🎉 The #CandyDrop Futures Challenge is live — join now to share a 6 BTC prize pool!
📢 Post your futures trading experience on Gate Square with the event hashtag — $25 × 20 rewards are waiting!
🎁 $500 in futures trial vouchers up for grabs — 20 standout posts will win!
📅 Event Period: August 1, 2025, 15:00 – August 15, 2025, 19:00 (UTC+8)
👉 Event Link: https://www.gate.com/candy-drop/detail/BTC-98
Dare to trade. Dare to win.
The Sui incident has sparked a battle of beliefs in the Blockchain industry: the concept of Decentralization faces significant challenges.
The Faith Controversy in the Blockchain Industry: In-depth Reflections Triggered by the Sui Incident
Introduction
The recent events are actually a victory for capital, rather than a victory for users, and they seem more like a regression for the development of the industry.
Bitcoin and Sui are heading in completely different directions. Whenever there are industry moves that shake decentralization, it triggers people's faith in Bitcoin to become even stronger.
The world needs not just a better global financial infrastructure, but more importantly, it must always reserve a space for freedom for some people.
Looking back, consortium blockchains were once more popular than public blockchains, primarily because they met the regulatory needs of the time. Today, the decline of consortium blockchains precisely illustrates that merely complying with regulatory demands does not satisfy the real needs of users. If regulated users are lost, what is the point of having regulatory tools?
1. Event Review
On May 22, 2025, the largest decentralized exchange in a certain public chain ecosystem was attacked by hackers, resulting in an instant decrease in liquidity and a collapse in the prices of various trading pairs, with losses exceeding $220 million.
The timeline of events is as follows:
On the morning of May 22, hackers attacked a certain DEX, siphoning off $230 million. The DEX urgently suspended contracts and issued an announcement.
On the afternoon of May 22, hackers transferred approximately $60 million across chains, while the remaining $162 million is still in the original chain address. Verification nodes quickly took action, adding the hacker's address to the "deny service blacklist" and freezing the funds.
On the evening of May 22, an executive from a certain public blockchain confirmed: the funds have been frozen, and the refund process will begin soon.
On May 23, a certain DEX began to fix vulnerabilities and update contracts.
On May 24th, a certain public blockchain open-sourced a PR, explaining that it will soon recover funds through an alias mechanism and a whitelist.
On May 26, a certain public blockchain initiated an on-chain governance vote to propose whether to implement a protocol upgrade and transfer the hacker's assets to a custody address.
On May 29, the voting results were announced, with more than 2/3 of the validation node weight in support; the protocol upgrade is ready to be executed.
From May 30 to early June, the protocol upgrade took effect, and the designated transaction hash was executed, resulting in the hacker's assets being 'legally transferred'.
2. Attack Principles
The attacker first used a flash loan to borrow a large number of tokens, instantly causing the price of the trading pool to drop by 99.90%. This massive sell order caused the target pool price to fall from about 1.8956×10^19 to 1.8425×10^19, nearly bottoming out.
Subsequently, the attacker created liquidity positions on the DEX within an extremely narrow range. Such a narrow range amplifies the impact of subsequent calculation errors on the required number of tokens.
The core principle of the attack lies in the integer overflow vulnerability present in the function used by the DEX to calculate the required number of tokens. The attacker intentionally claims to add a huge liquidity (about 10^37 units), but actually only invests 1 token into the contract.
Due to an error in the overflow detection condition, the contract experienced a high-order truncation during the left shift calculation, causing the system to severely underestimate the required amount of tokens, thereby obtaining a massive amount of liquidity at a minimal cost.
Technically, the aforementioned vulnerability originates from the DEX using incorrect masks and conditional checks in the smart contract, allowing any value less than 0xffffffffffffffff << 192 to bypass detection; while the high-order data is truncated after a left shift of 64 bits, the system only collects a minimal amount of tokens and considers it to have obtained significant liquidity.
After the incident occurred, the authorities took two stages of operation: "freeze" and "recover":
The freezing phase relies on blacklists and node consensus to be completed. The recovery phase requires an on-chain protocol upgrade, community voting, and executing specific transactions to bypass the blacklist.
3. Freezing Mechanism
A certain public blockchain has a special blacklist mechanism that has implemented the freezing of funds in this hacking incident. Not only that, but the token standard of this blockchain also has a "regulated token" model with a built-in freezing function.
The emergency freeze utilized this feature: validator nodes quickly added addresses related to the stolen funds in their local configuration files. In theory, each node operator can modify the configuration to update the blacklist, but to ensure network consistency, the foundation, as the original configuration publisher, coordinated centrally.
The foundation first officially released a configuration update containing the hacker's address, allowing validators to synchronize and take effect according to the default configuration, thus temporarily "sealing" the hacker's funds on-chain. Behind this, there are actually highly centralized factors.
To rescue victims from frozen funds, the public blockchain team immediately launched a whitelist mechanism patch. This is aimed at the operation of subsequently reversing the funds. Legal transactions can be pre-constructed and registered on the whitelist, allowing enforcement even if the fund address is still on the blacklist.
This new feature allows specific transactions to be pre-added to the "whitelist", enabling these transactions to bypass all security checks, including signatures, permissions, blacklists, and more.
It is important to note that the whitelist patch does not directly seize hacker assets; it merely grants certain transactions the ability to bypass freezing, and the actual asset transfer still requires legal signatures or additional system permission modules to complete.
In contrast, the freezing of this public chain occurs at the underlying protocol level, operated collectively by validator nodes, with execution speeds far exceeding those of ordinary contract calls. In this model, to execute quickly means that the management of these validator nodes is highly unified.
4. The Principle of "Transfer-based Recycling"
What's even more surprising is that this public chain not only froze the hacker's assets but also plans to "transfer recovery" of the stolen funds through an on-chain upgrade.
On May 27th, a certain DEX proposed a community voting plan, requesting to upgrade the protocol and transfer the frozen funds to a multi-signature escrow wallet. The public chain foundation then 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. The official announcement stated that once the proposal is approved, "all funds frozen in the two hacker accounts will be retrieved into a multi-signature wallet without the need for hacker signatures."
No hacker signatures are required, this is a very special feature, and the blockchain industry has never had such a fix before.
From the official GitHub PR, it can be seen that the protocol has introduced an address aliasing mechanism. The upgrade includes: pre-specifying alias rules in the protocol configuration, allowing certain permitted transactions to consider valid signatures as being sent from hacker accounts.
Specifically, the hash list of the rescue transactions 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 regarded as a valid owner of the hacker address initiating the transaction. For these specific transactions, the validator node system will bypass the blacklist check.
From a code perspective, this public blockchain has added new criteria in its transaction validation 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 alias rules, this transaction is marked as allowed to pass, ignoring the previous interception error, and continues to be packaged and executed normally.
5. Opinion
$160 million, tearing apart the deepest underlying beliefs in the industry.
Although the storm from this incident may pass quickly, this handling model will not be forgotten, as it undermines the foundation of the industry and breaks the traditional consensus of immutability of 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 model of "voting behavior adjudicating code results."
It is precisely because this public chain's direct appropriation of transactions is vastly different from the way mainstream blockchains handle hacker issues.
This is not the first time "tampering with consensus", but it is the quietest one.
Historically:
A major event in a well-known public blockchain in 2016 involved rolling back transactions through a hard fork to compensate for losses, but this decision led to a split in the chain, a process that was highly controversial, ultimately resulting in different groups forming their own consensus beliefs.
The Bitcoin community 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 18.4 billion illegally generated Bitcoins.
These all adopt a hard fork model, rolling back the ledger to before the issue occurred, after which users can decide for themselves which ledger system to continue using.
Compared to the aforementioned hard fork, this public chain did not choose to split the chain but instead precisely targeted this event through protocol upgrades and the configuration of aliases. By doing so, this public chain maintained the continuity of the chain and the majority of consensus rules unchanged, but it also indicates that the underlying protocol can be used to implement targeted "rescue operations."
The problem is that historically, "forked rollbacks" were a choice made by users; while the "protocol-based corrections" of this public chain make decisions on behalf of the users.
"Not your private key, not your coins"? I'm afraid it no longer applies.
In the long run, this means that the concept of "not your private key, not your coins" is dismantled on this public blockchain: even if users' private keys are intact, the network can still prevent asset movement and redirect assets through collective protocol changes.
If this becomes a precedent for the future Blockchain to respond to major security incidents, and is even considered a practice 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 success in "public welfare money grabbing", the next time it may be an operation in the "moral gray area".
What will happen?
If hackers really stole the users' money, can a collective vote take away his money?
Is the voting based on who has more money (POS) or more people? If the one with more money wins, then the final producers described by Liu Cixin will soon arrive; if the one with more people wins, then the clamor of the mob will also rise again.
In traditional systems, it is normal for illegal gains to be unprotected, and freezing and transfer are routine operations of traditional banks. But isn't the inability to do this from a technical theory perspective the root of the development of the Blockchain industry?
The industry's compliance stick is continuously fermenting. Today, it can freeze and modify account balances for hackers, and tomorrow, it can make arbitrary modifications due to geopolitical factors and conflicting elements. If the blockchain becomes a regional tool, then the value of the industry will be significantly compressed, at best becoming another less usable financial system.
This is also the reason why I firmly believe in the industry: "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 inevitable, can the blockchain hold on to its own soul?
Once upon a time, consortium chains were more popular than public chains because they met the regulatory needs of that era. The decline of consortium chains today actually means that simply complying with this demand is not the real need of users. If regulated users are lost, is there still a need for regulatory tools?
From the perspective of industry development, is "efficient centralization" 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 a DAO is hacked and the hacker controls the voting power), can they also "legally vote to whitewash themselves"?
Ultimately, the value of the 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 not determined by the technological architecture, but by the set of beliefs it chooses to uphold.