Opinion: Did the hacker steal the money, so Sui can take it?

Written by: Shisi Jun

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

Bitcoin to the left, Sui to the right, every action that shakes the decentralized industry brings a stronger belief in Bitcoin.

The world needs not just a better global financial infrastructure, but 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. Today, the decline of consortiums actually means that simply adhering to this need does not reflect the true demands of users. What about the users lost to regulation? What regulatory tools are needed then?

1. Background of the event

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

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

On the morning of May 22, hackers attacked Cetus to siphon off 230 million dollars, leading Cetus to urgently suspend contracts and issue an announcement.

On the afternoon of May 22, hackers transferred approximately 60 million USD across chains, while the remaining 162 million USD is still in the Sui chain address. Sui validation nodes quickly took action, adding the hacker address to the "Deny List" and freezing the funds.

On the evening of May 22, Sui CPO @emanabio tweeted to confirm: funds have been frozen, and refunds will start soon.

On May 23, Cetus began fixing vulnerabilities and updating the contract.

On May 24th, Sui open-sourced a PR explaining that funds will soon be recovered through an aliasing mechanism and a whitelist.

On May 26, Sui initiated on-chain governance voting, proposing whether to execute the 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 validating nodes' weight in support; the protocol upgrade is ready to be executed.

May 30 - early June, the protocol upgrade takes effect, the designated transaction hash is executed, and the hacker's assets are "legally transferred away".

2. Attack Principles

Regarding the principle of the event, there have been multiple statements in the industry, here is just an overview of the core principles:

From the perspective of the attack process:

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.

99.90%. This massive sell order caused the target pool price to drop 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 magnified the impact of subsequent calculation errors on the required amount of tokens.

The core principle of the attack:

There is an integer overflow vulnerability in the get_delta_a function used by Cetus to calculate the required token amount. An attacker deliberately claims to add a massive liquidity (approximately 10^37 units), but actually only deposits 1 token into the contract.

Due to an error in the overflow detection condition of checked_shlw, the contract experienced high-bit truncation during the left shift calculation, causing the system to severely underestimate the required amount of haSUI, thus acquiring a massive amount of 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 left-shifting by 64 bits, the high-order data is truncated, resulting in the system collecting only a minimal amount of tokens and believing it has gained significant liquidity.

After the incident occurs, two official actions emerge: "Freeze" vs "Recover", which are two phases:

The freezing phase is completed through Deny List + node consensus;

The recovery phase requires on-chain protocol upgrades + community voting + designated transaction execution to bypass the blacklist.

3. Sui's freezing mechanism

