Firm Belief After a Security Crisis: Why SUI Still Has Long-Term Rise Potential?

1. A chain reaction triggered by an attack

On May 22, 2025, the leading AMM protocol Cetus deployed on the SUI network suffered a hacker attack. The attackers exploited a logical vulnerability related to the "integer overflow issue" to carry out precise manipulation, resulting in a loss of over $200 million in assets. This incident is not only one of the largest security incidents in the DeFi space so far this year but has also become the most destructive hacker attack since the launch of the SUI mainnet.

According to DefiLlama data, the total TVL of SUI on the entire chain plummeted by over $330 million on the day of the attack, and the locked amount of the Cetus protocol itself evaporated by 84% in an instant, dropping to $38 million. As a result, several popular tokens on SUI (including Lofi, Sudeng, Squirtle, etc.) plummeted by 76% to 97% within just one hour, triggering widespread concern in the market regarding the security and ecological stability of SUI.

However, after this shockwave, the SUI ecosystem has demonstrated strong resilience and recovery capability. Despite the Cetus incident causing fluctuations in confidence in the short term, on-chain funds and user activity have not experienced a sustained decline, but instead have significantly increased the entire ecosystem's focus on security, infrastructure development, and project quality.

2. Analysis of the Causes of the Cetus Incident Attack

2.1 Attack Implementation Process

According to the technical analysis of the Cetus attack incident by the Slow Fog team, the hacker successfully exploited a critical arithmetic overflow vulnerability in the protocol, using flash loans, precise price manipulation, and contract flaws to steal over $200 million in digital assets in a short period of time. The attack path can be roughly divided into the following three stages:

①Initiate a flash loan, manipulate the price

The hacker first utilized a maximum slippage flash swap of 10 billion haSUI through a flash loan, borrowing a large amount of funds to manipulate the price.

Flash loans allow users to borrow and repay funds within the same transaction, requiring only a fee, and feature high leverage, low risk, and low cost. Hackers exploited this mechanism to temporarily drive down market prices, precisely controlling them within a very narrow range.

The attacker then prepared to create an extremely narrow liquidity position, precisely setting the price range between the lowest bid of 300,000 and the highest price of 300,200, with a price width of only 1.00496621%.

By the above means, hackers successfully manipulated the haSUI price using a sufficient amount of tokens and massive liquidity. Subsequently, they also targeted several tokens with no actual value for manipulation.

②Add liquidity

The attacker creates a narrow liquidity position, claiming to add liquidity, but due to a vulnerability in the checked_shlw function, ultimately only receives 1 token.

This is essentially due to two reasons:

1. The mask setting is too wide: it is equivalent to a very large liquidity addition limit, resulting in the validation of user inputs in the contract being meaningless. Hackers bypassed overflow detection by setting abnormal parameters, constructing inputs that are always less than this limit.

2. Data overflow was truncated: When performing the shift operation n << 64 on the numeric value n, data truncation occurred because the shift exceeded the effective bit width of the uint256 data type (256 bits). The overflow portion was automatically discarded, resulting in a calculated outcome that was far lower than expected, causing the system to underestimate the amount of haSUI required for the exchange. The final calculated result was about less than 1, but since it was rounded up, the final result equaled 1, meaning the hacker only needed to add 1 token to exchange for a huge amount of liquidity.

③Withdraw liquidity

Repay the flash loan and retain a large profit. Finally, withdraw token assets worth hundreds of millions of dollars from multiple liquidity pools.

The situation of fund loss is serious, and the attack resulted in the following assets being stolen:

• 12.9 million SUI (approximately 54 million USD)

• 60 million USDC

• 4.9 million USD Haedal Staked SUI

• 19.5 million US dollars TOILET

• Other tokens such as HIPPO and LOFI have dropped 75--80%, with liquidity exhausted.

2.2 Causes and Characteristics of This Vulnerability

The vulnerability of Cetus has three characteristics:

1. The cost of fixing is extremely low: on one hand, the root cause of the Cetus incident is a flaw in the Cetus math library, not an error in the protocol's pricing mechanism or underlying architecture. On the other hand, the vulnerability is limited to Cetus itself and is unrelated to the SUI code. The root of the vulnerability lies in a boundary condition check, and only two lines of code need to be modified to completely eliminate the risk; once the fix is completed, it can be immediately deployed to the mainnet to ensure that subsequent contract logic is complete and to eliminate this vulnerability.

2. High Concealment: The contract has been running smoothly for two years with zero failures. The Cetus Protocol has undergone multiple audits, but no vulnerabilities have been found, mainly because the Integer_Mate library used for mathematical calculations was not included in the audit scope.

Hackers exploit extreme values to precisely construct trading intervals, creating extremely rare scenarios with extremely high liquidity that trigger abnormal logic, indicating that such issues are difficult to detect through ordinary testing. These problems often lie in blind spots in people's view, which is why they remain hidden for a long time before being discovered.

3. Not a problem unique to Move:

Move outperforms various smart contract languages in resource safety and type checking, with built-in native detection for integer overflow issues in common scenarios. This overflow occurred because, when adding liquidity, the wrong value was first used for the upper limit check while calculating the required token amount, and a bitwise operation was used instead of the conventional multiplication operation. In Move, if conventional addition, subtraction, multiplication, and division operations are used, overflow conditions are checked automatically, thus avoiding this high-bit truncation problem.

