Firm Belief After a Security Crisis: Why Does SUI Still Have 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 carry out precise manipulation, resulting in losses of over $200 million in assets. This incident is not only one of the largest security incidents in the DeFi sector 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 SUI across the entire chain plummeted by more than $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 fell by 76% to 97% within just one hour, sparking widespread concern in the market about the safety and ecological stability of SUI.

However, after this shockwave, 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; rather, it significantly prompted the entire ecosystem to enhance its focus on security, infrastructure development, and project quality.

Klein Labs will analyze the reasons behind this attack incident, the node consensus mechanism of SUI, the security of the MOVE language, and the ecological development of SUI, to outline the current ecological pattern of this public chain, which is still in the early stages of development, and discuss its future development potential.

2. Analysis of the Causes of the Cetus Incident

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, utilizing 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 exploited the maximum slippage to swap 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 lower market prices and precisely control 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 quote of 300,000 and the highest price of 300,200, with a price width of only 1.00496621%.

By using the above methods, hackers successfully manipulated the haSUI price with 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, claims 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 is set too wide: equivalent to a very large liquidity addition limit, resulting in ineffective validation of user input in the contract. 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 numerical value n, data truncation occurs because the shift exceeds the valid bit width of the uint256 data type (256 bits). The overflow part in the high bits is automatically discarded, resulting in a calculation that is far below expectations, thus causing the system to underestimate the amount of haSUI needed for the exchange. The final calculated result is approximately less than 1, but due to rounding up, the final result equals 1, meaning the hacker only needs to add 1 token to exchange for a huge amount of liquidity.

③Withdraw liquidity

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

The situation of fund losses is severe, and the attack resulted in 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 USD TOILET

• Other tokens such as HIPPO and LOFI have dropped 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, rather than an error in the protocol's pricing mechanism or underlying architecture. On the other hand, the vulnerability is limited to Cetus itself and has nothing to do with 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 the subsequent contract logic is complete and to eliminate this vulnerability.

2. High Concealment: The contract has been operating smoothly without any faults for two years since its launch. The Cetus Protocol has undergone multiple audits, but no vulnerabilities were found, primarily 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 high liquidity submissions that trigger abnormal logic, indicating that such issues are difficult to detect through ordinary testing. These types of problems 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, and it has 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 during the calculation of the required token amount, and bitwise operations were used instead of regular multiplication. If regular arithmetic operations were used in Move, it would automatically check for overflow situations, preventing this kind of high-order truncation issue.

Similar vulnerabilities have also appeared in other languages (such as Solidity and Rust), and are even easier to exploit due to their lack of integer overflow protection; the overflow checks were very weak before the update of the Solidity version. Historically, there have been addition overflows, subtraction overflows, multiplication overflows, etc., all directly caused by the operation results exceeding the range. For example, the vulnerabilities in the two smart contracts BEC and SMT written in Solidity have achieved attacks by carefully constructed parameters that bypass the detection statements in the contracts, resulting in excessive transfers.

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 increase 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 Cycle: 24 hours

Mechanism process:

• Delegated Stake: Regular users do not need to run nodes themselves; they can participate in network security and reward distribution by staking SUI and delegating it to candidate validators. This mechanism lowers the participation threshold for regular 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 block production: A small number of selected validators produce blocks in a fixed or random order, which improves confirmation speed and increases TPS.

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

The advantages of DPoS:

• High efficiency: Due to the controllable number of block 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 demand for computing power decreases, and costs are lower. Ultimately, this achieves 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, the consensus mechanism of SUI employs a BFT (Byzantine Fault Tolerance)-based algorithm, requiring that more than two-thirds of the votes among validators reach consensus to confirm a transaction. This mechanism ensures that even if a minority of nodes act maliciously, the network can still maintain secure and efficient operation. Any upgrades or major decisions also require more than two-thirds of the votes for implementation.

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. Compared to pure PoS or PoW, it sacrifices a certain degree of complete decentralization but significantly improves 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 packaged onto the chain. Validator nodes are core components of the SUI blockchain, responsible for verifying transactions and executing protocol rules. By collectively ignoring transactions related to an attacker, these validators effectively implement a mechanism akin to 'account freezing' in traditional finance at the consensus level.

SUI itself has a deny list mechanism built in, 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 instantly freeze the hacker's address. Without this feature, 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 authority to change 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. At first glance, it seems that each validator is freely expressing their own values.

In fact, to ensure consistency and effectiveness of security policies, updates to such critical configurations are usually coordinated. Since this is an "urgent update driven by the SUI team", it is essentially the SUI Foundation (or its authorized developers) that sets and updates this denial list.

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

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.

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

• For large holders, the main providers of liquidity, the protocol aims to ensure the safety of funds, because in reality, the on-chain data tvl is all contributed by major holders. To ensure the long-term development of the protocol, safety will undoubtedly be prioritized.

• For retail investors, contributors to the ecological activity, and strong supporters of technology and community co-construction. The project party also hopes to attract retail investors to co-build, so that...