Introduction

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

Bitcoin to the left, Sui to the right, every shake in 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 free space.

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 consortium chains actually means that merely complying with this requirement does not reflect the real needs of users. With the loss of regulated users, what is the need for regulatory tools?

1. Event Background

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, 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, a Hacker attacked Cetus, extracting $230 million. Cetus urgently suspended contracts and issued an announcement.
• On May 22nd in the afternoon, a Hacker transferred approximately 60 million dollars across chains, while the remaining 162 million dollars are still in the Sui chain address. Sui validator 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@emanabioTweet confirmation: Funds have been frozen, and refunds will begin shortly.
• On May 23, Cetus began fixing vulnerabilities and updating contracts.
• On May 24th, Sui open-source PR explained that funds will soon be recovered through the aliasing mechanism and whitelist.
• On May 26, Sui initiated an on-chain governance vote, 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 the validator node weight in support; the protocol upgrade is ready to be executed.
• From May 30 to early June, the protocol upgrade took effect, the designated trading hash was executed, and the hacker's assets were "legally transferred away."

2. Attack Principle

Regarding the principles of events, the industry has already published several statements. Here, we only provide an overview of the core principles:

From the perspective of the attack process:

The attacker first borrowed approximately 10,024,321.28 haSUI using a flash loan, 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 clearing 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 amplifies the impact of subsequent calculation errors on the required token quantity.

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 number of tokens. An attacker intentionally claims to add a huge liquidity (approximately 10^37 units), but actually only contributes 1 token to the contract.

Due to the incorrect overflow detection condition of checked_shlw, the contract experienced high-bit truncation during left shift calculations, causing the system to seriously underestimate the required amount of haSUI, thus obtaining 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; furthermore, the high-order data is truncated after a left shift of 64 bits, causing the system to believe it has gained significant liquidity with only a small amount of tokens collected.

After the incident occurred, two official operations emerged: "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. The freezing mechanism of Sui

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

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

The foundation first officially released a configuration update containing the hacker's address, and the validators synchronized according to the default configuration, temporarily "sealing" the hacker's funds on the chain. In fact, there are highly centralized factors behind this.

In order to rescue victims from frozen funds, the Sui team quickly launched a whitelist mechanism patch.

This is for the operation of transferring funds back in the future. You can pre-construct legitimate transactions and register them on the whitelist. Even if the fund address is still on the blacklist, it can still be forcibly executed.

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

It is important to note that the whitelist patch does not directly seize hacker assets; it only grants certain transactions the ability to bypass freezes, while the actual transfer of assets still requires a legal signature or additional system permission modules to be completed.

In fact, the mainstream freezing solutions in the industry often occur at the token contract level and are controlled by multi-signatures 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 scheme requires a multi-signature to initiate the freeze request on-chain, and it is only executed after the multi-signature reaches a consensus, thus there is a delay in execution.

The Tether freezing mechanism is effective, but statistics show that the multi-signature process often has "windows of opportunity," leaving room for criminals to take advantage.

In contrast, Sui's freezing occurs at the underlying protocol level, operated collectively by validator nodes, with a speed much faster than that of regular contract calls.

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

4. The implementation principle of Sui's "transfer-based recycling".

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

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

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

No hacker signature is required, what a unique feature, the blockchain industry has never had such a repair method.

From the Sui official GitHub PR, it is clear that the protocol has introduced an address aliasing mechanism. The upgrade includes: pre-specifying alias rules in ProtocolConfig, allowing certain permitted transactions to consider 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 considered to have initiated the transaction as a valid owner of the Hacker address. For these specific transactions, the validator node system will bypass the Deny List check.

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

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

5. Opinion

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

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

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

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

The reason is that Sui's direct appropriation of transactions is in stark contrast to 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 and Ethereum Classic into two chains. The process was highly controversial, but ultimately different groups formed different consensus beliefs.
• The Bitcoin community has also faced similar technical challenges: the value overflow bug in 2010 was urgently fixed by developers who upgraded the consensus rules, completely erasing approximately 1.84 billion illegally generated bitcoins.

This is the same hard fork pattern, rolling the ledger back to before the issue, after which users can still decide which ledger system to continue using.

Unlike the DAO hard fork, Sui did not choose to split the chain, but instead precisely targeted this event through protocol upgrades and configuration aliases. By doing this, Sui maintains the continuity of the chain and keeps most consensus rules unchanged, while also indicating that the underlying protocol can be used to implement targeted "rescue operations."

The problem is that historically, "fork-based rollbacks" are a matter of user choice; Sui's "protocol-based corrections" are decisions made on behalf of the chain.

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

In the long run, this means that the idea of "Not your keys, not your coins" is being undermined on the Sui chain: even if users have the complete private keys, the network can still prevent asset movement and redirect assets through collective protocol changes.

If this becomes a precedent for the blockchain to respond to major security incidents in the future, or even be 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 rule."

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 then?

The hacker indeed stole the user's money, so can group voting 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 in Liu Cixin's writing will soon arrive. If the one with more people wins, then the chaotic crowd will also make their voices heard.

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 it the root of the development of the blockchain industry?

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

The value of that industry has also been significantly compressed, at best it is just another set of a less useful 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 it does not change for you even if you hate it."

With regulation on the rise, can the blockchain maintain its soul?

Once upon a time, consortium chains were more popular than public chains because they met the regulatory needs of that era. Nowadays, the decline of consortia actually means that simply adhering to these needs does not reflect the true needs of users. The users lost to regulation raise the question of what regulatory tools are needed.

From the perspective of industry development

"Efficient centralization"—is it 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 exonerate 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.

Statement:

1. This article is reproduced from [Fourteen Bacteria] The copyright belongs to the original author [Fourteen Bacteria] If you have any objections to the reprint, please contact Gate Learn TeamThe team will process it as soon as possible according to the relevant procedures.
2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Other language versions of the article are translated by the Gate Learn team, unless otherwise mentioned.GateUnder this circumstance, it is not allowed to copy, spread, or plagiarize translated articles.