Chain reorganizations ("reorgs") can affect the functioning of the PoD token. They happen when two (or more) groups of miners/stakers aren't in agreement which is the "longest chain", and so one group mines on one chain tip, the other on the other tip - until one of both groups "wins" and the other one deletes their tip and "reorganize" their chain taking the blocks of the other group. In SLM, they happen from time to time without bad intentions, for example due to network latency. It's however also possible that reorgs are used for attacks (the 51%-attack involves a reorg, for example).

The main problem is that when a reorg happens, the order and block height of the transactions can change. This happens because it is possible that the order of the transactions between the two groups of miners differ. So it is possible that in the chain tip that is later discarded, a transaction appears in block X, but the other group only includes it in block X 1 or even X 100.

This can affect the structure of the PoD token, because it heavily relies on block heights for its phases and rounds. For example, if we have a voting round where the "yes" and "no" votes are equilibrated until the last possible block of the voting round, and in this block ("block X") one voter votes "yes", the proposal is approved. But then a reorg happens and the voting transaction of this last voter gets included in block X 2, then the proposal would not be approved anymore. If someone has signalled funds, then he has wasted the transaction fees.

Which are the main phases affected by that problem?

1) The most "dangerous" one is the period between the second voting phase and the donation release. If a positive result of the second voting phase is "overturned" by a reorg and becomes negative, and some donors have already donated, then they won't get tokens for their donations. This must be avoided at all costs.

2) Similarly dangerous would be a reorg in the last round (8th round, or round 7 if we start counting with round 0) of the second slot allocation round. This is a first-come-first-serve round, so the order between the signalling transactions is of crucial importance. The donors of this round need to be sure that the signalling order is "final", once they donate. If this is not the case, then in may happen that a donor A which signalled one block before another donor B and got the last available slot, is relegated to a blockheight after donor B,

3) Third in priority would be the other rounds of the second phase. Here, of course if you donate funds and a reorg happens, two problems are possible: a) Your donation is placed by the reorg "outside" of the round/phase, and then it becomes invalid. b) The signalling transactions become changed in order/or some become invalid, or even invalid ones become valid, so the amount you donate (using the slot "before" the reorg) doesn't anymore match your slot after the reorg.

4) In the rounds 1-4 the worst thing that may happen is that you lock your coins in vain, because either your signalling transaction or your locking transaction is included, after the reorg, in a block outside of the corresponding round (and thus becomes invalid). So this should also be avoided but would not be that catastrophic.

In some cases you may also be able to double spend the transactions to avoid an invalid donation, or an innecessary lock. For example, if you become aware that the voting has been overturned due to a reorg, but the donation transaction you already sent has still not been included in a block, you can send these funds to another of your addresses with a higher fee, and then very likely this transaction will be mined. You can't however rely on this.

The solution I propose are security periods between all major phases and rounds (currently there is only one such period per phase, which I now see as insufficient). These are periods where transactions of a specific type (voting, signalling, locking or donation) are still accepted by the system. But you won't be able to transact in them with the standard pacli tools, or a warning is issued that the transaction may be lost.

Transactions which are re-ordered after a reorg in a way they appear a couple of dozens (up to hundreds) of blocks later or a couple of blocks earlier (this is rare but could also happen), would then not be in danger to be "outside of their round", but instead fall into a security period, and so they would be counted as normal.

Between the most critical phases, I would propose security periods of 1000 blocks (around a day). These have to be secure, a reorg which makes transactions invalid there could cause a lot of harm to the token. Maybe for the most critical period (2nd voting -> donation release) I would even allocate 2000 blocks to the security period.

Shorter security periods between the less critical phases, for example 200 or 400 blocks. Normally, a reorg should not be longer than 100 blocks, so the transactions can also not be re-ordered by much more than 100, but we have to go safe due to the possible harm - a 500-block reorg is extremely unlikely, but if it happens, the harm for the PoD token would be big if the security periods are too short.

Feedback for the proposed solution is greatly appreciated!