In-depth reflection on the Sui public chain event

Introduction

Recent events have revealed the victory of capital rather than the interests of users. This could be a setback for the development of the industry.

The development directions of Bitcoin and Sui present a stark contrast; whenever there are industry actions that shake the foundation of decentralization, people's faith in Bitcoin becomes even stronger.

The world needs not only better global financial infrastructure but also a space of freedom that is always reserved for a part of the population.

Looking back at history, consortium chains were once more popular than public chains, primarily because they met the regulatory needs of the time. The decline of consortium chains today precisely illustrates that merely complying with regulatory requirements does not satisfy the real needs of users. Once regulated users are lost, regulatory tools lose their meaning of existence.

1. Event Background

On May 22, 2025, the largest decentralized exchange in a public chain ecosystem suffered a hacker attack, resulting in a sharp decline in liquidity, multiple trading pairs' prices collapsing, and losses exceeding $220 million.

The main timeline of the event is as follows:

• May 22nd morning: A hacker attack resulted in a loss of $230 million, the exchange urgently suspended contracts and issued an announcement.
• On the afternoon of May 22: Hackers transferred approximately $60 million across chains, with $162 million still remaining on the original chain.
• On the evening of May 22: The officials confirmed that the funds have been frozen and are preparing to start the refund process.
• May 23: The exchange began to fix vulnerabilities and update the contract.
• May 24: Public chain open source PR, explaining that fund recovery will be conducted through an alias mechanism and a whitelist.
• May 26: Launch on-chain governance voting to propose whether to execute protocol upgrades and transfer the hacker's assets to a custodian address.
• May 29: Voting results announced, over 2/3 of verification node weight supports.
• May 30 to early June: Agreement upgrade takes effect, designated transaction hash is executed, hacker assets are transferred.

2. Attack Principles

The attack primarily exploited the integer overflow vulnerability in the exchange's smart contract. The attacker first borrowed a large amount of tokens through a flash loan, causing the price in the trading pool to plummet by 99.90%. Subsequently, the attacker created liquidity positions within a very narrow price range.

The core of the attack lies in the integer overflow issue in the function used by the exchange to calculate the required number of tokens. The attacker claims to add a large amount of liquidity, but actually only invests a small amount of tokens. Due to incorrect overflow detection conditions, the system severely underestimates the required number of tokens, allowing the attacker to obtain a large amount of liquidity at a very low cost.

Technically, this vulnerability arises from the use of incorrect masks and judgment conditions in the smart contract, allowing a large number of values to bypass detection. After the left shift operation, the high-order data is truncated, and the system only collects a minimal amount of tokens, believing it has obtained significant liquidity.

After the incident, the authorities took two phases of response measures: "freezing" and "retrieving."

• Freezing Phase: Completed through the blacklist and node consensus
• Recovery Phase: Requires on-chain protocol upgrades, community voting, and execution of designated transactions to bypass the blacklist.

3. The Freezing Mechanism of Public Chains

The public chain has a special rejection list mechanism internally, which has implemented the freezing of the hacker's funds this time. In addition, its token standard also has a "regulated token" model, with a built-in freezing function.

The emergency freeze utilized this feature: validator nodes quickly added the addresses related to the stolen funds in their local configuration files. In theory, each node operator can modify the configuration to update the blacklist on their own, but to ensure network consistency, the 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 and take effect with the default configuration, thus temporarily "sealing" the hacker's funds on-chain. Behind this, there are actually high levels of centralization factors.

To rescue victims from frozen funds, the public chain team subsequently launched a whitelist mechanism patch. This 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 does not directly transfer hacker assets; it merely grants certain transactions the ability to bypass freezing, while the actual transfer of assets still requires legitimate signatures or additional system permission modules to be completed.

In contrast, mainstream freezing solutions in the industry often occur at the token contract level and are controlled by a multi-signature from the issuer. Taking a certain stablecoin as an example, its contract has a built-in blacklist function, allowing the issuing company to freeze non-compliant addresses. This solution requires a multi-signature to initiate a freeze request on-chain, and it is only executed after consensus is reached among the multi-signatories, which therefore leads to execution delays.

