Substitute DeclarationSubstitute Signature The way was taken out. This is consistent with the predictions of the posts we analyzed earlier. Is there a "referendum" logic? There is no code related to on chain voting, DAO governance, or "referendum" in this set of PR. There was no choice for a national referendum, and ultimately the problem was solved by the representative system. The validators with 2/3 of the total pledge weight voluntarily upgraded and merged the above codes. Of course, Sui's current governance model originally focused on 'validator governance' rather than 'holder governance'. Objectively speaking, although there is some centralization, in the event of an emergency, a joint discussion between the foundation and the verifier is the fastest path. Can the foundation use "stunt doubles" at will in the future? Let's first take a look at how to reconstruct a stunt double transaction? Firstly, it is necessary to upgrade the protocol version again The substitute address is written in the initialization code of v83. If you want to add other mappings in the future, you must release new code and have validators with ≥ 2/3 of the total staking weight actively upgrade. If the node refuses to upgrade and there is no corresponding entry in the old code, the avatar will not take effect. Secondly, the whitelist restricts the "transaction hash" [Substitute Code] Only list those two redemption transactions. Even if someone signs another transaction with the same private key, it cannot pass the verification. Finally, the survival period is short The source code has already written that when the network is upgraded to v86, the avatar field will be completely removed; The old list naturally becomes invalid. So, this function was temporarily added and will soon need to be deleted. If you want to use a substitute again in the future, you still need to go through the entire process. So you can't use it casually later, but you can go through the process again and use it again.