Opinion: Hackers stole money, so can Sui take it?
TechFlow Selected TechFlow Selected
Opinion: Hackers stole money, so can Sui take it?
The value of blockchain lies not in whether it can be frozen, but in the fact that even though a group has the ability to freeze it, they choose not to.
Navigating Web3 tides with focused insightsAuthor: Shisijun
This incident marks a victory for capital, not users, and represents a setback for industry development.
Bitcoin goes left, Sui goes right. Every move that undermines decentralization only strengthens people's faith 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.
There was a time when consortium chains were more popular than public chains because they met the regulatory demands of their era. The current decline of consortium chains actually shows that simply complying with such demands does not reflect real user needs. If users subject to regulation are lost, then what use is a regulatory tool?
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. Liquidity plummeted instantly, prices of multiple trading pairs collapsed, and losses exceeded $220 million.
Timeline as of press time:
-
May 22 morning: Hacker exploited Cetus, draining $230 million. Cetus immediately paused its contract and issued an announcement.
-
May 22 afternoon: Hacker bridged approximately $60 million cross-chain; the remaining $162 million stayed on addresses within the Sui network. Sui validators swiftly took action by adding the hacker’s address to the "Deny List" (Denial of Service blacklist), freezing the funds.
-
May 22 evening: Sui CPO @emanabio confirmed via tweet: Funds have been frozen; recovery will begin shortly.
-
May 23: Cetus began fixing vulnerabilities and updating contracts.
-
May 24: Sui published an open-source PR explaining plans to recover funds using aliasing mechanisms and whitelisting.
-
May 26: Sui initiated on-chain governance voting proposing whether to execute protocol upgrades to transfer hacker-held assets to custodial addresses.
-
May 29: Voting results released—over two-thirds of validator weight supported the proposal; protocol upgrade preparation commenced.
-
May 30 – early June: Protocol upgrade activated; designated transaction hashes executed, and hacker assets were “legally transferred away.”
2. Attack Mechanism
Industry experts have already published extensive analysis of the technical details. Here we provide only a core summary:
Attack flow overview:
The attacker first used flash loans to borrow about 10,024,321.28 haSUI, causing the pool price to crash by 99.90%. This massive sell order dropped the target pool price from roughly 1.8956×10^19 to 1.8425×10^19, nearly emptying the pool.
Next, the attacker created a liquidity position on Cetus within an extremely narrow range (tick lower bound 300000, upper bound 300200, range width only 1.00496621%). Such a narrow interval amplified the impact of computational errors on required token amounts.
The core vulnerability:
Lay in the integer overflow flaw within Cetus’ get_delta_a function used to calculate required token quantities. The attacker deliberately declared intent to add massive liquidity (~10^37 units) but contributed only one actual token to the contract.
Due to incorrect overflow detection conditions in checked_shlw, the system truncated high-order bits during left-shift calculations, severely underestimating the required amount of haSUI. As a result, the attacker acquired massive liquidity at minimal cost.
Technically, this vulnerability stemmed from Cetus using incorrect masks and conditional checks in Move smart contracts, allowing any value less than 0xffffffffffffffff << 192 to bypass validation. After a 64-bit left shift, higher data bits were truncated, leading the system to believe it had received enormous liquidity while collecting almost no tokens.
Following the event, two official actions emerged: "Freezing" vs. "Recovery"—representing two distinct phases:
-
Freezing phase achieved via Deny List + node consensus;
-
Recovery phase requiring protocol upgrade + community vote + execution of specified transactions bypassing blacklists.
3. Sui's Freezing Mechanism
Sui inherently features a special Deny List mechanism, which enabled the freezing of hacker funds in this incident. Moreover, Sui’s token standard includes a “regulated token” mode with built-in freezing capabilities.
The emergency freeze leveraged this feature: validators quickly added the stolen fund-related addresses into their local configuration files. In theory, each node operator could independently modify TransactionDenyConfig to update the deny list. However, to ensure network consistency, the Sui Foundation coordinated centrally as the original configuration issuer.
The foundation officially released an updated configuration containing the hacker addresses. Validators synchronized according to default settings, thereby temporarily "sealing" the hacker funds on-chain—a process revealing significant centralization behind the scenes.
To rescue victims from frozen funds, the Sui team promptly introduced a whitelist mechanism patch.
This was designed specifically for subsequent fund recovery operations. Legitimate transactions can be pre-constructed and registered on the whitelist, enabling forced execution even if the funding address remains blacklisted.
The new feature transaction_allow_list_skip_all_checks allows specific transactions to be pre-added to an "exempt list," letting them skip all security checks—including signature verification, permissions, and blacklist restrictions.
It should be noted that the whitelist patch cannot directly seize hacker assets. It merely grants certain transactions the ability to bypass freezes. Actual asset transfers still require valid signatures or additional system-level permission modules.
In contrast, mainstream industry freezing solutions typically occur at the token contract level and are controlled via multi-signature wallets managed by issuers.
For example, Tether’s USDT has a built-in blacklist function in its contract, allowing the issuing company to freeze违规addresses, preventing USDT transfers. This method requires initiating a freeze request on-chain through multi-sig consensus, resulting in execution delays due to coordination.
While effective, Tether’s freezing mechanism often suffers from statistical "windows of opportunity" during the multi-sig approval process, giving malicious actors room to act.
In comparison, Sui’s freezing occurs at the base protocol layer, executed collectively by validator nodes, making it significantly faster than regular contract calls.
This model requires fast execution, implying highly unified management among validator nodes themselves.
3. Implementation Principle of Sui's "Transfer-Based Recovery"
More astonishingly, Sui not only froze the hacker’s assets but also planned to "recover" stolen funds through a protocol upgrade.
On May 27, Cetus proposed a community voting plan requesting a protocol upgrade to send the frozen funds to a multi-signature custody wallet. The Sui Foundation promptly launched an on-chain governance vote.
On May 29, voting results showed approximately 90.9% of validator weight supported the proposal. Sui officially announced that once approved, “all funds frozen in the two hacker accounts would be recovered into a multi-sig wallet without requiring the hacker’s signature.”
No need for the hacker’s signature—this is an extraordinary characteristic. Never before has the blockchain industry seen such a recovery method.
According to Sui’s GitHub PR, the protocol introduced an address aliasing mechanism. Upgrade content included pre-specifying alias rules in ProtocolConfig so that permitted transactions could treat legitimate signatures as originating from hacker accounts.
Specifically, a list of rescue transaction hashes was bound to the target addresses (i.e., hacker addresses). Any executor signing and broadcasting these fixed transaction digests would be considered the legitimate owner of the hacker address initiating the transaction. For these specific transactions, validator nodes would bypass Deny List checks.
At the code level, Sui added the following logic to transaction validation: When a transaction is blocked by the blacklist, the system iterates over its signers and checks whether protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) returns true.
If any signer satisfies the alias rule, the transaction is marked as allowed, previous blocking errors are ignored, and normal packaging and execution proceed.
4. Perspectives
$160 Million Tears Open the Industry’s Deepest Foundational Belief
In my view, while the Cetus incident may fade quickly, this operational model won’t be forgotten—it fundamentally disrupts industry foundations and breaks the traditional consensus of immutability under a single ledger system.
In blockchain design, contracts are law, and code is the judge.
But in this incident, code failed, governance intervened, power prevailed—establishing a precedent where voting overrides code outcomes.
This direct transaction manipulation by Sui differs drastically from how mainstream blockchains handle hacking incidents.
This isn’t the first time consensus has been altered—but it’s the quietest
Historically:
-
Ethereum’s 2016 DAO incident involved a hard fork rollback to recover losses. That decision caused the split between Ethereum and Ethereum Classic, sparking intense controversy. Ultimately, different communities formed divergent belief systems.
-
The Bitcoin community also faced similar technical challenges: In 2010, a value overflow bug was urgently patched by developers who upgraded consensus rules, completely erasing around 18.4 billion illegally generated bitcoins.
Both cases followed the same hard fork pattern—rolling back ledgers to a state before the issue arose, leaving users free to choose which ledger version to continue using.
Compared to the DAO hard fork, Sui chose not to split the chain. Instead, it precisely targeted this incident through protocol upgrades and configuration aliasing. While maintaining chain continuity and preserving most consensus rules, this approach also demonstrates that the base protocol can be used to conduct targeted "rescue operations."
The key difference is: historical "fork-based rollbacks" let users choose their beliefs; Sui’s "protocol-level corrections" make decisions on behalf of the chain.
Not Your Key, Not Your Coin? Apparently, not anymore.
In the long run, this means the principle of “Not your keys, not your coins” is dismantled on Sui: even with fully intact private keys, the network can collectively alter protocols to block asset movement and redirect ownership.
If this becomes a precedent—or worse, an accepted norm—for how future blockchains respond to major security incidents,
“When a chain can break rules for justice, it sets a precedent for breaking any rule.”
Once a successful case of “public-interest robbery” exists, next time it might involve morally ambiguous interventions.
What happens then?
Hackers did steal users’ money—so can collective voting justify taking it back?
Does voting follow wealth (PoS) or headcount? If wealth wins, Liu Cixin’s vision of the ultimate property owner arrives swiftly. If majority rule prevails, mob mentality rises with deafening noise.
In traditional systems, illegal gains aren't protected—freezing and transferring assets are routine banking practices.
Yet isn't the very inability to do this technically what gave birth to the blockchain industry?
Now, with compliance pressures intensifying, today we freeze accounts and alter balances for hackers—tomorrow, could we do the same for geopolitical or ideological reasons? Could chains become regional tools?
If so, the industry’s value shrinks dramatically—reduced to nothing more than another clunkier financial system.
This is precisely why I remain committed to the industry: “Blockchain isn’t valuable because it can’t be frozen—it’s valuable because even if you hate it, it refuses to change for you.”
As regulation becomes inevitable, can chains preserve their soul?
Consortium chains once outshone public chains because they satisfied regulatory demands of their time. Their current decline signifies that merely meeting such demands doesn't equate to fulfilling genuine user needs. Without regulated users, why maintain regulatory tools?
From an Industry Development Perspective
Is efficient centralization a necessary stage in blockchain evolution? If the ultimate goal of decentralization is to protect user interests, can we tolerate centralization as a transitional measure?
The word “democracy” in on-chain governance is actually token-weighted. What if hackers hold large amounts of SUI (or one day hack a DAO and gain voting power)? Could they legally vote to legitimize themselves?
In the end, the value of blockchain lies not in whether freezing is possible, but in choosing not to freeze—even when the power to do so exists.
A chain’s future isn’t determined by its technical architecture, but by the set of beliefs it chooses to uphold.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