Although this freezing mechanism is effective, statistics indicate that the multi-signature process often experiences a "window period," leaving opportunities for criminals.

In contrast, the freezing in this event occurred at the underlying protocol level, carried out collectively by the validator nodes, and the execution speed is much faster than ordinary 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 "Transfer-based Recycling" in Public Chains

Even more surprisingly, the public chain not only froze the hacker's assets but also plans to upgrade on-chain to "transfer and recover" the stolen funds.

On May 27, the exchange proposed a community voting plan to require an upgrade to the protocol, sending the frozen funds to a multi-signature escrow wallet. The foundation immediately initiated an on-chain governance vote.

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

No hacker signatures are required; this is an unprecedented repair method in the blockchain industry.

According to the official GitHub PR, the protocol has introduced an address alias mechanism. The upgrade includes: pre-specifying alias rules in the protocol configuration, allowing certain permitted transactions to treat legal signatures as coming from hacked 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 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 denial list check.

From a code perspective, the public chain has added a new judgment in its transaction verification logic: when a transaction is intercepted by the blacklist, the system traverses its signers to check if they meet the alias rules. As long as there is a signer that meets the conditions, the transaction is marked as allowed to pass, ignoring the previous interception error, and continues to be packed and executed normally.

5. Perspectives

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

Although the storm of this incident may pass quickly, the model it adopted will not be forgotten, as it subverted the foundation of the industry and broke the traditional consensus of immutability under the same ledger in blockchain.

In blockchain design, contracts are the law, and code is the referee. However, in this incident, the code failed, governance intervened, and power prevailed, forming a model of "voting behavior adjudicating code results."

It is precisely because the public chain's practice of directly misappropriating transactions this time differs greatly from the way mainstream blockchains handle hacker issues.

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

Historically:

A certain public chain rolled back transactions through a hard fork in 2016 due to a major incident to compensate for losses, but this decision led to a split in the chain, a process that was highly controversial, but ultimately resulted in different groups forming different consensus beliefs.

The Bitcoin community has also faced similar technical challenges: the value overflow bug in 2010 was urgently fixed by developers and the consensus rules were upgraded, completely erasing about 1.84 billion illegally generated bitcoins.

These all adopt a hard fork model, rolling back the ledger to before the issue occurred, and then users can decide which ledger system to continue using.

Compared to previous hard forks, this time the public chain did not choose to split the chain, but instead precisely targeted this event through a protocol upgrade and configuration aliasing. This approach 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 actions".

The problem is that historically, "fork rollbacks" were a choice made by users; whereas this time, the "protocol correction" is a decision made by the chain on behalf of the users.

The concept of "Not your keys, not your coins" is dismantled on this public blockchain: even if a user has complete control over their private keys, the network can still prevent asset movement and redirect assets through collective protocol changes.

If this sets a precedent for how blockchain can respond to major security incidents in the future, and is even regarded as a convention that can be adhered to again, then "when a chain can break the rules for justice, it also has a precedent for breaking any rules."

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

What will happen?

If hackers really stole the user's money, can a group vote take away his money?

Is the vote based on who has more money or more people? If the one with more money wins, then the final producer described by Liu Cixin will soon arrive; if the one with more people wins, then the cacophony of the crowd will rise.

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

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

The big stick of industry compliance is continuing to ferment. Today, it can freeze and modify account balances for hackers, and tomorrow, it can make arbitrary modifications for geopolitical and conflict factors. If the chain becomes a regional tool, then the value of the industry will be significantly compressed, at best becoming just another less usable financial system.

This is also the reason for the industry's determination: "Blockchain is valuable not because it cannot be frozen, but because even if you hate it, it does not change for you."

The trend of regulation is irresistible; can the blockchain maintain its own soul?

Once upon a time, consortium blockchains were more popular than public blockchains because they met the regulatory needs of that era. Today, the decline of consortium blockchains actually means that merely adhering to this need is not the true demand of real users. If users who are under regulation are lost, then is there still a need for regulatory tools?

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 actually refers to token-weighted voting. So if a hacker holds a large number of tokens (or if one day an autonomous organization is hacked and the hacker controls the voting rights), can they also "legally vote to whitewash 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 collective has the ability to freeze.

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