Preface
This incident is a victory for capital, not for users, and is a regression for industry development.
Bitcoin moves to the left, Sui to the right, every action that shakes decentralization brings a stronger contrast to the faith in Bitcoin.
The world needs not just a better global financial infrastructure, but there will always be a group of people needing a space of freedom.
There was a time when consortium chains were more popular than public chains because they met the regulatory needs of that era. The decline of consortiums today actually means that merely adhering to this need is not the real needs of users. What about the lost regulated users and the need for regulatory tools?
1. Event background
On May 22, 2025, Cetus, the largest decentralized exchange (DEX) in the Sui public chain ecosystem, suffered a hacker attack, instantly depleting liquidity, causing multiple trading pairs to crash in price, with losses exceeding $220 million.
As of the time of writing, the timeline is as follows:
On the morning of May 22, hackers attacked Cetus to siphon off $230 million, leading Cetus to urgently suspend the contract and issue an announcement.
On the afternoon of May 22, hackers cross-chain transferred about $60 million, while the remaining $162 million was still in Sui chain addresses. Sui validator nodes quickly took action to add the hacker address to the 'Deny List,' freezing the funds.
On the evening of May 22, Sui CPO @emanabio confirmed via tweet: funds have been frozen and returns will begin soon.
On May 23, Cetus began to fix vulnerabilities and update contracts.
On May 24, Sui open-sourced a PR explaining that it would soon use the aliasing mechanism with the whitelist for fund recovery.
On May 26, Sui initiated on-chain governance voting, proposing to execute protocol upgrades and transfer hacker assets to a custodial address.
On May 29, the voting results were announced, with more than 2/3 of the validator nodes' weight in support; protocol upgrades were prepared to be executed.
From May 30 to early June, the protocol upgrade took effect, designated transaction hashes were executed, and hacker assets were 'legally transferred away.'
2. Attack principles
Related to the principle of the event, the industry has already published several statements, here is just a core principle overview:
From the perspective of the attack process:
The attacker first utilized a flash loan to borrow about 10,024,321.28 haSUI, instantly causing the price in the trading pool to plummet.
99.90%. This huge sell order caused the target pool price to drop from about 1.8956×10^19 to 1.8425×10^19, nearly clearing it out.
Subsequently, the attacker created liquidity positions on Cetus within a very narrow range (Tick lower limit 300000, upper limit 300200, with a range width of only 1.00496621%), such a narrow range magnified the impact of subsequent calculation errors on the required token amount.
And the core principle of the attack:
The integer overflow vulnerability exists in the get_delta_a function used by Cetus to calculate the required token amount. The attacker deliberately declared a huge liquidity addition (about 10^37 units), but only put 1 token into the contract.
Due to the incorrect overflow detection condition of checked_shlw, the contract suffered a high-bit truncation during left shift calculations, causing the system to severely underestimate the required amount of haSUI, thus obtaining massive liquidity at a very low cost.
From a technical perspective, the aforementioned vulnerabilities stem from Cetus using incorrect masks and judgment conditions in the Move smart contract, allowing any value less than 0xffffffffffffffff << 192 to bypass detection; and after a left shift of 64 bits, high-bit data was truncated, causing the system to only collect a minimal amount of tokens while believing it had obtained massive liquidity.
After the incident, two official actions emerged: 'Freeze' vs 'Recover,' which are two phases:
The freezing phase is completed by Deny List + node consensus;
The recovery phase requires on-chain protocol upgrades + community voting + designated transaction execution bypassing the blacklist.
3. Sui's freezing mechanism
The Sui chain itself has a special Deny List mechanism that achieved the freezing of hacker funds. Moreover, Sui's token standard also has a 'regulated token' model with a built-in freezing function.
This emergency freezing utilized this feature: validator nodes quickly added addresses related to the stolen funds in their local configuration files. Theoretically, each node operator could modify TransactionDenyConfig to update the blacklist, but to ensure network consistency, the Sui Foundation, as the original configuration publisher, coordinated centrally.
The foundation first officially released a configuration update containing the hacker's address, and validators synced by default, temporarily 'sealing' the hacker's funds on the chain, which actually involves a high degree of centralization.
To rescue victims from frozen funds, the Sui team immediately launched a whitelist mechanism patch.
This is an operation aimed at transferring funds back later. Legal transactions can be pre-constructed and registered in the whitelist, and even if the funding address is still on the blacklist, it can be enforced.
This new feature transaction_allow_list_skip_all_checks allows specific transactions to be pre-added to the 'exempt list', enabling these transactions to skip all security checks, including signatures, permissions, blacklists, etc.
It should be noted that the whitelist patch cannot directly seize the hacker’s assets; it only grants certain transactions the ability to bypass the freeze, while real asset transfers still require valid signatures or additional system permissions to complete.
In fact, the mainstream freezing solutions in the industry often occur at the token contract level and are controlled by multi-signatures of the issuer.
Taking USDT issued by Tether as an example, its contract has a built-in blacklist function that allows the issuing company to freeze non-compliant addresses, preventing them from transferring USDT. This solution requires multi-signatures to initiate a freeze request on-chain, and only after consensus is reached will it be truly executed, thus there is a delay in execution.
Although the Tether freezing mechanism is effective, statistics show that the multi-signature process often has 'windows of opportunity,' leaving room for criminals.
In contrast, Sui's freezing occurs at the underlying protocol level and is collectively operated by validator nodes, executing much faster than normal contract calls.
In this model, to execute quickly means that the management of these validator nodes must be highly unified.
3. The implementation principle of Sui's 'transfer-style recovery'.
More surprisingly, Sui not only froze the hacker's assets but also plans to recover the stolen funds through on-chain upgrades 'transfer recovery'.
On May 27, Cetus proposed a community voting plan, requesting an upgrade of the protocol to send the frozen funds to a multi-signature escrow wallet. The Sui Foundation immediately initiated governance voting on-chain.
On May 29, the voting results were announced, with about 90.9% of weighted validators supporting the proposal. Sui officially announced that once the proposal is passed, 'all funds frozen in the two hacker accounts will be returned to a multi-signature wallet without the need for hacker signatures.'
No need for hacker signatures, what a contrasting feature, such a repair method has never existed in the blockchain industry.
From the Sui official GitHub PR, it can be seen that the protocol introduced an address aliasing mechanism. The upgrade includes: pre-specifying aliasing rules in ProtocolConfig, allowing certain permitted transactions to consider valid signatures as coming from hacker accounts.
Specifically, the rescue transaction hash list to be executed is bound to the target address (i.e., the hacker's address), and any executor who signs and publishes these fixed transaction summaries is considered a valid hacker address owner initiating the transaction. For these specific transactions, the validator node system will bypass the Deny List check.
From the code level, Sui added the following judgment to the transaction verification logic: when a transaction is intercepted by the blacklist, the system traverses its signers to check whether protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) is true.
As long as there exists a signer that meets the aliasing rules, marking this transaction as allowed to pass, it ignores the previous interception errors and continues to be packaged and executed normally.
4. Perspectives
160 million, tearing apart the industry's deepest foundational beliefs.
From my personal view on the Cetus incident, this storm may pass quickly, but this model will not be forgotten because it subverted the foundations of the industry and broke the traditional consensus of immutability under one ledger in blockchain.
In blockchain design, contracts are law, and code is the judge.
But in this incident, the code failed, governance intervened, and power overshadowed, forming a model of 'voting behavior adjudicates code results.'
It is precisely because Sui's direct appropriation of transactions is vastly different from mainstream blockchain approaches to dealing with hacker issues.
This is not the first time 'consensus has been altered,' but it is the quietest one.
Historically:
The Ethereum 2016 DAO incident once compensated for losses through hard fork rollback transfers, but this decision led to the split of Ethereum and Ethereum Classic, the process was highly controversial, but ultimately led to different groups forming different consensus beliefs.
The Bitcoin community has also experienced similar technical challenges: the value overflow vulnerability in 2010 was urgently repaired by developers, and the consensus rules were upgraded, completely erasing about 1.84 billion illegally generated bitcoins.
This is the same hard fork model, rolling back the ledger to before the issue, and then users can still decide which ledger system to continue using.
Compared to DAO hard forks, Sui chose not to split the chain but to precisely target this incident through protocol upgrades and configuration aliasing. By doing so, Sui maintained the continuity of the chain and most consensus rules while also indicating that the underlying protocol can be used to implement targeted 'rescue actions.'
The problem is that the historical 'fork-style rollback' is a user choice of belief; Sui's 'protocol-style correction' is a decision made for you by the chain.
Not Your Key, Not Your Coin? I'm afraid Not Anymore.
In the long run, this means that the idea of 'Not your keys, not your coins' is being dismantled on the Sui chain: even if users have complete private keys, the network can still prevent asset movement and redirect assets through collective protocol changes.
If this becomes a precedent for future blockchain responses to major security incidents, even being regarded as a convention that can be followed again.
'When a chain can break the rules for justice, it then has the precedent to break any rules.'
Once there is a successful 'public interest robbery', the next time it might be an operation in 'moral gray areas'.
What would happen?
The hacker did indeed steal users' money, so can group voting take away his money?
Is the voting based on who has more money (pos) or more people? If the money wins, then the final producer described by Liu Cixin will soon arrive; if the people win, then the crowd of the masses will rise in voice.
Under traditional systems, it is very normal for illegal gains not to be protected; freezing and transferring are routine operations of traditional banks.
But from a technical theory perspective, it is impossible to achieve this, isn't it the root of the blockchain industry's development?
Now the stick of industry compliance is continuing to ferment; today it can freeze for hackers and modify account balances, and tomorrow it can do arbitrary modifications for geopolitical or conflict factors. If the chain becomes a part of regional tools.
Then the value of the industry will be significantly compressed, at best it is just another less usable financial system.
This is also the reason why I firmly believe in the industry: 'Blockchain is valuable not because it cannot be frozen, but because even if you hate it, it does not change for you.'
Regulation is an inevitable trend, can the chain hold onto its soul?
There was a time when consortium chains were more popular than public chains because they met the regulatory needs of that era. The decline of consortiums today actually means that merely adhering to this need is not the real needs of users. What about the lost regulated users and the need for regulatory tools?
From the perspective of industry development
Efficient centralization, is it an inevitable stage of blockchain development? If the ultimate goal of decentralization is to protect user interests, can we tolerate centralization as a transitional means?
'Democracy' in the context of on-chain governance is actually token weighted. So if hackers hold a large amount of SUI (or one day a DAO is hacked and hackers control the voting rights), can they also 'legally vote to wash themselves clean'?
Ultimately, the value of blockchain lies not in whether it can freeze, but in the fact that even if the group has the ability to freeze, it chooses not to do so.
The future of a chain is not determined by its technical architecture, but by the belief system it chooses to protect.
