On August 23, 2026, at 06:25 UTC, an attacker executed a single parameterless function call on Ethereum and walked away with $8.5 million from Term Finance's vaults. No exploit in the traditional sense — no reentrancy, no overflow, no oracle manipulation. The smart contracts worked exactly as designed. The attacker simply voted.

This is the anatomy of a governance takeover — the kind of attack that no code audit would have caught, because the code was never the problem.

The Target

Term Finance is an Ethereum-based fixed-rate lending protocol. Its yield products — the Meta Vaults — sit on Yearn V3 infrastructure with a custom governance layer bolted on top. Users deposit ETH and USDC into these vaults, which then deploy capital across strategies in Aave, Morpho Blue, and other lending markets.

At the time of the attack, Term's vaults held roughly $12.45 million in TVL, with $8.8 million on Ethereum mainnet.

The governance design: vault depositors receive a governance token (tmvETH) proportional to their stake. Token holders vote on proposals that control vault parameters — which strategies to add, what fee structures to use, where capital flows. A 7-day timelock and an LP veto mechanism were supposed to prevent hostile proposals from executing.

All of this worked as intended. That was the problem.

The Kill Chain

Day 0 — August 17, 05:01 UTC: The $951 Coup

Block 25,772,572. A fresh wallet (0xa908b347...) receives 0.9945 ETH from an intermediary funded by Tornado Cash. Two ETH total — seed money.

Block 25,772,675 (twenty minutes later). The wallet purchases 0.4852 tmvETH — the governance token for Term's ETH Meta Vault — for approximately 0.5 ETH.

Cost: roughly $951.

The total staked supply of gtmvETH at that moment: 0.5352.

The attacker now controls 90.66% of all voting power in the ETH Meta Vault. Four USDC strategy vaults fall under full control as well — their governance participation was even thinner.

The entire defense model assumed the electorate would be large enough that no single buyer could reach a majority. It wasn't. The governance token market was so thin that the protocol's security reduced to a liquidity depth question — and no one was watching the depth.

Day 0 — Proposals Submitted

With 90.66% voting power, the attacker submits governance proposals to the affected vaults. The proposals contain two critical actions, ordered deliberately:

Action 1: Set the timelock cooldown to zero.

This is the move that made everything else possible. The 7-day timelock was the last line of defense — after a proposal passes, there's supposed to be a mandatory waiting period before execution. The attacker's first action upon execution removes that waiting period for all subsequent proposals. One vote to end all future delay.

Action 2: Add a new "strategy" contract.

In Yearn V3 architecture, strategies are the modules that deploy vault capital into external protocols. The attacker's "strategy" is a contract whose sole purpose is to route withdrawn funds to the attacker's address (0x184f2e57b4...). It looks like a strategy. It functions as a drain.

Day 1–5 — Silence

The proposals sit in the timelock queue. The 7-day waiting period ticks.

Term Finance had an LP veto mechanism — liquidity providers could reject hostile proposals during this window. Nobody vetoed. The governance forum showed no discussion of these proposals. The monitoring infrastructure either didn't exist or didn't trigger.

Five days of a loaded gun sitting on the table, and nobody noticed.

Day 6 — August 23, 06:25 UTC: Execution

Block 25,816,049. The attacker calls 0x373058b8 on the governance executor contract (0x64e47780...). A single function, no parameters. Execute.

What happens inside this transaction — 78 log events in total:

1. The timelock cooldown drops to zero (Action 1 fires)

2. The malicious strategy is added to the vault roster

3. The Meta Vault begins withdrawing from its real strategies:

   • Aave WETH pool: two sub-vaults redeemed

   • Morpho Blue (0xbbbbbbbb...): two withdrawals via Yearn V3 wrapper

   • Each redemption flows back through the Meta Vault aggregator (0x26fcb50e...)

4. Capital is routed to the attacker's strategy (0x184f2e57b4...)

5. The strategy forwards 2,841.74 WETH to the attacker wallet

Transaction: 0xd354a15b...

A separate execution drains the USDC vaults — approximately 1.68 million USDC, immediately swapped to DAI through on-chain DEX routes.

Total extraction: ~$8.5 million from a $951 investment.

Return on capital: 8,938x.

The Money Trail

Post-drain, the attacker moves quickly but not completely.

The 2,841 WETH is unwrapped to ETH and forwarded through a series of splitter contracts, all pointing to variations of 0xd518... addresses. Address poisoning tactics are visible in the transaction log — fake "EṬH" transfers (note the modified T character: Ṭ vs T) sent to similar-looking addresses, a social engineering technique targeting anyone monitoring the flow who might copy-paste the wrong destination.

As of this analysis, the consolidation wallet 0xD5183d8BfC65a50863C62aF2538198A8288FFc13 holds:

Approximately $670K has been spent on gas, forwarding, and partial exits. The bulk remains untouched — either the attacker is patient, or they're waiting for attention to die down.

Why Every Safeguard Failed

The Timelock Paradox

A 7-day timelock is only useful if someone is watching. Term Finance's governance participation was so low that the proposals passed with zero opposition. But the deeper design flaw is subtler: the timelock itself was governed by the same vote that it was supposed to protect against.

The attacker's first action — setting cooldown to zero — is the governance equivalent of using the first wish to wish for unlimited wishes. If the entity that controls the timelock is the same entity the timelock is supposed to constrain, the timelock is decorative.

The Veto That Wasn't

LP veto rights existed on paper. No LP exercised them. This isn't an implementation failure — it's a participation failure. The mechanism assumed LPs would:

1. Monitor the governance forum

2. Understand the proposals

3. Recognize the threat

4. Act within the window

Each assumption was individually reasonable. Together, they built a defense that required four human actions in sequence, any one of which could fail to happen. The attacker only needed one to not happen. It was all four.

The Token Distribution That Nobody Checked

The most fundamental failure: at the moment of attack, the governance token had a total staked supply of 0.5352 gtmvETH. The entire security model — the votes, the timelock, the veto — was downstream of a single assumption: that this number would be large enough to make a hostile majority prohibitively expensive.

It cost $951.

No monitoring system checked this number. No circuit breaker fired when a single address acquired 90% of voting power. The protocol treated governance token concentration as someone else's problem.

The Architecture Lesson

This exploit belongs to a class that traditional smart contract audits cannot catch. The code functioned correctly. The governance mechanism executed as specified. The timelock enforced its rules. Every require passed, every assert held, every state transition was valid.

The vulnerability was economic, not technical:

1. Governance security is a function of participation, not mechanism design. A perfectly designed voting system with 0.5 participants is less secure than a flawed one with 10,000.

2. Timelocks must not govern themselves. If a governance vote can modify the timelock parameters, the timelock provides exactly one window of protection — the first one. After that, the attacker owns the clock.

