Swapos V2 Pair Exploit — Broken `k`-Value Invariant Lets 10 wei of WETH Drain ~98% of the Pool's SWP

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2023-04-Swapos_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Swapos_exp.sol.

Vulnerability classes: vuln/arithmetic/precision-loss · vuln/arithmetic/decimal-mismatch

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the main DeFiHackLabs repo contains several unrelated PoCs that do not compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_SwaposV2Pair.sol.

Key info#

References: CertiKAlert · BeosinAlert ("judgment error in the k-value, which allows the attacker to withdraw funds from the pair contract").

TL;DR#

SwaposV2Pair.swap() implements the Uniswap-V2 constant-product check but with the wrong scaling factors (contracts_SwaposV2Pair.sol#L180-L182):

uint balance0Adjusted = balance0.mul(10000).sub(amount0In.mul(10));
uint balance1Adjusted = balance1.mul(10000).sub(amount1In.mul(10));
require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'SwaposV2: K');

The adjusted balances are scaled by 10,000 each (LHS scales by 1e8), but the invariant RHS is reserve0 * reserve1 * 1000^2 = scaled by 1e6. In real Uniswap V2 both sides are scaled by 1000/1000^2 (LHS 1e6, RHS 1e6). Swapos' mismatch makes the LHS ~100x larger than intended, so the require(... 'SwaposV2: K') gate is satisfied with a trivial input.

Concretely: sending just 10 wei of WETH should buy 10,887 wei of SWP under correct x·y=k. Under Swapos' broken check it buys up to ≈144,201 SWP. The PoC exploits exactly this, calling swap with amount0Out = 142,658.16 SWP after donating 10 wei WETH — draining 97.94% of the pool's SWP in a single call. The attacker can then dump that SWP in other pairs for risk-free profit.

Background — what SwaposV2Pair does#

SwaposV2Pair is a near-verbatim Uniswap-V2-style AMM pair holding two ERC20s (here SWP and WETH). The fork-block state of the SWP/WETH pair, read from the trace's storage writes and Sync/Swap events:

The pair enforces x·y = k only inside swap(). The whole exploit hinges on that check being wrong.

The vulnerable code#

The invariant check inside swap() (contracts_SwaposV2Pair.sol#L159-L187):

function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
    require(amount0Out > 0 || amount1Out > 0, 'SwaposV2: INSUFFICIENT_OUTPUT_AMOUNT');
    (uint112 _reserve0, uint112 _reserve1,) = getReserves();
    require(amount0Out < _reserve0 && amount1Out < _reserve1, 'SwaposV2: INSUFFICIENT_LIQUIDITY');
    ...
    balance0 = IERC20(_token0).balanceOf(address(this));
    balance1 = IERC20(_token1).balanceOf(address(this));
    uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
    uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
    require(amount0In > 0 || amount1In > 0, 'SwaposV2: INSUFFICIENT_INPUT_AMOUNT');
    { // scope for reserve{0,1}Adjusted, avoids stack too deep errors
    uint balance0Adjusted = balance0.mul(10000).sub(amount0In.mul(10));   // ⚠️ scaled by 10000, fee = 10
    uint balance1Adjusted = balance1.mul(10000).sub(amount1In.mul(10));   // ⚠️ scaled by 10000, fee = 10
    require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'SwaposV2: K');  // ⚠️ RHS scaled by 1000^2
    }
    _update(balance0, balance1, _reserve0, _reserve1);
    emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
}

Compare with the canonical Uniswap V2 check (v2-core UniswapV2Pair.sol):

uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K');

The only difference — and the entire bug — is the multiplier on the adjusted balances: Swapos uses 10000/fee 10 where Uniswap uses 1000/fee 3. The RHS (1000**2) was left untouched, so the LHS (which scales as 10000 × 10000 = 1e8) is 100x too large relative to the RHS (1e6).

Root cause — why it's exploitable#

The constant-product invariant is the only thing preventing an attacker from printing free output tokens. It requires, after a swap, that the fee-adjusted product of balances is at least the prior reserve0 * reserve1 (both sides scaled identically so the scaling cancels).

Swapos scales the two sides differently:

• LHS factor: 10000 × 10000 = 1e8
• RHS factor: 1000 × 1000 = 1e6
• Ratio LHS/RHS = 100x too loose

With 100x slack, balance1Adjusted can be ~100x smaller than reserve1 would allow. Because amount1In is subtracted from balance1 before scaling, an attacker can shrink the input to near-dust. Verified numerically against the trace:

Beosin's post-mortem described this exactly as a "judgment error in the k-value, which allows the attacker to withdraw funds from the pair contract."

Preconditions#

