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 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 it has also become the most destructive hacker attack since the launch of the SUI mainnet.

According to DefiLlama data, the total value locked (TVL) of the SUI blockchain 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, multiple popular tokens on SUI experienced a crash of 76% to 97% within just one hour, triggering widespread concern in the market regarding the safety and ecological stability of SUI.

However, after this shock wave, the SUI ecosystem has shown strong resilience and recovery ability. Although the Cetus incident brought short-term fluctuations in confidence, on-chain funds and user activity have not experienced a sustained decline; instead, it has significantly enhanced the entire ecosystem's 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, outlining the current ecological structure of this public chain, which 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 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 flash loans, manipulate prices

Hackers first exploited a maximum slippage flash swap of 10 billion haSUI flash loans, borrowing a large amount of funds to manipulate prices.

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 and precisely control them 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 with a large enough number of tokens and huge liquidity. Subsequently, they manipulated several tokens with no actual value.

②Add liquidity

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

Essentially due to two reasons:

1. The mask setting is too broad: equivalent to a very large liquidity addition limit, resulting in the validation of user inputs in the contract being effectively non-existent. Hackers exploit abnormal parameters to construct inputs that are always below this limit, thus circumventing overflow detection.

2. Data overflow was truncated: When performing a shift operation of n << 64 on the numerical value n, data truncation occurred due to the shift exceeding the effective bit width of the uint256 data type (256 bits). The overflow portion of the high bits was automatically discarded, resulting in a calculation outcome far below expectations, thus causing the system to underestimate the amount of haSUI required for the exchange. The final computed result was approximately less than 1, but due to rounding 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 and retain massive profits. Ultimately 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 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 by 75--80%, with liquidity exhausted.

2.2 The causes and characteristics of this vulnerability

This vulnerability of Cetus has three characteristics:

1. The cost of fixing is extremely low: on one hand, the root cause of the Cetus incident was 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 was limited to Cetus itself and had nothing to do with SUI's code. The root of the vulnerability was in a boundary condition check, and it only requires modifying two lines of code to completely eliminate the risk; once the fix is completed, it can be immediately deployed to the mainnet to ensure the completeness of subsequent contract logic and eliminate 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 were found. The main reason is that 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 with extremely high liquidity that trigger abnormal logic, indicating that such issues are difficult to detect through ordinary testing. These issues often lie in blind spots of people's awareness, 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 security and type checking, with built-in native detection for integer overflow issues in common scenarios. This overflow occurred because an incorrect value was used for the upper limit check when calculating the required token amount during liquidity addition, and bitwise operations were used instead of conventional multiplication. In contrast, conventional addition, subtraction, multiplication, and division operations in Move will automatically check for overflow situations, avoiding such high-bit truncation issues.

Similar vulnerabilities have also appeared in other languages (such as Solidity and Rust), and they are even more easily exploited due to the lack of integer overflow protection; before the updates to the Solidity version, the overflow checks were very weak. Historically, there have been addition overflow, subtraction overflow, multiplication overflow, etc., all directly caused by operation results exceeding the range. For example, the vulnerabilities in the BEC and SMT smart contracts of the Solidity language were both exploited through carefully constructed parameters that bypassed the detection statements in the contracts, resulting in excessive transfers to carry out attacks.

3. The consensus mechanism of SUI

Introduction to the 3.1 SUI Consensus Mechanism

Overview:

SUI adopts a Delegated Proof of Stake framework (DeleGated Proof of Stake, abbreviated as DPoS)). While the DPoS mechanism can increase transaction throughput, it cannot provide the same level of decentralization as PoW (Proof of Work). Therefore, SUI has a relatively low level of decentralization and a higher governance threshold, making it difficult for ordinary users to directly influence network governance.

• Average number of validators: 106

• Average Epoch Duration: 24 hours

Mechanism process:

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

• Representing round block generation: a small number of selected validators produce blocks in a fixed or random order, enhancing confirmation speed and increasing TPS.

• Dynamic Election: After each voting cycle, 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: Due to the controllable number of block-producing nodes, the network can achieve confirmation in milliseconds, meeting the 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. As a result, hardware and operational costs decrease, the requirements for computing power decrease, leading to lower costs. Ultimately, this achieves lower user transaction fees.

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

At the same time, the consensus mechanism of SUI adopts an algorithm based on BFT (Byzantine Fault Tolerance), requiring that more than two-thirds of the votes among validators 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, balancing decentralization and efficiency. DPoS chooses to reduce the number of active block-producing nodes in exchange for higher performance in the security-decentralization-scalability "impossible triangle." 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

Operation of the freezing mechanism 3.2.1

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. Validation 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 the 'account freeze' 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 function 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 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. 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 driven 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 allows validators to 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 feature is actually not 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 "security chain" tied to the door, it is only activated for those who want to intrude into the home, namely for those who intend to maliciously exploit the protocol. For users:

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

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