The hacker stole the money, so can Sui just take it?

Preface

This event is a victory for capital, not for users, and represents a regression in industry development.

Bitcoin moves left, Sui moves right; every action that shakes the foundation of decentralization intensifies the faith in Bitcoin.

The world needs more than just a better global financial infrastructure; there will always be a group of people who need a space for freedom.

Once upon a time, consortium chains were more popular than public chains because they met the regulatory demands of that era. Now, the decline of consortiums actually signifies that merely complying with this demand does not reflect the true needs of users. What is the need for regulatory tools when the regulated users are lost?

1. Background of the Incident

On May 22, 2025, Cetus, the largest decentralized exchange (DEX) in the Sui public chain ecosystem, suffered a hacker attack, resulting in an immediate drop in liquidity and the collapse of prices for multiple trading pairs, with losses exceeding $220 million.

As of the time of publication, the timeline is as follows:

On the morning of May 22, hackers attacked Cetus, extracting $230 million. Cetus urgently suspended contracts and issued an announcement.
In the afternoon of May 22, hackers transferred out approximately $60 million across chains, while the remaining $162 million was still in addresses on the Sui chain. Sui validation nodes quickly took action, adding the hacker's address to the "Deny List" and freezing the funds.
On the evening of May 22, Sui CPO @emanabio tweeted confirmation: the funds have been frozen, and the return will begin soon.
On May 23, Cetus began to fix vulnerabilities and update contracts.
On May 24, Sui open-sourced a PR explaining that funds would soon be recovered through an aliasing mechanism and a whitelist.
On May 26, Sui initiated on-chain governance voting, proposing whether to execute a protocol upgrade and transfer the hacker's assets to a custodial address.
On May 29, the voting results were announced, with over 2/3 of the validation node weight in support; preparations for the protocol upgrade were underway.
From May 30 to early June, the protocol upgrade took effect, and the specified transaction hash was executed, with the hacker's assets being "legally transferred away."

2. Attack Principle

Regarding the principles of the incident, the industry has already published multiple statements; here is a brief overview of the core principles:

From the attack process perspective:

The attacker first used a flash loan to borrow approximately 10,024,321.28 haSUI, instantly causing the price in the trading pool to drop by 99.90%. This massive sell order caused the target pool price to fall from approximately 1.8956×10^19 to 1.8425×10^19, nearly bottoming out.

Subsequently, the attacker created a liquidity position on Cetus within an extremely narrow range (Tick lower limit 300000, upper limit 300200, with a range width of only 1.00496621%). Such a narrow range amplified the impact of subsequent calculation errors on the required token quantity.

The core principle of the attack:

Lies in the integer overflow vulnerability present in the getdeltaa function used by Cetus to calculate the required token quantity. The attacker deliberately declared an intention to add a massive liquidity (approximately 10^37 units) but actually only contributed 1 token to the contract.

Due to incorrect overflow detection conditions in checked_shlw, the contract experienced high-bit truncation during left shift calculations, causing the system to severely underestimate the required haSUI quantity, thus obtaining massive liquidity at an extremely low cost.

Technically, the aforementioned vulnerability stems 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, leading the system to believe it had obtained massive liquidity with only a minimal number of tokens.

After the incident, two official operations emerged: "Freeze" vs "Recover," which are two phases:

The freeze phase was completed through the Deny List + node consensus;
The recovery phase requires on-chain protocol upgrades + community voting + specified transaction execution to bypass the blacklist.

3. Sui's Freezing Mechanism

The Sui chain itself has a special Deny List mechanism that enabled the freezing of the hacker's funds. Moreover, Sui's token standard also includes a "regulated token" model with a built-in freezing function.

This emergency freeze utilized this feature: validator nodes quickly added addresses related to the stolen funds in their local configuration files. Theoretically, each node operator can modify TransactionDenyConfig to update the blacklist, but to ensure network consistency, the Sui Foundation, as the initial configuration publisher, coordinated centrally.

The foundation first officially released a configuration update containing the hacker's address, and validators synchronized the default configuration, temporarily "sealing" the hacker's funds on-chain, which actually involved a high degree of centralization.

To rescue victims from the frozen funds, the Sui team subsequently introduced a whitelist mechanism patch.

This is aimed at operations for transferring back funds later. Legal transactions can be pre-constructed and registered on the whitelist, allowing them to be forcibly executed even if the fund address is still on the blacklist.

This new feature, transactionallowlistskipall_checks, allows specific transactions to be pre-added to an "exemption list," enabling these transactions to bypass all security checks, including signatures, permissions, and blacklists.

It is important to note that the whitelist patch does not directly seize the hacker's assets; it merely grants certain transactions the ability to bypass the freeze, while the actual asset transfer still requires legal signatures or additional system permission modules to complete.

In fact, mainstream freezing solutions in the industry often occur at the token contract level and are controlled by multi-signature from the issuer.

For example, Tether's USDT has a built-in blacklist function in its contract, allowing the issuing company to freeze non-compliant addresses, preventing them from transferring USDT. This solution requires multi-signature to initiate a freeze request on-chain, and only after consensus is reached does it actually execute, leading to execution delays.

