The core idea of this hard fork can be summarized in one sentence: completely ban the 'hacker address', and temporarily declare a 'substitute signer' in the protocol, allowing only 1-2 specific 'redemption transactions' to pass verification and transfer the money.
1. How is the substitute transaction implemented?
Specifically, it can be broken down into two steps:
The first step is to add a new parameter.
SUI has added a parameter called aliased_addresses to the signature verification layer verify_sender_signed_data_message_signatures, which does a replacement.
Simply put, aliased means substitute address.
The second step is to open a loophole in the deny check.
Specify that only 'substitute + specified hash' can be allowed.
The effect of these two steps combined is:
Any ordinary transaction → is still intercepted by the deny list;
Only the redemption transaction in the 【substitute declaration】, where the signer is the substitute, can bypass the ban and continue execution.
Currently, SUI has already withdrawn the money from the hacker address using the 【substitute signing】 method.
This is consistent with our previous article's prediction.
2. Is there a 'referendum' logic?
There is no code related to on-chain voting, DAO governance, or 'referendums' at all in this PR set.
They did not choose a public referendum; ultimately, it was representative governance that solved the problem, with validators holding 2/3 of the total staked weight proactively upgrading and merging the aforementioned code.
Of course, Sui's current governance model originally focuses on 【validator governance】 rather than 【non-token holder governance】.
Objectively speaking, although it is somewhat centralized, in emergency situations, the foundation + validators' consensus is the fastest path.
3. Can the foundation use 'substitutes' freely in the future?
Let's first take a look at how to reconstruct a substitute transaction.
First, the protocol version must be upgraded again.
The substitute address is hardcoded in the initialization code of v83. If you want to add other mappings in the future, you must release new code and have validators holding ≥ 2/3 of the total staked weight proactively upgrade.
If the nodes refuse to upgrade, the old code will not have corresponding entries, and the substitute will not take effect.
Secondly, the whitelist restricts the 'transaction hash'.
【Substitute Code】Only lists those two redemption transactions. Even if someone uses the same private key to sign other transactions, they will not pass verification.
In the end, the lifespan is short.
The source code states that once the network is fully upgraded to v86, the substitute fields will be completely removed; the old list will naturally become invalid.
So, this function is temporarily added and will soon be deleted; if you want to use a substitute again in the future, you will still need to go through the entire process.
So later it cannot be 【used casually】, but rather 【reprocessed for reuse】.