Analysis: How Did Sui Freeze $160M from a Hacker?

By Haotian

Translation WuBlockchain

Original link:

https://x.com/tmel0211/status/1925736378131751224?t=DQGIBGZEnTEaVGg9XvvCew&s=19

Many people are puzzled: after Sui officially stated that @CetusProtocol was hacked, it claimed that validators coordinated to “freeze” the hacker’s address, recovering $160 million. But how exactly was this achieved? Is decentralization just an “illusion”? Let’s try to analyze this from a technical perspective:

Assets Transferred via Cross-Chain Bridges:

After the successful attack, the hacker immediately moved part of the USDC and other assets to Ethereum and other chains via cross-chain bridges. These funds are unrecoverable — once outside the Sui ecosystem, validators are powerless.

Assets Still on the Sui Chain:

A significant portion of the stolen funds remained in Sui addresses controlled by the hacker. These on-chain assets became the target of the “freeze.”

According to the official announcement, “a large number of validators identified the stolen fund addresses and are ignoring transactions from those addresses.”

So — how is this technically implemented?

1. Validator-Level Transaction Filtering — In Simple Terms, Validators Pretend to Be Blind:

● Validators ignore transactions from hacker addresses at the mempool stage.

● These transactions are technically valid but simply never get included in blocks.

● As a result, the hacker’s funds are effectively “soft-frozen” at the address level.

2. Key Mechanism in Move’s Object Model — Enabling Freezing:

● Transfers Must Be On-Chain: Even though the hacker controls addresses with large amounts of USDC, SUI, and other assets, transferring these objects requires creating a transaction and getting it packaged by validators.

● Validators Hold the Power: If validators refuse to package the transaction, the asset can never move.

● Outcome: The hacker technically “owns” the funds but is completely powerless to move them.

It’s like having a bank card that all ATMs refuse to recognize. The money is “there,” but you can’t withdraw it. With continuous validator surveillance and intervention (like ATM denial), tokens like SUI in the hacker’s address are rendered illiquid — effectively burned — which may even result in a deflationary effect?

System-Level Support?

Beyond temporary coordination, Sui may also have a built-in denylist mechanism at the protocol level. If so, the process might be:

● An authorized entity (like the Sui Foundation or through governance) adds the hacker’s address to a system denylist.

● Validators, following protocol rules, automatically reject transactions from these addresses.

Whether by ad hoc coordination or protocol rule enforcement, most validators must act in unison. Clearly, Sui’s validator network remains overly centralized — just a few nodes can steer key network decisions.

This isn’t unique to Sui — most PoS chains, from Ethereum to BSC, face similar validator centralization risks. Sui’s case just makes the problem more visible.

But Wait — How Can a “Decentralized” Chain Freeze Assets So Easily?

Even more concerning: Sui stated it intends to return the frozen funds to the pool. But if validators are merely refusing to package transactions, the assets should be permanently unmovable. So how does Sui manage to return them?

This raises deeper questions:

Could it be that beyond validator-level refusal, there’s a centralized authority with protocol-level superpowers that can reassign asset ownership? (We need further details from Sui on the freezing mechanism.)

Before More Details Are Disclosed — Let’s Discuss the Tradeoff

Is sacrificing a bit of decentralization for emergency incident response always a bad thing? When under attack, would users really want a chain that does nothing?

Certainly, no one wants hackers to get away with stolen funds. But the real concern is this:

● The freeze standard is entirely subjective — What defines “stolen funds”? Who decides? Where is the line?

● Today it’s a hacker; who gets frozen tomorrow?

Once such a precedent is set, a public chain’s most core value — censorship resistance — is fundamentally undermined, damaging long-term user trust.

Decentralization is not black and white. Sui has chosen a specific balance between user protection and decentralization. The key issue is a lack of transparent governance and clear criteria.

Most blockchains are navigating similar tradeoffs today. But users deserve the truth — not a misleading “fully decentralized” label.

Other Perspectives

By: @0x_Todd

Original Link:

https://x.com/0x_Todd/status/1925819908434059659?t=NAfGq0iNz-qjYZwqjV1daA&s=19

Curious Case of SUI’s Freeze Function — How Is the Blacklist Implemented and What’s the New Whitelist Patch For?

1. How is the freeze implemented?

To start, SUI has always had a built-in feature called the Deny List — a blacklist mechanism that blocks any transaction involving listed addresses.

Because this feature already existed in the client, SUI was able to immediately freeze the hacker’s address. Without it, even though SUI only has 113 validators, it would have been too late for Cetus to call them one by one.

SUI didn’t suddenly become a centralized chain yesterday — it has always been centralized, at least since the introduction of the blacklist feature.

2. Who has the power to change the blacklist?

In theory, the TransactionDenyConfig is a YAML/TOML config file locally loaded by each validator.

Anyone running a node can edit this file, hot-reload or restart the node, and update the list. On the surface, it looks like each validator is freely expressing their own values.

But — you know what I’m about to say.

In reality, for consistency and the effectiveness of security policies, updates to this kind of critical configuration are usually coordinated.

That coordination is where centralization creeps in.

Since this is an “emergency update pushed by the SUI team,” it’s essentially Sui Foundation (or its authorized developers) who set and update this deny list.

Sui officials publish the blacklist, and validators theoretically choose whether to adopt it — but in practice, from what I know, most do so automatically by default.

So while this feature protected user funds, it is undeniably centralized in nature.

Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish