Did the hacker steal the money, so Sui can rob it?

Author: Shijun

This incident is a victory for capital, not for users, and it represents a regression for industry development.

Bitcoin to the left, Sui to the right; every action that shakes the foundation of decentralization brings a stronger belief in Bitcoin.

What the world needs is not just a better global financial infrastructure, but a space for freedom that will always be needed by a group of people.

Once upon a time, consortium chains were more popular than public chains because they met the regulatory needs of that era. The decline of consortiums today actually signifies that merely complying with this demand does not reflect the true needs of users. What about the users lost to regulation? What tools are needed for regulation then?

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 instant liquidity drop 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.
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 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: 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 hacker assets to a custodial address.
On May 29, the voting results were announced, with over 2/3 of 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 hacker 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:

The attacker first used a flash loan to borrow about 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 a very 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 in the getdeltaa function used by Cetus to calculate the required token quantity. The attacker deliberately declared the intention to add a massive liquidity (about 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 a minimal 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 few 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 required 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" mode 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. In theory, each node operator could 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. Behind this, there is actually 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 hacker 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 execute, leading to execution delays.

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

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 means that the management of these validator nodes is highly unified.

4. Sui's "Transfer Recovery" Implementation Principle

Even more astonishingly, Sui not only froze the hacker's assets but also planned to recover the stolen funds through on-chain upgrades.

On May 27, Cetus proposed a community voting plan to upgrade the protocol and 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 about 90.9% of the validation node weight supporting the plan. 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 need for the hacker's signature—what a distinctive feature; such a repair method has never existed in the blockchain industry.

From Sui's official GitHub PR, it is known 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 rescue transaction hashes to be executed is bound to the target address (i.e., the hacker address), and any executor signing and publishing 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 the code level, 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 continuing to be packaged and executed normally.

5. Opinion

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

From my personal perspective, the Cetus incident may pass quickly, 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 referee.

But in this incident, the code failed, governance intervened, and power superseded, forming a model where voting behavior adjudicates the results of the code.

This is because Sui's direct appropriation of transactions is vastly different 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 also faced similar technical challenges: the value overflow vulnerability in 2010 was urgently fixed by developers, upgrading consensus rules and completely erasing about 1.84 billion illegally generated bitcoins.

These are all similar hard fork models, rolling back the ledger to before the problem, 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, while also indicating that the underlying protocol could be used to implement targeted "rescue actions."

The issue is that 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" has been 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 blockchains respond to major security incidents in the future, or even regarded as a practice that can be adhered to again.

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

Once there is a successful instance of "public interest robbery," the next time it could be an operation in a "morally ambiguous zone."

What will happen then?

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

Is the vote based on who has more money (pos) or who has more people? If the one with more money wins, then the end product described by Liu Cixin will soon arrive; if the one with more people wins, then the crowd of the masses will raise their voices.

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

However, 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 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."

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

From the Perspective of Industry Development

Is efficient centralization a necessary 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 term "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 clear themselves"?

Ultimately, the value of blockchain lies not in whether it can freeze, but in the choice not to do so, even if 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，本平台相关工作人员将会进行核查。