KyberSwap Elastic Exploit — Tick-Boundary Precision Loss Doubles Pool Liquidity

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-11-KyberSwap_exp.eth.1 in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/KyberSwap_exp.sol.

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

This PoC reproduces the November 2023 KyberSwap Elastic incident against one of the many pools that were drained — the frxETH/WETH KS2 Reinvestment-Token pool on Ethereum mainnet. The same root cause (a tick-boundary rounding error that lets an attacker double the pool's active liquidity) was used to drain ~17 pools across multiple chains for a total of ~$46–48M. The figures below are exact for the frxETH/WETH pool reproduced here.

Key info#

TL;DR#

KyberSwap Elastic is a Uniswap-V3-style concentrated-liquidity AMM. Active liquidity (baseL) is adjusted as the price crosses initialized ticks by adding/subtracting that tick's liquidityNet. The crossing is symmetric only if the price genuinely lands on the tick.

The flaw lives in SwapMath.computeSwapStep / calcReachAmount: every reach calculation is rounded down (mulDivFloor) "so we avoid giving away too much." When a swap is sized so the price should reach an initialized tick, the floored arithmetic instead leaves the new sqrtP one wei short of that tick. The pool's loop (Pool.sol:413-419) sees sqrtP != nextSqrtP, treats the step as not having crossed the tick, breaks without applying liquidityNet, yet records the new currentTick as already being on the other side of that boundary (Pool.sol:416). The pool's tick bookkeeping and its baseL are now desynchronized.

An attacker who mints a tiny LP position straddling that exact boundary, then swaps back across it, makes the pool add the position's liquidity a second time without ever having removed it — the trace shows the active liquidity field jumping from 74,692,747,583,654,757,908 to exactly double, 149,385,495,167,309,515,816 (output.txt:234 vs output.txt:268). With phantom liquidity backing it, a final exact-output swap pulls essentially all of the pool's WETH out at a price the real reserves cannot support. Everything is wrapped in an Aave flash loan, so the attacker needs no capital.

Background — KyberSwap Elastic mechanics#

KyberSwap Elastic (Pool / KS2-RT) is a concentrated-liquidity DEX. The relevant pieces:

• baseL — the active base liquidity currently in range (Pool struct, used in every swap step).
• reinvestL — auto-compounding fee liquidity (the "reinvestment" mechanism; KS2-RT is the reinvestment receipt token).
• Initialized ticks form a doubly-linked list (Linkedlist.sol). Each tick stores a signed liquidityNet. When the price crosses tick T going up, baseL += liquidityNet[T]; going down, baseL -= liquidityNet[T]. This bookkeeping is implemented by _updateLiquidityAndCrossTick and is the heart of every V3-style AMM's correctness.
• The swap loop (Pool.sol:371-464) walks one initialized tick at a time. For each step it calls SwapMath.computeSwapStep, which returns the amount used and the resulting sqrtP. If sqrtP reached the target tick, the loop crosses it (applies liquidityNet); otherwise it breaks.

On-chain state of the frxETH/WETH pool at the fork block (from the trace):

The vulnerable code#

1. Every reach amount is floored — the price falls short of the tick#

calcReachAmount computes how much input is needed to move sqrtP exactly to the next tick. Note the floor rounding on every branch:

// isExactInput, isToken0 == false (token1 in, price up — the attacker's direction)
uint256 denominator = C.TWO_FEE_UNITS * currentSqrtP - feeInFeeUnits * targetSqrtP;
uint256 numerator = FullMath.mulDivFloor(            // ← rounds DOWN
  liquidity,
  C.TWO_FEE_UNITS * absPriceDiff,
  denominator
);
reachAmount = FullMath.mulDivFloor(numerator, currentSqrtP, C.TWO_POW_96).toInt256(); // ← rounds DOWN

Because reachAmount is rounded down, the actual price produced by calcFinalPrice (SwapMath.sol:253-280) lands a hair below targetSqrtP — it does not equal the tick's sqrt price.

2. The loop treats "almost reached" as "not crossed" but still advances the tick#

// Pool.sol — inside the swap while-loop
(usedAmount, returnedAmount, deltaL, swapData.sqrtP) = SwapMath.computeSwapStep(...);
...
// if price has not reached the next sqrt price
if (swapData.sqrtP != swapData.nextSqrtP) {           // ← off by 1 wei ⇒ TRUE
  if (swapData.sqrtP != swapData.startSqrtP) {
    swapData.currentTick = TickMath.getTickAtSqrtRatio(swapData.sqrtP); // ← tick advances anyway
  }
  break;                                              // ← liquidityNet NEVER applied
}
swapData.currentTick = willUpTick ? tempNextTick : tempNextTick - 1;
...
(swapData.baseL, swapData.nextTick) = _updateLiquidityAndCrossTick(...); // ← skipped

So after the swap the pool believes the price is on one side of the boundary tick (the currentTick was updated via getTickAtSqrtRatio, Pool.sol:416), while baseL was computed as if it were still on the other side (the cross at Pool.sol:457-463 was skipped by the break).

3. _getInitialSwapData re-derives nextTick from the desynced state#

function _getInitialSwapData(bool willUpTick) internal view returns (...) {
  ...
  nextTick = poolData.nearestCurrentTick;            // derived from the corrupted currentTick
  if (willUpTick) nextTick = initializedTicks[nextTick].next;
}

On the next swap, the pool starts from the corrupted nearestCurrentTick/currentTick. When the attacker now swaps back across the same boundary tick, the loop crosses it "again" and applies that tick's liquidityNet — even though it was never removed the first time. The attacker's freshly minted position is therefore counted twice, doubling baseL.

Root cause — why it was possible#

A concentrated-liquidity AMM is only solvent if baseL and the tick-crossing bookkeeping stay perfectly in lockstep: every wei of liquidity added at a tick must be added to / removed from baseL exactly once when the price crosses that tick. KyberSwap's swap step rounds the price-to-tick calculation down, so the price stops one wei short of an initialized tick. The pool then makes two contradictory decisions in the same step: it advances currentTick past the tick (via getTickAtSqrtRatio on the off-by-one price) but skips the _updateLiquidityAndCrossTick call that would apply the tick's liquidityNet. The state machine is now inconsistent, and a follow-up swap re-applies the liquidity, doubling the active liquidity for free.

The four facts that compose into a critical, capital-free exploit:

1. Asymmetric / floored rounding in calcReachAmount and calcFinalPrice (SwapMath.sol:124-161) makes "price reaches the tick" practically unattainable — the result is always a wei short.
2. The sqrtP != nextSqrtP branch is the only gate on whether liquidityNet is applied (Pool.sol:413-419). A one-wei discrepancy silently skips the cross while the tick still moves.
3. currentTick is recomputed from the (off-by-one) sqrtP (Pool.sol:416), so the pool thinks it crossed even though baseL says otherwise — the desync is persisted to storage via _updatePoolData/nearestCurrentTick (PoolTicksState.sol:105-119).
4. Anyone can mint a position straddling the exact boundary through the whitelisted AntiSnipAttackPositionManager (Pool.sol:171-215) and then drive the price with permissionless swap() calls, so the attacker fully controls where the boundary lands and when it is re-crossed.

This is the bug BlockSec titled "Yet another tragedy of precision loss."

Preconditions#

• A pool with at least one initialized tick the attacker can straddle, and enough real liquidity on the WETH side to be worth draining (here 2.13 WETH).
• Ability to mint/burn a concentrated position via the whitelisted position manager (permissionless for any EOA — AntiSnipAttackPositionManager is whitelisted, but callers of it are not gated).
• Working capital to size the boundary swaps. Fully flash-loanable: the PoC borrows 2,000 WETH from Aave v3 and repays 2,001 WETH (0.05% premium) inside the same transaction (test/KyberSwap_exp.eth.1.sol:92-93, :170-178).

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

The PoC's _flashCallback (test/KyberSwap_exp.eth.1.sol:97-156) executes four pool interactions inside the Aave flash loan. token0 = frxETH, token1 = WETH; the attacker only ever sells/buys WETH (isToken0 = false on all swaps).

The proof of the bug is purely mechanical, visible in two trace lines:

output.txt:234  Swap(... liquidity: 74692747583654757908,  currentTick: 111310)   # 7.469e19
output.txt:268  Swap(... liquidity: 149385495167309515816, currentTick: 111105)   # 1.493e20 == 2×

149,385,495,167,309,515,816 = 2 × 74,692,747,583,654,757,908 to the wei. The active liquidity doubled with no corresponding deposit — the only thing that happened between the two swaps was re-crossing the boundary tick. The position's liquidity was counted twice because the first crossing (step 4) advanced the tick but skipped _updateLiquidityAndCrossTick.

Why step 5 drains everything: after the doubling, the pool's quoted exact-output price is backed by phantom liquidity. The pool sends out the requested ~396.24 WETH (deltaQty1 = −396244493223555299358, output.txt:268) while only taking in ~5.87e15 frxETH — far less than the constant-product curve of the real reserves would demand. The victim pool ends with 0 WETH and only dust frxETH (output.txt:332-336).

Profit accounting#

The attacker walks away with 6.364 frxETH + 1.117 WETH of net profit (the small gap vs. the pool drain is the Aave premium + swap fees + the wei left as dust). The pool's entire WETH side is gone (output.txt:10-13). Test result: [PASS] testExploit() (gas: 2,529,592) (output.txt:3-4).

Diagrams#

Sequence of the attack#

Pool liquidity / tick state evolution#

Where the desync is born inside swap()#

Why each magic number#

• swap #1 amount 2000e18 WETH with the precise sqrtPriceLimit 0x100…0000 (20282409603651670423947251286016, = sqrtP at tick 110909): pushes the price exactly to the edge of a zero-liquidity range so the attacker controls the active-liquidity baseline before minting (test:114).
• mint [110909, 111310], qty 89631297100385708499 and removeLiquidity 14938549516730950591: sized so the remaining baseL = 7.469e19 sits straddling the boundary tick the attacker will re-cross — and so the doubled value (1.493e20) is large enough to back the final drain (test:118-140).
• swap #2 amount 387170294533119999999 with limit = MAX_SQRT_RATIO: pushes sqrtP to land one wei short of tick 111310, manufacturing the desync (test:143).
• swap #3 amount −IERC20(WETH).balanceOf(victim) (exact output = the pool's entire WETH balance) with limit = MIN_SQRT_RATIO + 1 (4295128740): re-crosses the boundary (triggering the double-count) and requests all of the pool's WETH as output (test:150).

Remediation#

1. Make tick crossing consistent with the tick the price ends on. The cross of liquidityNet must be decided by which tick the final sqrtP belongs to, not by the brittle sqrtP == nextSqrtP equality. If getTickAtSqrtRatio(sqrtP) advances past a boundary, that boundary's liquidityNet must be applied in the same step. (KyberSwap's actual fix reworked the swap step so the price and the active-liquidity bookkeeping can never disagree.)
2. Round the reach amount conservatively toward the tick boundary, and re-derive currentTick only from a fully-crossed price. Avoid a state where currentTick is past a tick that was never crossed for liquidity purposes.
3. Add a swap-level invariant assertion. After each swap, assert that baseL equals the sum of active positions for the resulting tick (or, more cheaply, that crossing-count parity is preserved). A liquidity value that increases across a swap with no mint is an immediate red flag — the trace's 7.469e19 → 1.493e20 jump would have reverted.
4. Treat any boundary-precision divergence as a hard error, not a silent break. Where the math cannot reach the tick exactly, snap sqrtP to the tick (and cross) or revert, rather than leaving it one wei short and advancing the tick anyway.
5. Defense in depth: reserve solvency check on exact-output swaps. Bound the output of any single swap by the pool's real token balance / curve so phantom liquidity can never authorize paying out more than the constant-product curve of the actual reserves permits.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under a whole-project forge build):

