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

Reprinted from chaincatcher

06/03/2025·15D

Author: Fourteen Lords

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

Bitcoin goes left and Sui goes right. Every move that shakes decentralization brings a stronger belief in Bitcoin.

What the world needs is not just a better set of global financial infrastructure, but there will always be a group of people who need freedom.

Once upon a time, alliance chains were more popular than public chains because they met the regulatory needs of that era. Now the decline of alliances actually means that simply complying with this demand is not the needs of real users. What about the lost regulated users? What about regulatory tools?

1. Event background

On May 22, 2025, Cetus, the largest decentralized exchange (DEX), the Sui public chain ecosystem, was attacked by hackers, and its liquidity dropped sharply in an instant, and the prices of various transaction pairs collapsed, with losses exceeding US$220 million.

The timeline is as follows before publication:

On the morning of May 22, hackers attacked Cetus to embezzle US$230 million, Cetus suspended the contract urgently and issued an announcement
On the afternoon of May 22, the hacker transferred about $60 million across the chain, and the remaining $162 million was still in the Sui chain address. The Sui verification node quickly took action to add the hacker address to the "Deny List" and freeze funds.
On the evening of May 22, Sui CPO @emanabio tweeted to confirm that the funds have been frozen and the return will begin soon
On May 23, Cetus begins fixing vulnerabilities and updating contracts
On May 24, Sui open source PR explains that it will soon recover funds through aliasing mechanism and whitelist
On May 26, Sui launched an on-chain governance vote, proposing whether to implement a protocol upgrade and transfer hacker assets to a custodial address
On May 29, the voting results were announced, and more than 2/3 of the verification node weights were supported; the protocol upgrade was ready to be implemented
From May 30 to early June, the agreement upgrade took effect, the designated transaction hash was executed, and the hacker assets were "legally transferred away"

2. Principle of attack

The industry has already expressed many articles related to the incident principle. Here we will only give an overview of the core principles:

From the attack process:

The attacker first used Lightning Loan to borrow about 10,024,321.28 haSUI, instantly dropping the price of the trading pool.

99.90%. This huge sell order has reduced the target pool price from about 1.8956×10^19 to 1.8425×10^19, almost clearing it down.

The attacker then created liquidity positions on Cetus with a very narrow range (Tick lower limit 300000, upper limit 300200, interval width is only 1.00496621%). Such a narrow range amplifies the impact of subsequent calculation errors on the number of tokens required.

And the core principle of attack:

There is an integer overflow vulnerability in the get_delta_a function used by Cetus to calculate the required number of tokens. The attacker deliberately declared to add a huge liquidity (about 10^37 units), but actually only invested 1 token into the contract.

Due to the error in the overflow detection condition of checked_shlw, the contract was truncated at a high position during the left shift calculation, causing the system to seriously underestimate the required number of haSUIs, thus exchanging huge liquidity at a very small cost.

From a technical perspective, the above vulnerability originated from Cetus' use of wrong masks and judgment conditions in the Move smart contract, resulting in any value less than 0xffffffffffffffff << 192 being bypassed by 64 bits left, and the high-bit data is truncated, and the system only collects very few tokens and believes that it has obtained huge liquidity.

After the incident, two official operations were derived: "Frozen" vs "Recovery", which is in two stages:

The freezing phase is completed by Deny List + node consensus;
During the recovery phase, the on-chain protocol upgrade is required + community voting + designated transaction execution bypass blacklist.

3. Sui's freezing mechanism

There is a special Deny List (reject list) mechanism in the Sui chain, which has achieved the freezing of hacker funds. Not only that, Sui's token standard also has a "regulated token" model, with a built-in freezing function.

This emergency freeze takes advantage of this feature: the validator node quickly adds addresses related to the stolen funds to the local configuration file. In theory, each node operator can modify TransactionDenyConfig to update the blacklist by itself, but to ensure network consistency, the Sui Foundation has coordinated centrally as the initial configuration publisher.

The foundation first officially released a configuration update containing the hacker address. Verifiers take effect synchronously according to the default configuration, so that hacker funds are temporarily "sealed" on the chain. There are actually high centralization factors behind this.

In order to rescue victims from the frozen funds, the Sui team immediately launched a patch for the Whitelist mechanism.

This is for subsequent transfer of funds. Legal transactions can be constructed in advance and registered on the whitelist, and even if the fund 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" so that these transactions can skip all security checks, including signatures, permissions, blacklists, etc.

It should be noted that whitelist patches cannot directly rob hacker assets; it only gives certain transactions the ability to bypass freezing, and real asset transfers still require legal signatures or additional system permission modules to complete.

In fact, the mainstream freezing schemes in the industry often occur at the token contract level and are controlled by the issuer for multiple signings.

Take the USDT issued by Tether as an example. Its contract has a built-in blacklist function, and the issuing company can freeze the illegal address so that it cannot transfer the USDT. This solution requires multiple signatures to initiate a freeze request on the chain, and it will only be implemented after multiple signatures reach an agreement, so there is an execution delay.