Similar vulnerabilities have also appeared in other languages (such as Solidity and Rust), and they are even easier to exploit due to the lack of integer overflow protection; prior to updates in Solidity versions, overflow checks were very weak. Historically, there have been addition overflows, subtraction overflows, and multiplication overflows, all directly caused by the computation results exceeding the limits. For example, vulnerabilities in the BEC and SMT smart contracts of the Solidity language were exploited by carefully crafted parameters that bypassed the detection statements in the contracts, resulting in excessive transfers to execute the attack.

3. The consensus mechanism of SUI

3.1 Introduction to the SUI Consensus Mechanism

Overview:

SUI adopts a Delegated Proof of Stake framework (DeleGated Proof of Stake, abbreviated as DPoS). Although the DPoS mechanism can improve transaction throughput, it cannot provide the extremely high level of decentralization like PoW (Proof of Work). Therefore, the level of decentralization of SUI is relatively low, and the governance threshold is relatively high, making it difficult for ordinary users to directly influence network governance.

• Average number of validators: 106

• Average Epoch Duration: 24 hours

Mechanism process:

• Delegated Rights: Ordinary users do not need to run nodes themselves; they can participate in network security assurance and reward distribution by staking SUI and delegating it to candidate validators. This mechanism lowers the participation threshold for ordinary users, allowing them to engage in network consensus by "hiring" trusted validators. This is also a significant advantage of DPoS over traditional PoS.

• Representative round block generation: A small number of selected validators produce blocks in a fixed or random order, which improves confirmation speed and increases TPS.

• Dynamic Elections: After each voting period, based on voting weight, a dynamic rotation is conducted to re-elect the Validator set, ensuring node vitality, interest consistency, and decentralization.

Advantages of DPoS:

• High efficiency: Due to the controllable number of block-producing nodes, the network can achieve confirmation in milliseconds, meeting high TPS requirements.

• Low cost: Fewer nodes participating in consensus significantly reduce the network bandwidth and computing resources required for information synchronization and signature aggregation. This leads to a decrease in hardware and operational costs, lower computational power requirements, and reduced costs. Ultimately, this achieves lower user transaction fees.

• High security: The staking and delegation mechanisms amplify the cost and risk of attacks; combined with the on-chain confiscation mechanism, it effectively suppresses malicious behavior.

At the same time, in the consensus mechanism of SUI, an algorithm based on BFT (Byzantine Fault Tolerance) is used, requiring more than two-thirds of the votes from validators to reach a consensus in order to confirm transactions. This mechanism ensures that even if a minority of nodes behave maliciously, the network can still operate securely and efficiently. Any upgrades or major decisions also require more than two-thirds of the votes to be implemented.

Essentially, DPoS is a compromise solution to the "impossible triangle," balancing decentralization and efficiency. In the security-decentralization-scalability "impossible triangle," DPoS chooses to reduce the number of active producing nodes in exchange for higher performance, sacrificing a certain degree of complete decentralization compared to pure PoS or PoW, but significantly improving network throughput and transaction speed.

3.2 The performance of SUI in this attack

3.2.1 Operation of the Freezing Mechanism

In this incident, SUI quickly froze the addresses related to the attacker.

From a code perspective, it prevents transfer transactions from being packed on-chain. The validating nodes are the core components of the SUI blockchain, responsible for validating transactions and executing protocol rules. By collectively ignoring transactions related to the attacker, these validators essentially implement a mechanism similar to 'account freezing' in traditional finance at the consensus level.

SUI has a built-in deny list mechanism, which is a blacklist feature that can prevent any transactions involving listed addresses. Since this feature already exists in the client, when an attack occurs,

SUI can immediately freeze the hacker's address. Without this function, even if SUI has only 113 validators, it would be difficult for Cetus to coordinate all validators to respond one by one in a short time.

3.2.2 Who has the authority to modify the blacklist?

TransactionDenyConfig is a YAML/TOML configuration file loaded locally 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 seems that each validator is freely expressing their own values.

In fact, for the consistency and effectiveness of the security policy, updates to this critical configuration are usually coordinated. Since this is an "emergency update driven by the SUI team", it is essentially the SUI Foundation (or its authorized developers) that sets and updates this deny list.

SUI has released a blacklist, and in theory, validators can choose whether to adopt it------but in practice, most people will automatically adopt it by default. Therefore, while this feature protects user funds, it does have a certain degree of centralization in its essence.

3.2.3 The Essence of the Blacklist Function

The blacklist function is not actually a logic at the protocol level; it is more like an additional layer of security to respond to emergencies and ensure the safety of user funds.

Essentially, it is a security assurance mechanism. Similar to a "security chain" attached to a door, it is activated only for those who intend to intrude, that is, for those who would act maliciously against the protocol. For users:

• For large investors, the main providers of liquidity, the protocol aims to ensure the safety of funds, as the on-chain data TVL is largely contributed by these major investors. To achieve long-term development of the protocol, ensuring safety will undoubtedly be the top priority.

• For retail investors, contributors to ecological activity, and strong supporters of technology and community co-construction. The project party also hopes to attract retail investors to co-build, so as to gradually improve the ecology and enhance retention rates. As for the DeFi field, the top priority is still the security of funds.

The key to determining "whether it is decentralized" should be whether users have control over their assets. In this regard, SUI leverages Move to compile.