3. Token concentration is a security metric. Protocols that expose governance power through thin markets need circuit breakers: minimum quorum, concentration alerts, automatic pause when a single address crosses a voting threshold.

4. The veto window is a monitoring commitment, not a safety feature. A veto mechanism that nobody monitors is indistinguishable from no veto mechanism at all.

5. $951 is cheaper than an audit. The attacker spent less on this entire operation than most protocols spend on a single smart contract review. The audit would have found nothing — the code was clean. The governance design was the attack surface, and no auditor was looking at token distribution depth.

What Should Have Existed

• Minimum quorum: proposals below X% participation cannot execute, regardless of vote ratio

• Concentration alert: if a single address holds >Y% of voting power, governance enters emergency mode (pause + multisig override)

• Timelock immutability: core safety parameters (timelock duration, veto window) cannot be modified through governance — they require a multisig or are hardcoded

• Strategy whitelist with independent approval: new strategy contracts require approval from a separate security council, not the same governance that benefits from the strategy

• Active monitoring with auto-pause: governance proposal submission triggers alerts to all LPs, and proposals modifying safety parameters auto-escalate to a higher approval threshold

None of these are novel. All of them existed in other protocols before this attack. They just weren't implemented here.

Timeline

On-chain data sourced via Alchemy Ethereum mainnet RPC. All addresses and transaction hashes are independently verifiable on Etherscan.

Summary

​ A permissionless sweepUnclaimedBonus() between a moderator's SURVIVED flag and a corrective CORRUPTED re-flag irreversibly drains the bonus to recoveryAddress, permanently reducing the whitehat attacker's bounty. The protocol pays the wrong recipient with no recovery path. ​

Description

​ sweepUnclaimedBonus does not set claimsStarted (L503), so the re-flag window stays open after the sweep. When riskWindowStart == 0, bonus is unreserved and fully sweepable (L483-487). On re-flag, the snapshot captures the now-zeroed totalBonus (L358), producing a reduced bountyEntitlement: ​

// ConfidencePool.sol L357-362
snapshotTotalBonus = totalBonus;           // captures zeroed value after sweep
bountyEntitlement = willBeGoodFaithCorrupted
? snapshotTotalStaked + snapshotTotalBonus  // bonus portion is zero
: 0;

​ Because the snapshot occurs after the sweep, no later code path restores the swept bonus into bountyEntitlement. ​ Reachability of riskWindowStart == 0: The registry requires UNDER_ATTACK before CORRUPTED (AttackRegistry.sol L324). But the pool only seals riskWindowStart on a pool-touching transaction (L793). If approveAttack() and markCorrupted() execute with no pool interaction in between (e.g., same block), riskWindowStart stays zero. ​

Vulnerability Details

​ Attack path: ​

1. Registry reaches CORRUPTED with no pool interaction during UNDER_ATTACK — riskWindowStart stays zero.

2. Moderator flags SURVIVED. No call to stake(), contributeBonus(), or pokeRiskWindow() occurred during the active-risk interval.

3. Anyone calls sweepUnclaimedBonus() — bonus drains to recoveryAddress, totalBonus zeroed.

4. claimsStarted remains false — moderator re-flags to good-faith CORRUPTED.

5. bountyEntitlement = snapshotTotalStaked + 0. Attacker permanently loses the bonus portion. ​

Risk

​ Impact: High — The protocol permanently pays the wrong recipient. The bonus (up to 100% of totalBonus) is irreversibly sent to recoveryAddress instead of the named whitehat attacker. The loss is bounded only by the bonus pool size and is independent of the attacker's exploit performance. ​ Likelihood: Medium — Requires a rare but valid registry path where the pool does not observe the active-risk window before CORRUPTED, combined with a moderator flag correction. The sweep is permissionless and trivially automatable by a MEV bot. ​

Impact

​ The whitehat attacker permanently loses their bonus entitlement. In the PoC, the attacker receives 150 tokens instead of the expected 200 — a 25% loss. The swept bonus sits irreversibly at recoveryAddress. No re-flag, no subsequent call, and no admin action can restore it into the attacker's bountyEntitlement. ​

Proof of Concept

​ Drop into test/unit/ and run: forge test --match-test testSweepBetweenFlagsReducesAttackerBounty -vvvv ​ The PoC uses MockAttackRegistry (same test double used by all 256 official tests) to stage the CORRUPTED state. In production this is reached via approveAttack() → markCorrupted() with no pool interaction in between. ​

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;
​
import {IAttackRegistry} from "@battlechain/interface/IAttackRegistry.sol";
import {PoolStates} from "src/libraries/PoolStates.sol";
import {BaseConfidencePoolTest} from "test/helpers/BaseConfidencePoolTest.sol";
​
contract PoC_SweepDrainsBounty is BaseConfidencePoolTest {
function testSweepBetweenFlagsReducesAttackerBounty() external {
_stake(alice, 100 * ONE);
_stake(bob, 50 * ONE);
_contributeBonus(carol, 50 * ONE);
​
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
assertEq(pool.riskWindowStart(), 0);
​
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
​
pool.sweepUnclaimedBonus();
assertEq(pool.totalBonus(), 0);
assertFalse(pool.claimsStarted());
assertEq(token.balanceOf(recovery), 50 * ONE);
​
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
assertEq(pool.bountyEntitlement(), 150 * ONE); // should be 200
​
vm.prank(attacker);
pool.claimAttackerBounty();
assertEq(token.balanceOf(attacker), 150 * ONE);
assertEq(token.balanceOf(recovery), 50 * ONE);
}
}

​

Tools Used

Manual review, Foundry

Recommended Mitigation

​ Gate sweepUnclaimedBonus on claimsStarted: ​