While Tether's freezing mechanism is effective, statistics indicate that the multi-signature process often experiences "window periods," leaving opportunities for criminals.

In contrast, Sui's freezing occurs at the underlying protocol level, collectively operated by validator nodes, executing much faster than ordinary contract calls.

In this model, to execute quickly, it means that the management of these validator nodes is highly unified.

4. Sui's "Transfer-Based Recovery" Implementation Principle

Even more astonishingly, Sui not only froze the hacker's assets but also plans to "transfer and recover" the stolen funds through an on-chain upgrade.

On May 27, Cetus proposed a community voting plan to upgrade the protocol to send the frozen funds to a multi-signature custodial wallet. The Sui Foundation immediately initiated on-chain governance voting.

On May 29, the voting results were announced, with approximately 90.9% of the validation node weight supporting the proposal. Sui officially announced that once the proposal passed, "all funds frozen in the two hacker accounts will be recovered to a multi-signature wallet without the hacker's signature."

No hacker signature required; this is such a distinctive feature that the blockchain industry has never had such a repair method.

From Sui's official GitHub PR, it is evident that the protocol introduced an address aliasing mechanism. The upgrade includes: pre-specifying alias rules in ProtocolConfig, allowing certain permitted transactions to treat legal signatures as coming from hacker accounts.

Specifically, the list of hashes for the rescue transactions to be executed is bound to the target address (i.e., the hacker address), and any executor who signs and publishes these fixed transaction summaries is regarded as having initiated a transaction as a valid hacker address owner. For these specific transactions, the validator node system will bypass the Deny List check.

From a code perspective, Sui added the following judgment in the transaction verification logic: when a transaction is intercepted by the blacklist, the system traverses its signers and checks if protocolconfig.istxallowedviaaliasing(sender, signer, txdigest) is true.

As long as there is a signer that meets the aliasing rules, this transaction is marked as allowed to pass, ignoring the previous interception error, and continues to be packaged and executed normally.

5. Views

$160 million, tearing apart the industry's deepest foundational belief

From my personal perspective, the Cetus incident may soon pass, but this model will not be forgotten because it subverts the foundation of the industry and breaks the traditional consensus of immutability under the same ledger in blockchain.

In blockchain design, contracts are the law, and code is the judge.

However, in this incident, the code failed, governance intervened, and power superseded, forming a model of "voting behavior adjudicating code results."

This is because Sui's direct appropriation of transactions differs significantly from how mainstream blockchains handle hacker issues.

This is not the first time "consensus has been altered," but it is the quietest one

Historically:

The Ethereum 2016 DAO incident rolled back transactions through a hard fork to compensate for losses, but this decision led to the split of Ethereum and Ethereum Classic, a process that was highly controversial, ultimately resulting in different groups forming different consensus beliefs.
The Bitcoin community has also faced similar technical challenges: the 2010 value overflow vulnerability was urgently fixed by developers, upgrading consensus rules and completely erasing approximately 1.84 billion illegally generated bitcoins.

These are all similar hard fork models, rolling back the ledger to before the issue, allowing users to decide which ledger system to continue using.

Compared to the DAO hard fork, Sui did not choose to split the chain but precisely targeted this incident through protocol upgrades and configuration aliasing. In doing so, Sui maintained the continuity of the chain and most consensus rules unchanged, but also indicated that the underlying protocol could be used to implement targeted "rescue actions."

The issue is, historical "fork-style rollbacks" are user-chosen beliefs; Sui's "protocol-style correction" is a decision made for you by the chain.

Not Your Key, Not Your Coin? Perhaps Not Anymore.

In the long run, this means that the idea of "Not your keys, not your coins" is 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 how future blockchains respond to major security incidents, or even regarded as a practice that can be adhered to again.

"When a chain can break the rules for justice, it also sets a precedent for breaking any rules."

Once there is a successful instance of "public welfare robbery," the next time it could be an operation in the "moral gray area."

What will happen then?

The hacker indeed stole the users' money, so can a group vote take away his money?

Is the voting based on who has more money (PoS) or who has more people? If the one with more money wins, then the ultimate producer described by Liu Cixin will soon arrive; if the one with more people wins, then the collective mob will raise their voices.

In traditional systems, it is very normal for illegal gains to be unprotected; freezing and transferring are routine operations of traditional banks.

But the inability to do this from a technical theory perspective is precisely the root of the blockchain industry's development.

Now, the stick of industry compliance is continuously fermenting. Today, accounts can be frozen and balances modified for hackers; tomorrow, arbitrary modifications can be made for geopolitical or conflict factors. If the chain becomes a regional tool.

Then the value of the industry will be significantly compressed, at best becoming another less useful financial system.

This is also 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."

With the trend of regulation, can the chain maintain its soul?

From the Perspective of Industry Development

Is "efficient centralization" an inevitable stage in the development of blockchain? If the ultimate goal of decentralization is to protect user interests, can we tolerate centralization as a transitional means?

The word "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 whitewash themselves"?

Ultimately, the value of blockchain lies not in whether it can be frozen, but in the choice not to do so even when the group has the ability to freeze.

The future of a chain is determined not by its technical architecture, but by the set of beliefs it chooses to uphold.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。