Although the Tether freezing mechanism is effective, statistics show that the multi-signment process often has a "window period", leaving criminals with opportunities to take advantage of.

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

In this mode, if it is executed quickly enough, it means that the management of these validator nodes themselves is highly unified.

3. Sui's "transfer recycling" implementation principle

What’s even more amazing is that Sui not only freezes hacker assets, but also plans to upgrade on-chain to “transfer and recycle” the stolen funds.

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

On May 29, the voting results were announced, and about 90.9% of the weighted validators supported the scheme. Sui officially announced that once the proposal is passed, "all funds frozen in the two hacker accounts will be collected back to a multi-signature wallet without the hacker's signature."

No hacker signature is required, what a different feature, there has never been such a way to fix it in the blockchain industry.

From Sui's official GitHub PR, we can see that the protocol introduces an address aliasing mechanism. The upgrade includes: pre-specifying alias rules in ProtocolConfig so that certain allowed transactions can treat legal signatures as being sent from a hacker account.

Specifically, the hash list of 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 summary is considered to be the valid hacker address owner initiated the transaction. For these specific transactions, the validator node system bypasses the Deny List check.

From the code level, Sui added the following judgment to the transaction verification logic: When a transaction is intercepted by a blacklist, the system traverses its signature and checks whether protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) is true.

As long as a signer meets the alias rule, that is, marking the transaction is allowed to pass, the previous interception error will be ignored and the normal packaging execution will be continued.

4. Viewpoint

160 million, the deepest underlying belief in the industry

From the author's personal opinion, this storm may pass quickly, but this model will not be forgotten because it subverts the industry foundation and breaks the traditional consensus that blockchain cannot be tampered with under the same ledger.

In blockchain design, contracts are laws and codes are referees.

However, in this incident, the code was invalid, governance intervention, and power overwhelmed, forming a pattern of voting behavior ruling code results.

This is because Sui's direct misappropriation of transactions this time is very different from the mainstream blockchain's handling of hacker issues.

This is not the first time to "tamper with consensus", but it is the silent one

Historically:

The DAO incident in Ethereum in 2016 made up for its losses through hard fork rollback transfers, but this decision led to the split between Ethereum and Ethereum Classic chains, which was controversial, but ultimately different groups formed different consensus beliefs.
The Bitcoin community has also experienced similar technical challenges: the value spillover vulnerability in 2010 was urgently fixed by developers and upgraded consensus rules, completely erasing about 18.4 billion illegally generated Bitcoins.

These are all the same hard fork mode. When the ledger is rolled back before the problem, the user can still decide which ledger system to continue to use it.

Compared with the DAO hard fork, Sui did not choose a split chain, but instead targeted this event accurately through protocol upgrade and configuration alias. In doing so, Sui keeps the chain continuity and most consensus rules unchanged, but also shows that the underlying protocol can be used to implement targeted "rescue operations."

The problem is that the historical "fork rollback" is the user's choice of belief; Sui's "protocol correction" is the chain that makes the decision for you.

Not Your Key, Not Your Coin? I'm afraid Not Anymore.

In the long run, this means that the concept of "Not your keys, not your coins" has been disintegrated on the Sui chain: Even if the user's private key is complete, the network can still block asset flow and redirect assets through collective agreement changes.

If this becomes a precedent for blockchain to deal with large security incidents in the future, and is even considered a practice that can be followed again.

"When a chain can break the rules for justice, it has precedents for breaking any rules."

Once there is a successful "charity money grab", the next time it may be an operation in a "moral vague zone".

What will happen then?

Hackers have indeed stolen users' money, so can group votes rob him of money?

Who is the basis for voting? If the more money win, the last-time producers in Liu Cixin's works will arrive soon. If the more people win, then the crowd will be filled with noises.

Under the traditional system, it is very normal for illegal income to be unprotected, and freezing and transfer are routine operations of traditional banks.

But from a technical theory that this cannot be done is the root cause of the development of the blockchain industry.

Now the industry compliance stick is continuing to ferment. Today, the account balance can be modified for the sake of hackers. Tomorrow, it can be modified by geopolitical and contradictory factors. If the chain becomes a regional part of the tool.

The value of the industry will be greatly compressed, and at best it is another even less useful financial system.

This is also the reason why I am firm in the industry: "Blockchain is not valuable because it cannot be frozen, but because even if you hate it, it will not change for you."

As the supervision trend is in general, can the chain keep 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 the interests of users, can we tolerate centralization as a transitional means?

The word "democracy" is actually token weighted in the context of on-chain governance. So if a hacker holds a large number of SUIs (or one day the DAO is hacked and the hacker controls the voting rights), can he also "legitimate voting to clean himself up"?

Ultimately, the value of blockchain is not whether it can be frozen, but 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 the technical architecture, but by the set of beliefs it chooses to protect.