Cetus Protocol Hack: $223M Integer Overflow on Sui | VCC

On May 22, 2025, Cetus Protocol — the leading decentralized exchange on the Sui blockchain — lost approximately $223 million to a single integer overflow bug in its concentrated liquidity AMM (CLMM) math library. The vulnerability lived in one function, get_delta_a inside clmm_math.move, and exploited a mis-sized overflow check that had survived multiple security audits.

This is not a story about a novel exploit. It is a story about a known bug class — tick-boundary arithmetic in CLMMs — that the industry has failed to systematically test for, despite a near-identical precedent (KyberSwap Elastic, November 2023, $48.8M) existing for 18 months. The Cetus hack cost roughly five times more because Sui's TVL had grown substantially in the interim.

The Bug: A Mis-Sized Overflow Check in checked_shlw

Cetus's CLMM implementation uses a shared math library, clmm_math.move, written in Move (Sui's smart contract language). Move is memory-safe and provides built-in overflow protection for standard arithmetic (+, -, *, /). However, the library needed a wide left-shift operation on a 256-bit unsigned integer (u256) — a specialized bit manipulation that Move's standard library exposes as checked_shlw.

The function checked_shlw(value: u256, shift: u8) shifts value left by shift bits and should abort if the result would overflow u256. The correct overflow threshold for a 64-bit left shift is:

MAX_SAFE_INPUT = (1 << 192) - 1   // 2^192 - 1

Because u256 max is 2^256 - 1, shifting left by 64 bits means any input ≥ 2^192 will overflow. The Cetus code, however, used a wrong constant — off by exactly 2^64. The buggy check effectively allowed inputs up to 2^256 - 1 (the full u256 range) to pass through, causing silent wraparound.

// CORRECT: abort if value >= 2^192
assert!(value < (1u256 << 192), E_OVERFLOW);

// BUGGY (what Cetus had): off by 2^64 assert!(value < (1u256 << 256), E_OVERFLOW); // 1<<256 == 0 in u256, so this check passes for ALL values 

The developer likely confused the shift amount (64) with the remaining bit width (256-64=192). This is a "category error" — mixing up how many bits we shift with how many bits remain.

Attack Walkthrough: Six Steps to $223M

The attacker did not wait for market conditions to trigger the bug. They engineered the preconditions using a flash swap:

1. Flash swap — Borrowed 10 million haSUI (a liquid staking derivative) from a Cetus pool.
2. Extreme tick range — Opened an LP position with tick range [300000, 300200], a narrow band at the upper bounds of the tick space (max tick = 887272). Standard test suites never exercise this range.
3. Minimal liquidity — Added just 1 unit of token A as liquidity.
4. Overflow fires — Due to the mis-sized check, get_delta_a returned a massive liquidity value:

`10,365,647,984,364,446,732,462,244,378,333,008` (~10^37)

1. Drain — Removed liquidity across multiple transactions, extracting roughly 5.7 million SUI from the pool.
2. Repay and profit — Repaid the 10M haSUI flash swap and kept the difference (~$223M at the time).

Why This Survived Audits: The Testing Blind Spot

Every major audit of Cetus (and most CLMM protocols) covers:

• Normal tick ranges (e.g., [-100000, 100000])
• Standard liquidity amounts
• Typical swap paths

None systematically test:

• Tick ranges at or near MAX_TICK (887272) or MIN_TICK (-887272)
• Single-unit liquidity at extreme ticks
• Overflow-boundary inputs to checked_shlw and similar wide-shift operations

The KyberSwap Elastic exploit (November 2023, $48.8M) was functionally identical — a tick-boundary rounding error in CLMM position initialization. The industry had 18 months of warning. Yet Cetus, launching on a growing chain, inherited the same blind spot.

The "Safe Language" Fallacy

Move is marketed as a "safe smart contract language" with built-in overflow protection. This is true for standard arithmetic. But checked_shlw is a specialized intrinsic for bit manipulation where the developer must specify the overflow bound. Move cannot infer the correct bound because it depends on the semantic intent of the shift — is it shifting by 64? 128? A variable amount?

Key insight: "Memory-safe language" ≠ "Arithmetic-safe language" when developers bypass standard operators for bit-level operations. The Cetus bug was not a failure of Move's guarantees; it was a failure to correctly use Move's escape hatch for wide shifts.

Move vs. Solidity: What Each Protects

Operation	Solidity 0.8+	Move
a + b	Built-in overflow check	Built-in overflow check
a * b	Built-in overflow check	Built-in overflow check
a << 64 (u256)	No built-in check (developer must use unchecked or manual bounds)	checked_shlw requires manual bound
a >> 64	No built-in check	checked_shrw requires manual bound

Both ecosystems require developer diligence for wide shifts. The Cetus bug proves that auditing the bound specification is as critical as auditing the arithmetic itself.

Sui-Specific Aftermath: Validator Freeze and Governance Debate

Unlike Ethereum, where stolen funds are typically unrecoverable once bridged, Sui's object-centric model allowed validators to identify and freeze the specific Coin objects held by the attacker's address. Within hours, validators coordinated a governance-assisted freeze of approximately $160M of the remaining stolen funds.

This sparked intense debate:

• Pro-freeze: Protected users, recovered majority of funds, demonstrated chain's ability to respond to catastrophic bugs.
• Anti-freeze: Violated censorship resistance, set precedent for validator intervention, could be abused for political censorship.

