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 logic vulnerability related to "integer overflow issues" to execute a 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 SUI across the entire chain plummeted by more than $330 million on the day of the attack, while the locked amount of the Cetus protocol evaporated by 84% instantly, dropping to $3.8 million. As a result, several popular tokens on SUI (including Lofi, Sudeng, Squirtle, etc.) fell by 76% to 97% within just one hour, triggering widespread concern in the market about the security and ecological stability of SUI.

But 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 sustained decline; instead, it has 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 event, the consensus mechanism of SUI nodes, the security of the MOVE language, and the ecological development of SUI, organizing the current ecological pattern of this public chain that is still in its early development stage, and discussing 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 Mist team, the hacker successfully exploited a key arithmetic overflow vulnerability in the protocol, using flash loans, precise price manipulation, and contract flaws to steal over $200 million in digital assets within a short period. The attack path can be roughly divided into the following three stages:

①Initiate flash loans to manipulate prices

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

Flash loans allow users to borrow and repay funds in a single transaction, only requiring a fee, featuring high leverage, low risk, and low cost. Hackers exploited this mechanism to sharply lower market prices within a short period, precisely controlling it within a very narrow range.

The attacker then prepares 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 the above method, hackers successfully manipulated the haSUI price using a sufficient amount of tokens and huge liquidity. Subsequently, they targeted several tokens with no actual value for manipulation.

②Add liquidity

The attacker created a narrow liquidity position, claimed to add liquidity, but due to a vulnerability in the checked_shlw function, ultimately only received 1 token.

Essentially due to two reasons:

1. Mask setting too wide: equivalent to a huge liquidity addition limit, making the contract's validation of user input virtually meaningless. Hackers bypassed the overflow detection by setting abnormal parameters and constructing inputs that were always less than this limit.

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

③Withdraw liquidity

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

The situation of fund loss is severe, 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 dollars TOILET

• Other tokens such as HIPPO and LOFI have dropped 75-80%, and liquidity has dried up.

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 fundamental 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 SUI's code. The root of the vulnerability lies in a boundary condition check, and simply modifying two lines of code can 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 the 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, primarily because the Integer_Mate library used for mathematical calculations was not included in the audit scope.

Hackers use extreme values to precisely construct trading intervals, creating extremely rare scenarios of submitting very high liquidity, which triggers 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 a problem 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 when calculating the required token amount, and bitwise operations were used instead of conventional multiplication. If conventional addition, subtraction, multiplication, and division were used in Move, overflow situations would be automatically checked, preventing this kind of high-bit truncation issue.

Similar vulnerabilities have also appeared in other languages (such as Solidity and Rust), and they can be more easily exploited due to the lack of integer overflow protection; prior to the updates in Solidity, the overflow checks were very weak. Historically, there have been addition overflows, subtraction overflows, multiplication overflows, etc., all directly caused by operation results exceeding their range. For example, vulnerabilities in the BEC and SMT smart contracts of the Solidity language were exploited through carefully constructed parameters, bypassing the detection statements in the contract to achieve excessive transfers.

3. The consensus mechanism of SUI

3.1 Introduction to SUI Consensus Mechanism

Overview:

SUI adopts a Delegated Proof of Stake framework (DeleGated Proof of Stake, referred to 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 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 Cycle: 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 can lower 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 blocks: A small number of selected validators produce blocks in a fixed or random order, which increases confirmation speed and improves TPS.

• Dynamic Election: After each voting cycle, a dynamic rotation is conducted based on voting weights 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 complete confirmations in milliseconds, meeting high TPS requirements.

• Low cost: Fewer nodes participate in consensus, significantly reducing the network bandwidth and computing resources required for information synchronization and signature aggregation. This results in lower hardware and operational costs, reduced requirements for computing power, and lower costs overall. Ultimately, it achieves lower user transaction fees.

• High security: The staking and delegation mechanism amplifies 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 that requires over two-thirds of the votes among validators to reach consensus in order to confirm transactions. This mechanism ensures that even if a minority of nodes act maliciously, the network can still maintain security 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" that balances decentralization and efficiency. In the security-decentralization-scalability "impossible triangle," 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 enhancing 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 coding perspective, it prevents transfer transactions from being packaged on-chain. Validator nodes are 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 the 'account freezing' mechanism 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 functionality already exists in the client, when an attack occurs,

SUI can immediately 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.

3.2.2 Who has the power 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. On the surface, each validator seems to be freely expressing their own 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 essentially the SUI Foundation (or its authorized developers) that set and update this denial list.

SUI has released a blacklist, 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.

3.2.3 The essence of the blacklist function

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

Essentially a security guarantee mechanism. Similar to a "security chain" tied to the door, it is activated only for those who want to intrude into the home, i.e., for those who wish to maliciously exploit the protocol. For users, it means:

• 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 primarily contributed by these large holders. For the protocol to develop sustainably, ensuring safety must be the top priority.

• For retail investors, contributors to ecological activity, a strong support for technical and community co-construction.