_shared/run_poc.sh 2023-11-KyberSwap_exp.eth.1 --mt testExploit -vvvvv

• RPC: an Ethereum archive endpoint is required (fork block 18,630,391). The project's foundry.toml mainnet alias must point at an archive node that serves historical state at that block; pruned RPCs fail with header not found / missing trie node.
• Result: [PASS] testExploit() — the victim pool's WETH balance goes from 2.134… to 0, and the attacker contract ends holding 6.364… frxETH + 1.116… WETH.

Expected tail:

Ran 1 test for test/KyberSwap_exp.eth.1.sol:KyberswapFrxEthWethPoolExploitTest
[PASS] testExploit() (gas: 2529592)
Logs:
   [ before ]  [ token1 ]  [ victim ] : 2.134741529491887485
   [ after ]   [ token1 ]  [ victim ] : 0.000000000000000000
   [ after ]   [ token0 ]  [ attacker ] : 6.364001987952861764
   [ after ]   [ token1 ]  [ attacker ] : 1.116773260184104614
Suite result: ok. 1 passed; 0 failed; 0 skipped

References: BlockSec — "Yet another tragedy of precision loss: an in-depth analysis of the KyberSwap incident" (https://blocksec.com/blog/yet-another-tragedy-of-precision-loss-an-in-depth-analysis-of-the-kyber-swap-incident-1); SlowMist — "A deep dive into the KyberSwap hack" (https://slowmist.medium.com/a-deep-dive-into-the-kyberswap-hack-3e13f3305d3a); SolidityScan — "KyberSwap Hack Analysis." Total incident loss ~$46–48M across multiple chains/pools; this PoC reproduces the frxETH/WETH pool drain.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-11-KyberSwap_exp.eth.1 (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: KyberSwap_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "KyberSwap Elastic 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.