The SUI token dropped 7%, CETUS token fell 40%, and smaller Sui ecosystem tokens lost up to 80% of their value in the week following. The attacker successfully bridged ~$62M USDC to Ethereum and converted to ~23,000 ETH before the freeze took effect.

Historical Parallel: KyberSwap Elastic (November 2023)

Aspect	KyberSwap Elastic	Cetus Protocol
Date	Nov 2023	May 2025
Chain	Ethereum	Sui
Loss	$48.8M	$223M
Root cause	Tick-boundary rounding in computeSwapStep	Integer overflow in checked_shlw (get_delta_a)
Attack vector	Extreme tick + precision loss	Extreme tick + shift overflow
Precedent known?	First major CLMM arithmetic exploit	Yes — 18 months prior

The industry's failure was not discovering the bug class — it was failing to systematically test for it across every new CLMM deployment.

Defensive Lessons: What Would Have Stopped This

1. Property-Based Testing at Tick Extremes

Standard unit tests cover "happy paths." Property-based tests (using tools like Proptest for Move or Echidna/ Foundry for Solidity) should assert invariants across the full tick range:

// Pseudocode for property test
#[test]
fn test_get_delta_a_no_overflow_at_any_tick() {
    for tick_lower in MIN_TICK..=MAX_TICK {
        for tick_upper in (tick_lower+1)..=MAX_TICK {
            for liquidity in [1, 1000, MAX_LIQUIDITY] {
                let result = get_delta_a(liquidity, tick_lower, tick_upper);
                assert!(result <= MAX_U256); // Never overflows
            }
        }
    }
}

2. Fuzzing Wide-Shift Operations

Any use of `checked_shlw`, `checked_shrw`, or equivalent wide-shift intrinsics should be fuzzed at the boundary:

• Input = 2^192 - 1 (max safe)
• Input = 2^192 (first overflow)
• Input = 2^256 - 1 (max u256)

3. Invariant-Preservation Tests for CLMM

Audit checklists should require: *"No sequence of valid operations (mint, burn, swap, flash) can cause the pool's invariant to exceed its mathematically correct value."* This would catch both overflow and rounding-direction bugs.

4. Audit Scope Must Include Shared Libraries

`clmm_math.move` is a shared library used across Cetus's pools. Auditing only the pool contracts while treating the math library as "trusted" is a gap. Every shared math library should get standalone arithmetic audit coverage.

5. Flash Swap as Attack Precondition — Monitor for State Engineering

Protocols should monitor for flash swap + immediate LP mint at extreme ticks as a suspicious pattern. This combination (capital-efficient state preparation) is a hallmark of arithmetic exploits.

FAQ

How much did the Cetus Protocol hack lose?

Approximately $223 million (about 5.7 million SUI at the time), making it the second-largest DeFi hack of 2025 after Bybit ($1.46B).

What was the root cause of the Cetus hack?

An integer overflow in the `checked_shlw` function within `get_delta_a` (inside `clmm_math.move`). The overflow check used a constant off by `2^64`, allowing a 64-bit left shift to wrap silently.

How did the attacker exploit the Cetus bug?

The attacker used a flash swap to borrow 10M haSUI, opened an LP position at an extreme tick range `[300000, 300200]` with 1 unit of liquidity, triggering the overflow to receive ~10^37 liquidity, then drained the pool.

Why is this called a "shared library exploit"?

The vulnerable function `get_delta_a` lives in `clmm_math.move` — a shared math library used by all Cetus CLMM pools. The bug was in the library, not in an individual pool contract.

Was the Cetus hack related to the KyberSwap hack?

Yes — functionally identical root cause. Both exploited tick-boundary arithmetic in CLMM position initialization. KyberSwap (Nov 2023, $48.8M) was a rounding error; Cetus (May 2025, $223M) was an integer overflow. Same blind spot, 18 months later, 5x the loss.

Can Move's safety features prevent this class of bug?

Move's built-in overflow checks protect standard arithmetic (+, -, *, /). They do not automatically protect wide-shift intrinsics like `checked_shlw` — the developer must specify the correct bound. The Cetus bug was a developer-specified bound error, not a language failure.

What happened to the stolen funds?

The attacker bridged ~$62M USDC to Ethereum (~23,000 ETH). Sui validators coordinated to freeze the remaining ~$160M on-chain — a controversial but effective governance response unique to Sui's object model.

Conclusion

The Cetus Protocol hack is a case study in systemic testing failure. The bug class (CLMM tick-boundary arithmetic) was known for 18 months. The precedent (KyberSwap) was public. The fix (property-based testing at extremes, fuzzing wide shifts, auditing shared libraries) is well-documented. Yet a leading DEX on a major L1 launched with the same blind spot and lost $223M.

The lesson extends beyond Sui or Move: arithmetic edge cases in audited, mature math libraries remain the industry's most persistent blind spot. Attackers don't find novel bugs — they engineer the boundary conditions that test suites ignore. Until fuzzing and property-based testing at arithmetic extremes become mandatory audit requirements, not optional best practices, this pattern will repeat — on Sui, on Ethereum, on every chain that runs DeFi.

The $223M question is not "how did this happen?" but "why are we still not testing for it?"

---

This analysis is based on 12+ independent sources including official post-mortems (Cetus, Sui Foundation), security audit reports (Dedaub, Verichains, Quillaudits, Cyfrin), on-chain forensics (BlockSec, Cyvers, SlowMist), and historical precedent (KyberSwap). All technical details cross-verified across minimum 3 sources per claim.