The Sui chain itself has a special Deny List ( mechanism, which achieved the freezing of the hacker's funds this time. Not only that, in fact, Sui's token standard also includes a "regulated token" model, which has a built-in freezing function.

The emergency freeze took advantage of this feature: validator nodes quickly added the addresses related to the stolen funds in their local configuration files. In theory, each node operator could modify the TransactionDenyConfig to update the blacklist independently, but to ensure network consistency, the Sui Foundation, as the original configuration publisher, conducted centralized coordination.

The foundation first officially released a configuration update containing the hacker's address, allowing validators to synchronize with the default configuration, thereby temporarily "sealing" the hacker's funds on the chain. Behind this, there are actually high levels of centralization factors.

In order to rescue the victims from frozen funds, the Sui team has immediately launched the whitelist )Whitelist( mechanism patch.

This is an operation for subsequent fund returns. Legal transactions can be pre-constructed and registered in the whitelist, which can be enforced even if the fund address is still on the blacklist.

The new feature transaction_allow_list_skip_all_checks allows specific transactions to be pre-added to the "exemption list," enabling these transactions to bypass all security checks, including signatures, permissions, blacklists, etc.

It is important to note that the whitelist patch cannot directly seize assets from hackers; it merely grants certain transactions the ability to bypass freezing, while the actual transfer of assets still requires a legitimate signature or additional system permission modules to be completed.

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 USDT issued by Tether 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 a multi-signature to initiate the freeze request on-chain, and it is only executed after consensus is reached among the multi-signatures, resulting in execution delays.

Although the Tether freezing mechanism is effective, statistics show that the multi-signature process often has "window periods," which provide opportunities for criminals.

In comparison, the freezing of Sui occurs at the underlying protocol level, operated collectively by validator nodes, and executes much faster than ordinary contract calls.

In this model, in order to execute quickly, it means that the management of these validator nodes themselves must be highly unified.

3. The implementation principle of Sui's "Transfer-based Recycling"

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

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

On May 29, the voting results were announced, with approximately 90.9% of weighted validators supporting the proposal. Sui officials announced that once the proposal is passed, "all funds frozen in the two hacker accounts will be retrieved to a multi-signature wallet without the need for hacker signatures."

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

According to the Sui official GitHub PR, the protocol has introduced the address aliasing mechanism )address aliasing(. The upgrade includes: pre-specifying alias rules in ProtocolConfig, allowing certain permitted transactions to treat valid signatures as sent from hacker accounts.

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

From the code perspective, Sui has added the following check in the transaction validation logic: when a transaction is intercepted by the blacklist, the system iterates through its signers and checks whether protocol_config.is_tx_allowed_via_aliasing)sender, signer, tx_digest( are true.

As long as there is a signer that meets the alias rules, the transaction marked as allowed to pass will ignore previous interception errors and continue to be packaged and executed normally.

4. Opinion

160 million, tearing apart the deepest underlying beliefs of the industry

Cetus incident, from the author's personal point of view, this may be a storm will pass soon, but this model will not be forgotten, because it subverts the foundation of the industry, and also breaks the traditional consensus that blockchain cannot be tampered with under the same set of ledgers.

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

But in this incident, the code failed, governance intervened, power prevailed, forming a pattern of voting behavior determining the results of the code.

The reason is that Sui's direct appropriation of transactions differs significantly from how mainstream blockchains handle hacker issues.

This is not the first time of "manipulating consensus", but it is the quietest one.

Historically:

The Ethereum DAO incident in 2016 rolled back transactions through a hard fork to compensate for losses, but this decision led to the split of Ethereum into Ethereum and Ethereum Classic. The process was highly controversial, but ultimately different groups formed different consensus beliefs.

The Bitcoin community has also experienced similar technical challenges: the value overflow bug in 2010 was urgently fixed by developers and consensus rules were upgraded, completely eliminating approximately 18.4 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 did not choose to split the chain but instead precisely targeted this event through protocol upgrades and configuration of aliases. By doing so, Sui maintained the continuity of the chain and most of the consensus rules unchanged, while also indicating that the underlying protocol can be used to implement targeted "rescue actions."

The problem is that historical "fork-based rollbacks" are a choice made by users; Sui's "protocol-based 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 concept of "Not your keys, not your coins" is undermined on the Sui chain: even if the user's private keys are intact, the network can still prevent asset flow and redirect assets through collective protocol changes.

If this becomes a precedent for the future blockchain to respond to large security incidents, and is even regarded as a practice that can be followed again.

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

Once there is a successful "public welfare money grab," the next time it may be an operation in the "moral gray area."

What will happen?

If hackers have indeed stolen the user's money, can a collective vote take away his money?

Is the voting based on who has more money (pos) or who has more people? If it's the one with more money that wins, then the final producers described by Liu Cixin will arrive soon. If it's the one with more people that wins, then the crowd of the masses will also raise their voices.

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

But from a technical theoretical perspective, this cannot be achieved, isn't that the root of the development of the blockchain industry?

The stick of industry compliance is continuously fermenting. Today, it can be used to freeze and modify account balances for hackers, and tomorrow it can be used to make arbitrary modifications due to geopolitical factors or conflicting elements. If the chain becomes a regional tool.

The value of that industry has also been greatly compressed, at best, it's just another set of a less functional financial system.

This is also the reason why the author is firm 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 regulatory trends on the rise, can the blockchain maintain its own soul?

Once upon a time, consortium chains were more popular than public chains because they met the regulatory demands of that era. Today, the decline of consortiums actually means that merely adhering to this demand does not reflect the true needs of users. The loss of regulated users raises the question of what regulatory tools are needed.

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 power), can they also "legally vote to whitewash themselves"?

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

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