
Why was Sui able to freeze $160 million stolen by hackers?
TechFlow Selected TechFlow Selected

Why was Sui able to freeze $160 million stolen by hackers?
Decentralization is not black and white; Sui has chosen a specific balance point between user protection and decentralization.
Author: Haotian
Many people are puzzled: after Sui officially announced that @CetusProtocol was hacked, the validator network coordinated to "freeze" the hacker's address and recovered $160 million. How exactly was this achieved? Is decentralization a "lie"? Below is a technical analysis:
Cross-chain bridge transfers: After the attack succeeded, the hacker immediately transferred part of the assets such as USDC to other chains like Ethereum via cross-chain bridges. These funds can no longer be recovered, because once they leave the Sui ecosystem, validators have no power over them.
Funds still on the Sui chain: A significant amount of stolen funds remains in Sui addresses controlled by the hacker. This portion became the target of the "freeze".
According to the official announcement, "a large number of validators identified the stolen fund addresses and are now ignoring transactions from these addresses."
——How was this specifically implemented?
1. Transaction filtering at the validator level——in simple terms, validators collectively "pretend not to see":
-
Validators directly ignore transactions from the hacker's address at the transaction pool (mempool) stage;
-
These transactions are technically valid, but simply won't be included in blocks;
-
The hacker's funds are thus "soft-imprisoned" within the address;
2. Key mechanism of the Move object model——the Move language's object model makes such "freezing" feasible:
-
Transfers must go on-chain: although the hacker controls a large amount of assets in the Sui address, to transfer objects like USDC or SUI, a transaction must be initiated and packaged/confirmed by validators;
-
Validators hold life-and-death power: if validators refuse to package, the objects cannot move at all;
-
Result: the hacker nominally "owns" these assets but is completely powerless in practice.
It's like having a bank card, but every ATM refuses to serve you. The money is on the card, but you can't withdraw it. With continuous monitoring and intervention by SUI validator nodes (ATMs), tokens such as SUI in the hacker's address become non-transferable—effectively rendered as if "burned", objectively creating a deflationary effect?
Of course, beyond temporary coordination among validators, Sui may have preconfigured a deny list function at the system level. If so, the process might be: authorized parties (such as the Sui Foundation or through governance) add the hacker's address to a system-level deny_list, and validators enforce this rule by rejecting transactions from blacklisted addresses.
Whether through temporary coordination or execution based on system rules, it requires most validators to act in unison. Clearly, Sui's validator network remains overly centralized, with a small number of nodes capable of controlling key decisions across the entire network.
Sui's validator centralization issue is not an isolated case among PoS chains——from Ethereum to BSC, most PoS networks face similar risks of validator concentration; Sui simply exposed the problem more visibly.
——How can a supposedly decentralized network possess such strong centralized "freezing" capability?
More critically, Sui officials stated they plan to return the frozen funds to the pool. But if the freeze relies solely on validators refusing to include transactions, these funds should theoretically remain permanently immovable. How then does Sui intend to return them? This further challenges the decentralization claims of the Sui blockchain!
Could it be that beyond just a few centralized validators refusing transactions, the official team possesses system-level superuser privileges allowing direct modification of asset ownership? (Sui needs to provide further details on the freezing mechanism)
Prior to disclosure of specific details, it's necessary to discuss the trade-offs around decentralization:
Is emergency intervention, sacrificing some degree of decentralization, necessarily bad? Would users prefer a chain that stands idle during a hack?
The point is, naturally no one wants funds to fall into hackers' hands. But what worries the market more is that the freezing criteria become entirely "subjective": What counts as "stolen funds"? Who defines it? Where is the boundary? If we freeze hackers today, who will be frozen tomorrow? Once such precedent is set, the core censorship-resistant value of public blockchains collapses entirely, inevitably damaging user trust.
Decentralization isn't black and white. Sui has chosen a particular balance point between user protection and decentralization. The critical flaw lies in the lack of transparent governance mechanisms and clear boundary standards.
Most blockchain projects today make similar trade-offs, but users have the right to know the truth, rather than being misled by labels like "fully decentralized".
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