• A SwaposV2Pair is deployed with the buggy swap() (the SWP/WETH pair qualifies).
• Enough output-token liquidity to be worth stealing (the pair held 145,658 SWP).
• A non-zero amount0In/amount1In — satisfied by transferring any non-zero dust of the input token to the pair before calling swap (10 wei suffices).
• Working capital: effectively zero — 10 wei of WETH is below any rounding threshold. The 3 WETH minted in the PoC is only used to obtain the 10 wei; it is not consumed.

Attack walkthrough (with on-chain numbers from the trace)#

token0 = SWP, token1 = WETH, so reserve0 = SWP, reserve1 = WETH. All figures from the Sync/Swap/Transfer events and storage writes in output.txt.

Net: the attacker paid 10 wei of WETH (≈ 1e-17 WETH) and received 142,658.16 SWP (97.94% of the SWP reserve). The pool's SWP reserve collapsed to 3,000 SWP while its WETH reserve was unchanged bar 10 wei.

Profit/loss accounting (per PoC trace)#

The PoC does not itself swap the stolen SWP back to WETH/USD, so a USD profit figure is not derivable from this trace; the realized profit equals the dump value of 142,658 SWP across other venues minus gas. The exploit's defining fact is the price paid: 10 wei of WETH for ~98% of the reserve.

Diagrams#

Sequence of the attack#

Pool state + invariant evolution#

Why the K-check is wrong (the flow inside swap)#

Correct vs. broken invariant (constant-product)#

Why each magic number#

• amount1In = 10 (10 wei WETH): chosen to be the smallest non-zero value that satisfies require(amount0In > 0 || amount1In > 0) (contracts_SwaposV2Pair.sol#L178). Any non-zero dust works because the K-check is 100x loose; 10 wei is essentially free.
• **amount0Out = 142,658.161145 SWP (= reserve0 − 3,000 SWP):** sized to the maximum the broken invariant tolerates while still satisfying amount0Out < _reserve0([contracts_SwaposV2Pair.sol#L162](https://github.com/sanbir/evm-hack-registry/blob/main/2023-04-Swapos_exp/sources/SwaposV2Pair_8ce2F9/contracts_SwaposV2Pair.sol#L162)). The pool is left with 3,000 SWP — the largest residual that keeps(balance0·10000)·(balance1·10000 − 10) ≥ reserve0·reserve1·1e6` true.
• Why 3,000 SWP remains, not 0: the invariant still constrains something. Solving (3000·10000)·((133.39+10wei)·10000 − 10) ≥ 145658·133.39·1e6 holds with margin, but pushing amount0Out higher breaks it. 3,000 SWP is the boundary the PoC selects.
• 3 WETH deposit: only to source the 10 wei (and cover gas); 2.99999999999999999 WETH is left over and untouched.

Remediation#

1. Fix the K-check scaling. Restore canonical Uniswap-V2 constants so both sides scale identically:
   SOLIDITYCopy

   uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
   uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
   require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'SwaposV2: K');
   

   If a 10 bps fee is desired instead of 30 bps, keep the LHS at 10000/10 and bump the RHS to (10000)**2 so the scaling cancels.
2. Redeploy every affected pair. The pair bytecode is immutable; patching the source does not retroactively fix deployed pairs. All SwaposV2Pair instances sharing this bytecode must be migrated to a corrected factory, with liquidity migrated and the old pairs paused/delisted.
3. Add a swap-amount sanity bound (e.g., revert if amountOut exceeds a small fraction of the reserve absent a large amountIn), as a defense-in-depth guard against future scaling/fee bugs.
4. Audit any other forks. Verify _update, mint, burn, skim, and sync carry no analogous constant drift; this looks like an incomplete Uniswap-V2 fork where one fee constant was edited but its counterpart was not.
5. Formal/property test the AMM. A single fuzz test asserting "0-value-in ⇒ 0-value-out" and "getAmountOut ≤ swap output" would have caught this instantly.

How to reproduce#

The PoC lives in a standalone Foundry project:

_shared/run_poc.sh 2023-04-Swapos_exp --mt testExploit -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required for the fork at block 17,057,419 (April 16, 2023). foundry.toml uses https://mainnet.infura.io/...; pruned public RPCs may fail with missing trie node.
• Result: [PASS] testExploit().

Expected tail (copied from output.txt):

Ran 1 test for test/Swapos_exp.sol:ContractTest
[PASS] testExploit() (gas: 111690)
Logs:
  swapos balance: 3000.000000000000000000
  ETH balance: 133.386512258125308315

Reference: SlowMist Hacked — https://hacked.slowmist.io/ (Swapos, Ethereum). Beosin/CertiK alerts: "judgment error in the k-value."

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-04-Swapos_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Swapos_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Swapos V2 Pair Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.