Firm Belief After the 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 attacker exploited a logical vulnerability related to the "integer overflow issue" to execute 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 also the most destructive hacker attack since the launch of the SUI mainnet.

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

However, after this shock wave, the SUI ecosystem has demonstrated strong resilience and recovery capability. Although the Cetus incident caused fluctuations in confidence in the short term, on-chain funds and user activity did not experience a sustained decline, but rather prompted the entire ecosystem to significantly increase its 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 Mist team, hackers 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 flash loans to manipulate prices

Hackers first exploited a maximum slippage flash exchange of 10 billion haSUI through a flash loan, borrowing a large amount of capital to manipulate prices.

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

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

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

② Add liquidity

Attackers create narrow liquidity positions, claiming to add liquidity, but due to the vulnerability in the checked_shlw function, they ultimately only receive 1 token.

Essentially due to two reasons:

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

2. Data overflow is truncated: When performing the shift operation n << 64 on the numeric value n, data truncation occurs because the shift exceeds the effective bit width of the uint256 data type (256 bits). The high-order overflow part is automatically discarded, resulting in a computation result that is far lower than expected, causing the system to underestimate the amount of haSUI required for the exchange. The final computed result is approximately less than 1, but due to rounding up, it ultimately equals 1, meaning the hacker only needs to add 1 token to exchange for a large amount of liquidity.

③Withdraw liquidity

Repay the flash loan and retain huge profits. Ultimately withdraw token assets worth hundreds of millions of dollars from multiple liquidity pools.

The situation regarding fund losses is serious, the attack led to the theft of the following assets:

• 12.9 million SUI (approximately 54 million USD)
• 60 million USDC
• 4.9 million USD Haedal Staked SUI
• 19.5 million dollars TOILET
• Other tokens like HIPPO and LOFI have fallen by 75-80%, with liquidity exhausted.

2.2 The 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, and 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 not related 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, ensuring that the subsequent contract logic is complete and eliminating this vulnerability.

2. High Concealment: The contract has been running smoothly for two years with zero faults. The Cetus Protocol has undergone multiple audits, but no vulnerabilities have been found. The main reason is that 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 issues often exist in blind spots in people's vision, which is why they remain hidden for a long time before being discovered.

3. Not an issue unique to Move:

Move excels in resource safety and type checking compared to various smart contract languages, featuring native detection for integer overflow issues in common scenarios. This overflow occurred because an incorrect value was first used for the upper limit check when calculating the required token amount for adding liquidity, and bitwise operations were used instead of regular multiplication. In Move, regular addition, subtraction, multiplication, and division operations automatically check for overflow situations, preventing such high-bit truncation issues.

Similar vulnerabilities have also appeared in other languages (such as Solidity and Rust), and are even more easily exploited due to their lack of integer overflow protection; before the updates to Solidity, the checks for overflow were very weak. Historically, there have been addition overflows, subtraction overflows, multiplication overflows, etc., with the direct cause being that the result of the calculation exceeded the range. For example, vulnerabilities in the BEC and SMT smart contracts of the Solidity language were exploited by carefully constructed parameters that bypassed the detection statements in the contracts to achieve excessive transfers.

3. The consensus mechanism of SUI

Introduction to the SUI consensus mechanism 3.1

Overview:

SUI adopts a Delegated Proof of Stake framework (DeleGated Proof of Stake, abbreviated as DPoS)). Although the DPoS mechanism can increase transaction throughput, it cannot provide the same level of decentralization as PoW (Proof of Work). Therefore, the level of decentralization in 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:

• Equity Delegation: 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 compared to traditional PoS.

• Representative round of block production: A few selected validators produce blocks in a fixed or random order, improving the confirmation speed and increasing the TPS.

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

Advantages of DPoS:

• High Efficiency: With a controllable number of block-producing nodes, the network can achieve confirmation in milliseconds, meeting high TPS requirements.

• Low cost: Fewer nodes participate in the consensus, significantly reducing the network bandwidth and computing resources required for information synchronization and signature aggregation. As a result, hardware and operational costs decrease, the requirements for computing power diminish, and costs are lower. Ultimately, this leads to lower user transaction fees.

• High security: The staking and delegation mechanism synchronizes 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 adopted, requiring more than two-thirds of the votes among validators to reach a consensus in order to confirm transactions. This mechanism ensures that even if a minority of nodes act maliciously, the network can remain secure and operate 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 "impossible triangle" of security-decentralization-scalability, DPoS chooses to reduce the number of active block-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 The 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 packaged on-chain. Validator 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 effectively implement a mechanism similar to 'account freezing' in traditional finance at the consensus level.

SUI itself has a built-in deny list mechanism, which is a blacklist feature that can prevent any transactions involving listed addresses. Since this feature is already present 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 period of time.

3.2.2 Who has the power to change the blacklist?

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

In fact, for the consistency and effectiveness of security policies, updates to this critical configuration are usually coordinated. Since this is an "urgent update pushed by the SUI team", it is basically the SUI Foundation (or its authorized developers) that set and update this denial list.

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

3.2.3 The essence of the blacklist function

The blacklist feature is not actually a logic at the protocol level; it is more like an additional security measure to cope with emergencies and ensure the safety of user funds.

It is essentially a security guarantee mechanism. Similar to a "security chain" tied to a door, it is only activated for those who want to invade the home, that is, for those who intend to maliciously act against the protocol. For users:

• For large holders, the main providers of liquidity, the protocol aims to ensure the security of funds, since in reality, the on-chain data TVL is entirely contributed by major holders. To ensure the long-term development of the protocol, it must prioritize security.

• For retail investors, contributors to ecological activity, and strong supporters of technology and community co-construction. The project team 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 most important thing is still the safety of funds.

The key to determining "whether it is decentralized" should be whether users have control over their assets. In this regard, SUI embodies its commitment to user assets through the Move programming language.