function sweepUnclaimedBonus() external nonReentrant {
if (outcome != PoolStates.Outcome.SURVIVED && outcome != PoolStates.Outcome.EXPIRED) {
revert OutcomeNotEligibleForSweep();
}
+    if (!claimsStarted) revert OutcomeNotEligibleForSweep();

Alternatively, freeze totalBonus at the first flagOutcome and never re-snapshot it on re-flag, decoupling the sweep's accounting from the re-flag's snapshot.

BlueMove called it "a long-standing arithmetic overflow bug in the legacy AMM contract." Tyler Simpson of Quantum Void Labs called it a backdoor — a function shipped in a May 31 upgrade that set the stage for the drain.

Both accounts identify real pieces of the story. Neither captures the mechanism that made the drain possible.

I decompiled every module of both package versions, tested Move's integer behavior directly, and traced the attack transactions command by command. To the best of my knowledge, this is the first public analysis that identifies the actual exploit path: a reserve desynchronization between two callable versions of the same package. Both versions write reserve_x after every operation, but they write different values — V1 writes pool.token_x.value(), V-latest writes escrow.token_x.value(). When a V1 swap runs on a pool whose main liquidity lives in the escrow, reserve_x drops to the small pool.token_x balance, while the escrow retains the large one. The next V-latest mint divides by this deflated reserve_x, inflating LP tokens by the ratio between the two balances.

Why the overflow claim does not hold

Move's integer arithmetic does not wrap on overflow. Every overflow — addition, multiplication, or out-of-range downcast — aborts the transaction at runtime. This is not a compiler flag; it is how the Move VM executes arithmetic.

I tested this directly with Sui CLI v1.74.1:

#[test]
#[expected_failure]
fun test_u128_mul_overflow() {
    let a: u128 = 340282366920938463463374607431768211455; // u128::MAX
    let _result = a * 2; // aborts — does not wrap
}

#[test]
#[expected_failure]
fun test_u128_add_overflow() {
    let a: u128 = 340282366920938463463374607431768211455;
    let _result = a + 1; // aborts
}

#[test]
#[expected_failure]
fun test_u64_downcast() {
    let big: u128 = 18446744073709551616; // u64::MAX + 1
    let _small = (big as u64); // aborts — does not truncate
}

All three pass with expected_failure. Each operation aborts at runtime. An arithmetic overflow in Move is a denial-of-service, never a fund extraction vector.

The decompiled code

BlueMove never published source code. I decompiled all modules using Revela (v1.0.0) for bytecode v6, and sui move disassemble for bytecode v7 (unsupported by Revela). Critical paths were cross-verified between the two tools.

Three packages

On Sui, upgrading a package does not replace the original. Both versions remain callable on the same shared objects. BlueMove's Pool objects are shared, so any version can read and mutate them.

Two token stores, one reserve_x field

V1 stores tokens in pool.token_x / pool.token_y. V-latest stores tokens in EscrowCoinsV2, a dynamic object field on the Pool. Both versions share the Pool struct, including a single reserve_x: u64 field. Both versions overwrite reserve_x after every operation — but with values from different balances.

The reserve write: code proof

This is the linchpin. Each version's swap function ends with update(x, y, pool), which sets pool.reserve_x = x. The question is: what is x?

V1 swap → reserve_x = pool.token_x.value()

From V1's decompiled code (Revela, swap.move):

// V1 swap (lines 96, 122):
let (v2, v3) = token_balances<T0, T1>(arg2);
//  v2 = balance::value(&pool.token_x)    ← actual pool balance
//  v3 = balance::value(&pool.token_y)
...
update<T0, T1>(v2, v3, arg2);
//  pool.reserve_x = v2 = pool.token_x.value()

// V1 update (lines 80–83):
fun update<T0, T1>(arg0: u64, arg1: u64, arg2: &mut Pool<T0, T1>) {
    arg2.reserve_x = arg0;
    arg2.reserve_y = arg1;
}

This invariant holds immediately after every successful V1 swap because update() is always called with the current pool balances.

After every V1 swap: reserve_x == pool.token_x.value(). Always.

V-latest swap → reserve_x = escrow.token_x.value()

From V-latest's disassembly (escrow-exists branch, sui move disassemble):

// V-latest swap, escrow branch (lines 105–112, 269–272):
L105: CopyLoc[38](loc32: &mut EscrowCoinsV2)
L106: ImmBorrowFieldGeneric[11](EscrowCoinsV2.token_x)
L107: Call balance::value → loc18          ← escrow balance
L108: MoveLoc[38]
L109: ImmBorrowFieldGeneric[12](EscrowCoinsV2.token_y)
L110: Call balance::value → loc24          ← escrow balance
...
L269: MoveLoc[24](loc18)                   ← escrow.token_x.value()
L270: MoveLoc[30](loc24)                   ← escrow.token_y.value()
L271: MoveLoc[2](Pool)
L272: Call update                          ← reserve_x = escrow balance

After every V-latest swap (escrow branch): reserve_x == escrow.token_x.value().

This invariant holds only for the escrow branch. Therefore, whichever version executes last determines the meaning of reserve_x.

The consequence

reserve_x is a single field written by two functions that compute it from different balances. Whichever version runs last determines the value. If V-latest ran last, reserve_x tracks the escrow. If V1 ran last, reserve_x tracks pool.token_x. The two balances are independent — one can be orders of magnitude larger than the other.

The attack

Pool lifecycle

MovePump launchpad pools follow this lifecycle:

1. Created through V-latest (create_and_freeze_pool → unfreeze_and_add_liquidity → add_liquidity_direct). Initial liquidity goes into EscrowCoinsV2. pool.token_x stays at zero. reserve_x = escrow balance. LP tokens are minted to the pool creator.

2. Traded through V-latest. Users swap via V-latest router. Tokens move in and out of the escrow. reserve_x tracks escrow balance. pool.token_x remains empty. Over weeks, the escrow accumulates a large SUI balance from trading.

3. Traded through V1. External aggregators (e.g., OKX DEX Router, whose Move.toml references V1 package 0xb24b67...) route swaps through V1. V1 deposits input tokens into pool.token_x and sets reserve_x = pool.token_x.value() — a much smaller number than the escrow balance. This is the desync.

Step by step

Before attack:

escrow.token_x  = 350,000 SUI     (accumulated from V-latest trading)
pool.token_x    = 7,022 SUI       (accumulated from V1 aggregator swaps)
reserve_x       = 7,022            (set by last V1 swap = pool.token_x)
lp_supply       = 1,000            (from initial mint)

reserve_x and pool.token_x are equal (V1's update synchronizes them). But escrow.token_x is 50× larger — V1 doesn't see it, and the last operation was a V1 swap.

The numerical values below are representative rather than extracted from a single pool. They are chosen to satisfy the observed invariants (reserve_x == pool.token_x after a V1 swap) and to illustrate the ratio between the escrow balance and the pool balance that drives the LP inflation.

Step 1 — V-latest add_liquidity_returns(0.057 SUI, meme tokens):

The B20 branch runs (escrow exists). The deposit joins the escrow:

escrow.token_x += 0.057 → escrow_total = 350,000.057

V-latest's mint runs with lp_supply > 0 (the standard proportional branch — not the first-deposit branch):

LP_minted = (escrow_total − reserve_x) × old_supply ÷ reserve_x
          = (350,000.057 − 7,022) × 1,000 ÷ 7,022
          = 342,978.057 × 1,000 ÷ 7,022
          = 48,843

The attacker mints 48,843 LP — 48× the existing supply — because mint divides by reserve_x (7,022), not by the escrow balance (350,000) that the tokens actually sit in. No overflow. No underflow. The standard formula, fed a stale denominator.

The minted LP tokens are returned to the caller (this is what add_liquidity_returns does differently from add_liquidity), so they flow directly to the next command.

Step 2 — V1 remove_liquidity(48,843 LP):

V1's burn reads balance::value(&pool.token_x) — the actual SUI in the pool's direct balance, not the escrow:

total_supply  = 1,000 + 48,843 = 49,843
attacker_share = 48,843 ÷ 49,843 = 97.99%

withdrawal = pool.token_x.value() × attacker_lp ÷ total_supply
           = 7,022 × 48,843 ÷ 49,843
           = 6,881 SUI

V1 splits 6,881 SUI from pool.token_x and transfers it to the attacker.

Result: The attacker deposited 0.057 SUI (into the escrow) and withdrew 6,881 SUI (from pool.token_x). The stolen funds are the SUI that accumulated in pool.token_x from V1 aggregator swaps — real user trades routed through the old package.

The escrow's 350,000 SUI is not directly stolen in this step. It serves as the inflated numerator in the mint formula, making the attacker's LP share large enough to claim nearly all of pool.token_x.

The calculation above is illustrative. The attack transaction follows the same sequence of calls, while the exact balances differ from pool to pool.

This pattern repeated per pool. At ~1,966 SUI average across 363 pools, the total reaches approximately 714,000 SUI.

The attack transaction

Transaction 8pMKBovvrHzyRiaGjUPPFuFX6a92KkqSRitZ36zbD1qz — 49 programmable commands, 64 inputs. From the raw JSON, the command sequence repeats per pool:

SplitCoins  (prepare 0.057 SUI)
SplitCoins  (prepare meme token amount)
MoveCall    0x35f3190a... / router / add_liquidity_returns     ← V-latest
MoveCall    0xb24b6789... / router / remove_liquidity          ← V1

V-latest for deposit. V1 for withdrawal. Same Pool. Same transaction.

Pools drained in this single transaction include aaaMEME, SPANK, BSNAKE, JELLY, DGS, PCON, RUSHI, and others. On-chain balance changes for the aaaMEME pool: Add Liquidity +0.057 SUI, Remove Liquidity −7,022.21 SUI.

Attacker: 0xb29e7919...097335 (Blockaid: MALICIOUS)

Bridge wallet: 0xa74ee820...75065e

Exit: SUI → USDC across 11 DEXes → Wormhole deposit_for_burn → ~$528,000 USDC off Sui in 23 minutes.

Timeline

Verdict

The vulnerability class

The root cause is a shared mutable field written by incompatible update functions. Both V1 and V-latest write pool.reserve_x after every swap, but from different sources:

• V1: reserve_x ← pool.token_x.value()
• V-latest: reserve_x ← escrow.token_x.value()

When the two balances diverge (because tokens accumulate in different stores), whichever version wrote reserve_x last determines the denominator for LP minting. If the small balance wrote last, LP is inflated. If the large balance wrote last, LP is correctly priced.

This generalizes to any package upgrade that satisfies three conditions:

1. Storage relocation: Version B stores assets in a new location (dynamic object field, separate struct, etc.)
2. Shared accounting field: Both versions overwrite the same field (reserve_x) with values from their respective stores
3. Old version remains callable: Version A's functions are not disabled after Version B deploys

The pattern is analogous to a schema migration without backward compatibility — except the old schema is not just readable but writable, and both schemas race on the same live accounting field.

What this analysis did not cover

• Intent. The 40-day gap between the upgrade and the exploit is consistent with both a planted vulnerability and independent discovery. The code shows the mechanism; it does not show motive.
• Complete transaction accounting. The four "pure sweep" transfers documented by Simpson total ~256,000 SUI; additional drain transactions account for the remaining ~458,000 SUI. Simpson counted 363 affected pools; BlueMove's statement said 389.
• Whether V1 swaps preceding the attack were organic or attacker-triggered. The desync requires at least one V1 swap to set reserve_x = pool.token_x.value(). External aggregators referencing V1 would produce this naturally, but the attacker could also have triggered V1 swaps as setup within the same programmable transaction.
• Pre-attack pool state. The numerical example uses representative values (escrow = 350,000, pool.token_x = 7,022, supply = 1,000) that are consistent with the on-chain balance changes (+0.057 / −7,022) and with the V1 update rule (reserve_x == pool.token_x). Exact pre-attack values for individual pools were not extracted.
• The migrate_escrow_coins function in V-latest, which moves balances between the V-mid and V-latest escrow structs.

Methodology

• Decompilation: Revela v1.0.0 on V1 and V-mid (bytecode v6). sui move disassemble on V-latest (bytecode v7).
• Cross-verification: mint, burn, swap, add_liquidity_direct verified between decompiler output and raw disassembly. Register assignments for reserve_x writes traced instruction-by-instruction: V1 swap L96/L122, V-latest swap L105–112/L269–272, V-latest swap else-branch L319–326/L483–486.
• Overflow testing: sui move test, Sui CLI v1.74.1. Three cases, all abort.
• On-chain tracing: Suiscan Raw JSON for attack transaction. Package addresses extracted from MoveCall commands. Two distinct packages confirmed: 0x35f319... (add_liquidity_returns) and 0xb24b67... (remove_liquidity).
• Mathematical verification: LP minting and burn withdrawal computed with representative values satisfying the V1 update invariant (reserve_x == pool.token_x). Result (attacker share 97.99%, withdrawal 6,881 SUI) is consistent with the on-chain balance changes for the aaaMEME pool.

The EscownCoins spelling (V-mid) and EscrowCoinsV2 (V-latest) are exactly as they appear in the deployed bytecode.

I build move-test-gen, an open-source coverage checker and security linter for Sui Move. This analysis started with the linter flagging BlueMove's overflow_add function — which turned out to be irrelevant. The finding came from decompiling the bytecode and tracing the reserve update paths across package versions.

Upgrading a storage layout without retiring the previous entry points creates two valid writers for a single accounting field. Once those writers disagree about what the field represents, every formula downstream — LP pricing, withdrawal calculation, K-invariant verification — computes a correct answer to the wrong question.

The root cause was a single line of Move code that looked like an authorization check — called the right function, passed the right arguments, sat in the right place — but silently discarded its result. The oracle module had been live for eleven months.

I pulled the vulnerable source from GitHub, compared it against the post-incident rewrite, and traced the attack on-chain. This is what I found.

The vulnerable function

The oracle module (typus_oracle::oracle) managed price feeds for Typus Finance's TLP pool. Prices were updated through a function called update_v2:

public fun update_v2(
    oracle: &mut Oracle,
    update_authority: &UpdateAuthority,
    price: u64,
    twap_price: u64,
    clock: &Clock,
    ctx: &mut TxContext
) {
    // check authority
    vector::contains(&update_authority.authority, &tx_context::sender(ctx));
    version_check(oracle);

    update_(oracle, price, twap_price, clock, ctx);
}

Source: typus_oracle/sources/oracle.move, commit a918e98 (September 24, 2025 — three weeks before the exploit).

Read that function slowly. vector::contains() returns a bool. That bool is computed, evaluated — and then thrown away. The return value is never bound to a variable, never passed to assert!, never checked. Move does not warn on an unused pure-function return value. The compiler is happy. The tests pass. The authorization is theater.

What the code should have said:

assert!(
    vector::contains(&update_authority.authority, &tx_context::sender(ctx)),
    E_UNAUTHORIZED
);

One line. The entire $3.44M exploit hinged on the difference between calling a function and acting on its result.

Why this survived eleven months

The oracle module was deployed on November 13, 2024. MoveBit audited Typus Finance's contracts in May 2025 — but the oracle module was excluded from the audit scope. The module that controls every price in the system, that determines what every swap is worth, was the one module nobody formally reviewed.

The UpdateAuthority struct was a shared object on Sui — meaning any transaction could reference it. The authorization check was supposed to ensure only whitelisted addresses could call update_v2. Without the assert!, the whitelist existed but was never enforced. Every address on Sui had oracle-write access for eleven months.

The reason nobody noticed: every legitimate oracle update came from a whitelisted address. The check "worked" in the sense that whitelisted addresses passed it. It also "worked" for every other address on the network. The two populations — authorized callers and everyone else — were indistinguishable to the code.

The attack

At 13:05 UTC on October 15, the attacker submitted the first malicious transaction (6KJvWtmrZDi5MxUPkJfDNZTLf2DFGKhQA2WuVAdSRUgH). The attack followed a clean three-phase sequence:

Phase 1 — Price manipulation. The attacker called update_v2 directly — no exploit contract, no flash loan, no reentrancy. Just a direct function call with fabricated prices. In one instance, a token's oracle price was set to 651,548,270 while another was set to 1. The UpdateAuthority shared object (accessible to anyone) was passed as an argument, the vector::contains check returned false, nobody read the false, and update_() executed with the attacker's prices.

Phase 2 — Arbitrage extraction. The TLP pool relied entirely on oracle prices for swap calculations. With a 651-million-to-1 price ratio, the attacker could swap tiny amounts of one token for enormous amounts of another. In one swap, 1 SUI was exchanged for approximately 60,000,000 xBTC base units (0.6 xBTC at 8 decimals — roughly 0.6 BTC in value). Ten separate manipulation-then-swap sequences drained the pool systematically.

Phase 3 — Exit. The stolen suiETH, xBTC, and SUI were converted to USDC through Cetus, Haedal Protocol, and Turbos Finance. Approximately 3,430,717 USDC was bridged to Ethereum via Circle's CCTP in 14 separate transactions, then swapped to 3,430,241.91 DAI on Curve. The attacker's initial funding — 0.041 ETH — originated from Tornado Cash on BSC.

Total loss: 588,357.9 SUI + 1,604,034.7 USDC + 0.6 xBTC + 32.227 suiETH. Approximately $3.44 million.

The team detected the attack at 13:24 (19 minutes in), paused all contracts at 13:39, and identified the root cause by 13:42 — three minutes after pausing. The fix was obvious once you saw the missing assert!. Finding it was the hard part.

The fix — and what it reveals about the original design

Five days after the exploit, Typus pushed commit 4e118f0 — a major refactor of the oracle module. The change wasn't just adding an assert!. They redesigned the authorization model entirely:

A note on what the fix is not: UpdateCap is still a shared object (transfer::share_object() in create_update_cap). Anyone can reference it in a transaction. The access control is still a runtime check — the for: address field binds the cap to a specific sender, and assert! enforces it. This is not an owned-capability pattern (the codebase already has one — ManagerCap, which uses transfer::transfer and can only be presented by its owner). Typus likely chose the shared pattern because multiple oracle updater addresses (automated crankers) need to reference the cap concurrently, which an owned object would block.

The post-fix update_with_update_cap:

public fun update_with_update_cap(
    oracle: &mut Oracle,
    update_cap: &UpdateCap,
    price: u64,
    twap_price: u64,
    clock: &Clock,
    ctx: &TxContext,
) {
    version_check(oracle);
    assert!(update_cap.`for` == ctx.sender(), EInvalidUpdateCap);
    update_(oracle, price, twap_price, clock, ctx);
}

The entire defense is one assert!. Remove it and the cap's for field is decoration — exactly the same failure mode as the original vector::contains() call. The fix works, but it is procedural (a runtime check the next developer must remember to keep), not structural (an ownership constraint the type system enforces). That is worth stating plainly: the system that lost $3.44M to a forgotten check was fixed by adding a check and not forgetting it this time.

What a linter sees

I ran the vulnerable oracle.move through a static analysis pass looking for a specific pattern: a public function that takes a mutable reference (&mut) to a shared object but does not require a capability parameter. This is the class of defect that MOV-001 in move-test-gen targets — public state-mutating functions without a capability gate.

The result is instructive but honest: update_v2 takes &UpdateAuthority (an access-control struct), which a name-only heuristic would read as "has authorization." A regex-based linter sees a struct with "Authority" in the name and assumes it is a gate. The actual defect — that the gate's result is discarded — lives one abstraction layer deeper: you need to trace the return value of vector::contains() and confirm it reaches an assert! or an if branch. That is control-flow analysis, not pattern matching.

This is a known ceiling for line-based static analysis. The linter catches the structural shape (public function + mutable shared object + no capability), but the specific failure mode (unused return value of an authorization check) requires either a compiler warning for unused pure-function results or a data-flow analyzer that tracks boolean returns to assertion sites.

Move does not currently emit an "unused return value" warning for pure functions. A Rust-equivalent #[must_use] annotation on vector::contains would have caught this at compile time. That annotation does not exist in Move today.

The uncomfortable pattern

This is the third Sui DeFi exploit I have analyzed in detail — after Cetus ($223M) and Aftermath ($1.14M). The surface details differ — arithmetic overflow, signed-value boundary, authorization bypass — but the structural shape is the same:

1. The code looked correct to every reader. The function name said "check authority." The comment said "check authority." The called function was the right one. The arguments were correct. The only thing missing was one keyword.

2. The module that mattered most was the one that wasn't audited. Aftermath's perpetuals module was a late addition. Typus's oracle module was excluded from scope. The highest-value target is systematically the one with the least review.

3. The fix is trivial in hindsight. assert!(...) instead of a bare call. (x as u128) instead of x * y. These are one-line fixes that would have prevented nine-figure losses. The difficulty was never in writing the fix — it was in knowing the fix was needed.

This is not a tooling problem or an audit problem. It is a coverage problem. The code that controls the most value gets the least scrutiny, because it ships last, ships fastest, or ships outside the scope of an engagement that was scoped months earlier.

Addresses referenced in this analysis:

• Vulnerable package: 0xaf44818c67a878b9eba0c63186b00e80d9fc3d1e2ae02f00fa3993b0e683bff3

• First attack transaction: 6KJvWtmrZDi5MxUPkJfDNZTLf2DFGKhQA2WuVAdSRUgH

• Attacker (Ethereum): 0xeb8a15d28dd54231e7e950f5720bc3d7af77b443

• Funds destination: 0x4502cf2bc9c8743e63cbb9bbde0011989eed03c1

• Vulnerable source: commit a918e98 (September 24, 2025)

• Post-fix source: commit 4e118f0 (October 20, 2025)

Disclosure: I build move-test-gen, an open-source coverage checker and security linter for Sui Move. The linter's MOV-001 rule targets missing access control in public functions — the structural class this exploit belongs to. The specific failure mode (unused authorization return value) is beyond the current linter's reach, as noted above. Credit to Defimon and Typus Finance's post-mortem for the on-chain timeline and financial figures.

I've spent the last month reading exploit post-mortems, scanning production Sui contracts, and building lint rules to catch what I kept seeing. After the third time the same shape showed up, I stopped thinking of these as separate incidents.

They're the same bug wearing different clothes.

Exploit 1: Cetus — $223M (May 2025)

The largest Move exploit to date. A single function in a shared math library — checked_shlw in integer-mate — was supposed to prevent a 256-bit left shift from overflowing. It didn't.

The function checked whether the input was small enough to shift safely:

// BEFORE fix
assert!(n <= MAX_U256 >> 64, ERR_OVERFLOW);
n << 64

For inputs near 2^192, this check passes when it shouldn't. The shift wraps, producing a tiny number from a massive input. Cetus used this function in its liquidity delta calculation. The attacker opened a position with a crafted tick range, deposited approximately 1 token, and received a liquidity credit worth $223M. Then withdrew it.

Attacker: 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06

Fix: assert!(n < (1u256 << 192), ERR_OVERFLOW) — one comparison.

What the auditors saw: A math library everyone imports. checked_shlw — the name says "checked." It has an assert. It looks complete. You'd need to sit down with a pen and work out the 256-bit boundary arithmetic to realize the comparison is wrong. Under audit time pressure, that doesn't happen.

Exploit 2: Aftermath Finance — $1.14M (April 2026)

Different protocol, different operation, same disease.

Aftermath's perpetual futures exchange lets third-party integrators set their own fee rates. The fee type is signed fixed-point. The validation:

assert!(integrator_taker_fee <= max_taker_fee, E_INVALID);

Upper bound only. The attacker set max_taker_fee = 0, then passed a negative fee. Signed comparison: negative ≤ 0 is true. Check passes.

Downstream:

collateral_delta = filled_value - (taker_fee + negative_integrator_fee)

Subtracting a negative number adds. Phantom USDC appears in the account. The attacker deposited 100 USDC, withdrew 100,000+. Eleven times in 36 minutes.

Fix: assert!(integrator_taker_fee >= 0, E_INVALID) — one assert.

OtterSec audited Aftermath in November 2025. The bug shipped in August 2025. It survived a full audit by a top-tier Move firm.

Exploit 3: Bucket Protocol — Unpatched (found July 2026)

This one hasn't blown up yet. I found it while scanning Sui CDP protocols with a lint tool I built.

Bucket's compute_collateral_value_to_buck function calls mul_factor — which safely promotes to u128 internally — and then immediately multiplies the result by pow(10, decimal_diff) as raw u64:

let collateral_raw_value = mul_factor(collateral_amount, price, denominator);
// mul_factor used u128 internally. This line undoes that protection:
collateral_raw_value * pow(10, constants::buck_decimal() - collateral_decimal)

If collateral_decimal > buck_decimal(9) and the value is large enough, this overflows. The function is called by is_in_recovery_mode, is_liquidatable, is_healthy_bottle, and handle_redeem. An overflow here blocks liquidation, redemption, and health checks — the protocol's core safety functions stop working.

Current deployments use SUI (9 decimals = BUCK decimals), so pow(10, 0) = 1 — no overflow today. But create_bucket lets admins add new collateral types with arbitrary decimals, and there's no guard. The code is safe by accident, not by design.

Fix: u128 intermediate cast — PR submitted.

OtterSec audited Bucket in 2023 and found a related issue (OS-BKT-ADV-00, "Improper Conversion" — critical, resolved). The fix for that issue introduced compute_collateral_value_to_buck. The overflow in the fix is a new bug.

Four audit firms reviewed Bucket (OtterSec, MoveBit, Hashlock, Quantstamp). None caught this.

The Pattern

Three protocols. Three different operations (shift, subtraction, multiplication). Three different triggers (boundary input, negative value, decimal scaling). But strip away the surface and it's the same thing every time:

A math function that returns the wrong answer for inputs the developer didn't consider, protected by a check that looks complete but isn't.

The pattern isn't "developers write bad math." The math is usually correct for the inputs the developer imagined. The pattern is: the boundary between correct and catastrophic is one comparison, and it's invisible to a reviewer scanning for logic bugs.

Why Audits Keep Missing This

I don't think this is an auditor quality problem. I think it's a structural mismatch between how audits work and how arithmetic bugs hide.

An auditor reads code and asks: "Does this logic do what it claims?" For business logic — access control, state transitions, economic flows — that question works. You can read the intent and check the implementation.

For arithmetic boundary bugs, the question doesn't work. checked_shlw does exactly what its name and comment say — it checks and shifts. The bug is in the arithmetic of the check itself, and you can't see it without computing the actual boundary. An auditor under time pressure sees a named function with an assert and moves on. That's rational behavior — the alternative is manually verifying every comparison in every math function, which no audit budget covers.

This is the gap static analysis fills. Not because tools are smarter than auditors — they're not. Because tools don't have time pressure. A lint rule that flags "u64 multiplication without u128 promotion" runs in milliseconds on every file. It catches the 5 sites out of 500 where the developer skipped the cast, and an auditor can spend their limited time on the hard problems instead.

What I Took Away

I've been building a lint tool for Sui Move (move-test-gen) and these three incidents shaped what it checks:

• MOV-002 exists because of Cetus — flag unchecked multiplications

• MOV-004 exists because of Bucket — flag unchecked downcasts

• The Aftermath analysis taught me that signed types need entry-point validation, not just conversion-boundary checks

But honestly, the bigger lesson isn't about any specific rule. It's that the math layer is where Move's safety guarantees end and where the money is. Move prevents reentrancy, enforces object ownership, and catches type errors at compile time. It doesn't prevent 2^192 << 64 from wrapping. Three protocols, three audits (seven total across them), $224M lost and counting.

The fix every time is one line. The cost of missing it is nine figures.

On-chain data verified via Sui RPC. Cetus attacker 0xe28b...ff06 confirmed at 2025-05-22 10:30:50 UTC. Aftermath attacker 0x1a65...d41e confirmed at 2026-04-29 08:55:50 UTC. Bucket PR references commit 0ad3cb5 (OtterSec audit scope).

References: Cyfrin (Cetus) · DarkNavy (Aftermath) · OtterSec Bucket audit

The Problem

Sui's built-in linter has 6 rules — all focused on object handling (self-transfer, share-owned, etc.). Nothing about arithmetic overflow, missing access control, or unsafe type casting. MoveScanner exists but is closed-source and commercial.

If you're writing Move and want a slither-equivalent that checks security patterns on every PR — there isn't one. Or there wasn't.

What move-test-gen Does

Three layers, each independent:

Layer 1 — Assert pairing. Scans every assert! and abort in your source modules, every #[expected_failure] in your tests, and tells you which abort paths have no test coverage. Runs in seconds, needs only Node.js.

Layer 2 — Mutation testing. Injects deterministic bugs (flip a < to >=, comment out an assert!) and checks whether your test suite catches them. If a mutant survives, the test that should have caught it is too weak. 7 operators, exhaustive mode. Needs sui CLI.

Layer 3 — Security lint. 4 rules that scan for common vulnerability patterns:

MOV-002 and MOV-004 use a lightweight Move parser (scripts/move-parser.mjs) that tracks variable types through declarations, casts, and naming conventions. So it knows that numerator1 assigned from liquidity_u256 << RESOLUTION is u256 — no false positive on the multiplication.

What It Found on Real Protocols

I ran the linter against four production Sui DeFi protocols:

Kriya DEX — 1 finding

🔴 HIGH  spot_dex.move:187  [MOV-001]
  public function modifies state without capability check:
  `update_pool` takes &mut but no capability parameter

This is the same access control gap I reported manually in a 6-finding security review. The rule catches it in under a second on 3 source files.

Scallop Lending (172 files) — 2 findings

🔴 HIGH  liquidation_evaluator.move:143  [MOV-002]
  `LIQUIDATION_CAP_DIVISOR * debt_price_raw` — overflow risk

🟡 MEDIUM  limiter.move:189  [MOV-004]
  `(i as u64)` — downcast without overflow check

Initial run hit 82 false positives. Generic functions fun name<X, Y>() were invisible to the regex, test modules were scanned, Sui-specific patterns like Witness<T> and Version params weren't recognized. 9 commits to fix all of that. After hardening: these 2 legitimate findings, zero false positives on production code.

Bucket Protocol — Fix PR Submitted

MOV-002 flagged three sites in compute_collateral_value_to_buck and compute_buck_value_to_collateral where mul_factor (which safely promotes to u128 internally) is followed by a raw u64 multiplication that undoes the protection. I submitted a fix PR — three lines changed, u128 intermediate cast.

The overflow doesn't affect current deployments (SUI is 9 decimals = BUCK decimals, so the scaling factor is 1), but adding a collateral type with higher decimals would break liquidation, redemption, and health checks. The OtterSec V1 audit caught a related conversion issue but not the overflow in the fix itself.

How to Use It

One-liner (no install)

npx mehvetero/move-test-gen sources tests --lint

In CI — GitHub Action

# .github/workflows/move-security.yml
name: move-security
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: mehvetero/move-test-gen@v1.3.0
        with:
          sources: sources
          tests: tests
          lint: 'true'

Layer 1 + lint runs in seconds with zero dependencies. For mutation testing, add mutate: 'true' and install sui — there's a nightly schedule example in the repo.

Marketplace: move-test-gen coverage check

As an Agent Skill

The tool is also an agentskills-compatible skill. Install:

npx skills add mehvetero/move-test-gen

Then ask your coding agent: "Generate edge-case tests for sources/vault.move" — it produces #[test] and #[expected_failure] functions covering boundary values, arithmetic overflows, access control violations, and economic edge cases.

Agent Skill listing: agentskills Discussion #451

How It Compares

The gap this fills: there's no open-source tool that does security-focused static analysis on Sui Move. The built-in linter handles object patterns. MoveScanner is commercial. Aptos has mutation tools but they don't work on Sui. This tool covers the middle ground — regex + parser based, not compiler-grade, but catches the patterns that actually show up in exploits.

Measured, Not Trusted

The tool has an eval lab (eval/) with 5 campaigns, 13 scenarios, and 47 rounds of testing. Frozen prompt templates, retirement-by-saturation protocol, dated records. The methodology is borrowed from TheColliery — full lineage in the RESULTS.md.

The lint rules were validated against Kriya DEX, Scallop (172 files), Bucket Protocol, and Turbos CLMM. Every false positive fix gets a selftest pin before it ships — 11 regression cases, all enforced in CI.

What's Next

• More rules — clock staleness, upgrade policy, shared object access patterns

• Parser improvements — tracking types through function calls, not just declarations

• More protocol scans — each scan either validates the rules or finds a new pattern to handle

• Contribution: if you have a Move security pattern that should be a rule, open an issue or PR a rules/mov-NNN-*.mjs file

Repo: github.com/mehvetero/move-test-gen Marketplace: move-test-gen coverage check

TL;DR

• Protocol: Aftermath Finance Perpetuals (Sui Network)

• Date: April 29, 2026

• Loss: $1,139,927 USDC across 11 transactions in 36 minutes

• Root cause: Signed fixed-point fee value accepted without non-negativity check. fee <= max was validated, fee >= 0 was not.

• Auditor: OtterSec (November 2025) — did not catch this issue

• Fix: One assert: assert!(integrator_taker_fee >= 0)

Background: What Aftermath Perps Does

Aftermath Finance operates a fully onchain perpetual futures exchange on Sui. Unlike hybrid architectures that rely on off-chain sequencers, every order, match, and settlement executes in Move smart contracts.

The protocol supports an integrator system — third parties can integrate with Aftermath's clearing house and charge their own fees on top. Each integrator registers a fee configuration per user account.

This is the system the attacker exploited.

The Vulnerable Code Path

The perpetuals contracts are not open-source. The reconstruction below is based on DarkNavy's on-chain bytecode disassembly, which preserved the decompiled Move code in full.

On-Chain Addresses

Step 1: Fee Validation (the bug)

When a trade executes, the clearing house calculates taker fees:

// clearing_house.move (reconstructed from disassembly)
fun calculate_taker_fees(
    position, account, quote_filled, base_fee, gas_fee, integrator_info
) {
    let integrator_taker_fee = get_integrator_taker_fee(integrator_info);
    let max_taker_fee = get_integrator_max_taker_fee(account);
    
    // THE BUG: only upper-bound check
    assert!(integrator_taker_fee <= max_taker_fee, invalid_integrator_taker_fee);
    
    // missing: assert!(integrator_taker_fee >= 0, invalid_integrator_taker_fee);
    
    // ... compute fees
}

The comparison uses a signed fixed-point type. The less_than_eq function in the fixed-point library does signed comparison:

// signed fixed-point library
public fun less_than_eq(a: u256, b: u256): bool {
    return (a ^ SIGN_BIT) <= (b ^ SIGN_BIT);
}

The XOR with SIGN_BIT converts to two's complement ordering. Any negative value has SIGN_BIT set, so after XOR it becomes a small number — smaller than zero (which has SIGN_BIT unset after XOR). Result: negative <= 0 is always true.

Step 2: Collateral Calculation (the damage)

After fees are "validated," the clearing house applies them to the taker's collateral:

// clearing_house.move (reconstructed)
fun process_fill_taker(position, account, ...) {
    let (taker_fee_total, integrator_fee_total, integrator_addr) = 
        calculate_taker_fees(position, account, quote_filled, base_fee, gas_fee, integrator_info);
    
    // THE CRITICAL LINE
    let collateral_delta = filled_value - (taker_fee_total + integrator_fee_total);
    
    position::add_to_collateral_usd(position, collateral_delta, price_scale);
}

When integrator_fee_total is negative:

collateral_delta = filled_value - (taker_fee + NEGATIVE_FEE)
                 = filled_value - (taker_fee - |fee|)
                 = filled_value - taker_fee + |fee|

The negative fee adds to the collateral instead of subtracting. The taker account receives phantom USDC credit that does not correspond to any real deposit.

Step 3: Cash Out

The attacker then calls two functions to convert phantom collateral into real USDC:

// 1. Move collateral from position to account balance
clearing_house::deallocate_collateral(clearing_house, account, amount);

// 2. Withdraw account balance as actual USDC
account::withdraw_collateral(account, amount);

The to_balance conversion function in the fixed-point library actually checks for negative values:

public fun to_balance(value: u256, scale: u256): u64 {
    if (value >= SIGN_BIT) abort 0;  // rejects negative!
    return (value / scale) as u64;
}

But this check is at the exit boundary, not at the entry point. By the time the flow reaches to_balance, the collateral delta has already been computed as a large positive number (filled_value + |fee|). The negative value was consumed in the fee subtraction step — it never reaches to_balance.

Defense-in-depth failure: the inner function rejects negative, but the outer function lets it in. The attacker's path never touches the inner function with a negative value.

The Attack Transaction by Transaction

The attacker followed the same pattern in each PTB (Programmable Transaction Block):

1. Create two fresh accounts (maker + taker) via interface::create_and_return_account
2. Create positions for both accounts
3. Deposit 100 USDC into the maker-side account ONLY
4. Create integrator vault for attacker's address
5. Add integrator config to taker-side account: max_taker_fee = 0
6. Place a limit order on the maker side
7. Call clearing_house::create_integrator_info(attacker_address, NEGATIVE_FEE)
8. Start taker session → market order fills against maker
9. End session → deallocate free collateral → withdraw USDC from taker
10. Clean up transient accounts

100 USDC deposited on maker side → 100,000+ USDC withdrawn from taker side. The delta is pure phantom collateral.

All 11 Profitable Transactions

Total: $1,139,927 USDC net gain. Seeded with only $1,100 USDC across maker accounts.

Why the Audit Missed It

OtterSec audited Aftermath Perps in November 2025. The vulnerability was introduced in August 2025 — it was in-scope during the audit.

This is not a knock on OtterSec. They are a top-tier Move auditor. But the bug reveals a systematic blind spot in manual review:

The code reads correct. assert!(fee <= max_fee) looks like a complete validation. A reviewer scanning the fee path sees a bounds check and moves on. The absence of a lower-bound check is invisible unless the reviewer specifically asks: "can this signed value be negative, and what happens if it is?"

Manual review checks what IS there. A linter checks what ISN'T there.

A static rule — "signed fixed-point value accepted as function parameter without assert!(value >= 0) in the validation path" — would have flagged calculate_taker_fees on the first scan.

The Pattern: Upper-Bound-Only Validation on Signed Types

This is not unique to Aftermath or Move. The pattern appears wherever:

1. A protocol uses signed types for values that must be non-negative (fees, amounts, rates, prices)

2. Validation checks x <= max but not x >= 0

3. A negative value inverts arithmetic downstream

Other instances of this pattern class:

• Dango DeFi (April 2026, Sui): Insurance fund donations accepted without checking amount > 0. Negative donations extracted collateral. $410K drained, returned by whitehat.

• Traditional finance: Signed integer underflows in banking transaction processors have caused similar issues — a negative transfer amount credited instead of debited.

The defense is simple: every entry point that accepts a value which must be non-negative needs an explicit lower-bound assert, regardless of what inner functions check.

What Would Have Caught This

At the code level

// One line. That's the entire fix.
assert!(integrator_taker_fee >= 0, invalid_integrator_taker_fee);

At the tooling level

A lint rule scanning for signed-type parameters without non-negativity asserts. The rule would flag any function that:

• Accepts a signed fixed-point value as input

• Uses that value in arithmetic (subtraction, addition to balances)

• Has no assert!(value >= 0) or equivalent guard before the arithmetic

This is the class of bug that manual review systematically misses and static analysis systematically catches.

Timeline

Key Takeaways

1. Signed types in financial code are a loaded gun. If a value must be non-negative, validate at the entry point — not at a downstream conversion function.

2. x <= max is not a complete bounds check on signed values. The lower bound matters. This is obvious in retrospect and invisible in review.

3. Move's type safety didn't help here. Move prevents reentrancy, memory corruption, and unauthorized object access. It does not prevent signed arithmetic bugs or missing input validation. The "Move is safe" narrative needs qualification.

4. Audits have systematic blind spots. A top-tier auditor reviewed this code and missed it. The bug is not subtle — it is a one-line omission. But manual review optimizes for what IS there, not what ISN'T. Tooling fills this gap.

5. The entire exploit was a single PTB. No flash loans, no oracle manipulation, no multi-transaction setup. Open accounts, set negative fee, trade, withdraw. Clean enough to repeat 11 times in 36 minutes.

Analysis based on DarkNavy's on-chain disassembly. Source contracts are not public — all code shown is reconstructed from bytecode.

Post-mortem notes maintained at defi-incident-notes.