Firm Belief After the 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 attackers exploited a logical vulnerability related to the "integer overflow issue" to carry out precise manipulation, resulting in losses exceeding $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 the data, the total value locked (TVL) of the SUI blockchain plummeted by over $330 million on the day of the attack, with the locked amount of the Cetus protocol evaporating by 84%, 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 shockwave, the SUI ecosystem has demonstrated strong resilience and recovery ability. Although the Cetus incident caused fluctuations in confidence in the short term, the 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 construction, and project quality.

This article will focus on the reasons for this attack incident, the node consensus mechanism of SUI, the security of the MOVE language, and the ecological development of SUI. It will outline the current ecological landscape 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 attack

2.1 Attack Implementation Process

According to the technical analysis of the Cetus attack incident by the security 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 exchange of 10 billion haSUI flash loans, borrowing a large amount of funds to manipulate prices.

Flash loans allow users to borrow and repay funds in a single transaction, requiring only a fee, characterized by 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 prepared to create a very 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, the hacker successfully manipulated the haSUI price with a sufficiently large amount of tokens and huge liquidity. Subsequently, they 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: equivalent to a huge liquidity addition limit, resulting in the validation of user inputs in the contract being effectively void. Hackers bypassed the overflow detection by setting abnormal parameters, constructing inputs that are always less than this limit.

2. Data overflow was truncated: When performing a shift operation on the numeric n with n << 64, 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 computation far below expectations, 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 large amount of liquidity.

③Withdraw liquidity

Repay the flash loan and retain substantial 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 US dollars TOILET

• Other tokens like HIPPO and LOFI have dropped by 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 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 the SUI code. The root of the vulnerability lies in a boundary condition check, and it can be completely eliminated by modifying just two lines of code; once the fix is completed, it can be deployed to the mainnet immediately to ensure that the subsequent contract logic is complete and to eliminate this vulnerability.

2. High concealment: The contract has been operating smoothly for two years with zero faults and has undergone multiple audits, but vulnerabilities have not been found. The main reason is that the Integer_Mate library used for mathematical calculations was not included in the audit scope.

Hackers utilize 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 within people's view, which is why they remain hidden for a long time before being discovered.

3. Not just a problem unique to Move:

Move excels in resource safety and type checking compared to various smart contract languages, with native detection for integer overflow issues in common scenarios built-in. This overflow occurred because, when adding liquidity, an incorrect value was first used for the upper limit check during the calculation of the required token amount, and bitwise operations were used instead of conventional multiplication. If conventional addition, subtraction, multiplication, or division were used in Move, it would 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 the lack of integer overflow protection; overflow checks were very weak before the updates in Solidity versions. 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 BEC and SMT smart contracts in the Solidity language both achieved attacks by carefully constructed parameters, bypassing the detection statements in the contracts and executing 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 improve transaction throughput, it cannot provide the high level of decentralization that PoW (Proof of Work) can. Therefore, the degree 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:

• 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 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 period, a dynamic rotation will take place 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 high TPS requirements.

• Low cost: Fewer nodes participate in consensus, significantly reducing the network bandwidth and computational resources required for information synchronization and signature aggregation. This leads to 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 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 SUI's consensus mechanism, an algorithm based on BFT (Byzantine Fault Tolerance) is used, requiring more than two-thirds of the validators' votes to reach 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" that balances decentralization and efficiency. In the security-decentralization-scalability "impossible triangle," DPoS opts to reduce the number of active block producers in exchange for higher performance. This comes at the cost of a certain degree of complete decentralization compared to pure PoS or PoW, but it significantly enhances network throughput and transaction speed.

3.2 The performance of SUI in this attack

The operation of the 3.2.1 freezing mechanism

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

From the code level, it prevents transfer transactions from being packaged on the chain. Validator nodes are the core components of the SUI blockchain, responsible for verifying transactions and executing protocol rules. By collectively ignoring transactions related to the attacker, these validators effectively implement a mechanism similar to the 'account freeze' mechanism 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 the 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 feature, even if SUI has only 113 validators, it would be difficult to coordinate all validators to respond one by one in a short time.

3.2.2 Who has the authority 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, it seems that each validator is freely expressing their own values.

In fact, for the consistency and effectiveness of security policies, updates to this critical configuration are typically coordinated. Since this is a "team-driven urgent update", it is essentially the foundation (or its authorized developers) that sets and updates this denial list.

Publishing a blacklist, 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 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 to deal with emergencies and ensure the safety of user funds.

It is essentially a security assurance 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 users:

• For large holders, the main providers of liquidity, the protocol is most concerned with ensuring the safety of funds, because in fact, the on-chain data TVL is entirely contributed by these major holders. For the protocol to develop sustainably, ensuring safety will definitely 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, so that the ecosystem can be gradually improved and retention rates strengthened. As for the DeFi field, the most important thing is...