The hacker stole the money, so can Sui rob it?

Author: Shijiu Jun

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.

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 needs of that era. Now, the decline of consortiums actually means that simply 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 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:

• May 22, morning: The hacker attacked Cetus, extracting $230 million. Cetus urgently suspended contracts and issued an announcement.
• May 22, afternoon: The hacker 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.
• May 22, evening: Sui CPO @emanabio tweeted confirmation: funds have been frozen, and returns will begin shortly.
• May 23: Cetus began to fix vulnerabilities and update contracts.
• May 24: Sui open-sourced a PR explaining that funds would soon be recovered through an aliasing mechanism and a whitelist.
• 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.
• May 29: Voting results were announced, with over 2/3 of validation node weight in support; the protocol upgrade was prepared for execution.
• May 30 - 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 principle of the incident, the industry has already published multiple statements, and here is a brief overview of the core principle:

From the attack process perspective:

The attacker first utilized 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 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 present in the getdeltaa function used by Cetus to calculate the required token quantity. The attacker deliberately claimed 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.

From a technical perspective, 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 left shifting 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 represent two phases:

• The freeze phase relies on the Deny List + node consensus to complete;
• 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" 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 the "exemption list," enabling these transactions to skip 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.

Taking Tether's USDT as an example, its contract has a built-in blacklist function, 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, thus causing execution delays.

Although 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 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 validator 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 need for the hacker's signature—this is a remarkably different characteristic; the blockchain industry has never had such a repair method.

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 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 regarded as having initiated the 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 rule, the transaction is marked as allowed to pass, ignoring the previous interception error, and continues to be packaged and executed normally.

5. Perspective

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

From my personal perspective, the Cetus incident may blow over quickly, but this model will not be forgotten because it subverts the industry's foundation 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 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 instance.

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 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 instead 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 it also indicated 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, 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 gray area."

What will happen then?

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

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

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

However, from a technical theoretical standpoint, this cannot be done, which is the root of the blockchain industry's development.

Now, the regulatory big stick is continuously fermenting; today it can freeze for hackers and modify account balances, and tomorrow it can make arbitrary modifications 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 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?

Once upon a time, consortium chains were more popular than public chains because they met the regulatory needs of that era. Now, the decline of consortiums actually means that simply 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?

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 a hacker holds a large amount of SUI (or one day a DAO is hacked, and the hacker controls 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 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.