This is a lower bound: only assets with reliable historical USD prices are counted, so the actual loss may be higher.
0x485e08dc2b6a4b3aeadcb89c3d18a37666dc7d9424961a2091d6b3696792f0f30xfd7b111aa83b9b6f547e617c7601efd997f64703Ethereum0xfbc887823dd414edf76c5da88ffcd9eef2ba87ccEthereum0x93fc0acf77edd68e611f8a776c9995f350f84274Ethereum0x35e6f409565a98500001783ea090e6f669744c83Ethereum0x36240069ff26cecbde04d9e49a2af8d39146263eEthereumOn Ethereum mainnet transaction 0x485e08dc2b6a4b3aeadcb89c3d18a37666dc7d9424961a2091d6b3696792f0f3 in block 18630392, unprivileged EOA 0x50275e0b7261559ce1644014d4b78d4aa63be836 used helper contract 0xaf2acf3d4ab78e4c702256d214a3189a874cdc13 to exploit five KyberSwap Elastic pools in a single transaction. The helper repeatedly moved each pool price near a tick boundary, minted a narrow position through the public whitelisted position manager 0xe222fBE074A436145b255442D919E4E3A6c6a480, triggered a rounding-sensitive swap that left active base liquidity stale, and then reversed the swap to withdraw more assets than the pool should have released.
The root cause is a rounding-direction bug in Kyber Elastic swap math. In the final exact-input token1 step, SwapMath.estimateIncrementalLiquidity rounds fee liquidity down even though the inline comment says it must round up. That understated deltaL lets computeSwapStep return a nextSqrtP on the wrong side of the target tick boundary, and Pool.swap then skips the _updateLiquidityAndCrossTick path that should have updated baseL. The result is stale active liquidity that can be counted again on the reverse swap.
This was an ACT opportunity. The attacker used only public capital sources, public on-chain state, public Kyber Elastic contracts, and a public position manager. The lower-bound value captured by payout address was USD in stablecoins, with USD of gas cost, for a deterministic lower-bound net gain of USD before valuing the additional volatile tokens that were also extracted.
0xc9b826bad20872eb29f9b1d8af4befe8460b50c611062.8067681270.6513086345431000604459792.15546Kyber Elastic is a concentrated-liquidity AMM. Active liquidity is piecewise by tick range, so baseL must change exactly when price crosses an initialized tick. The pool also tracks reinvested fee liquidity as reinvestL, which means swap math must keep price movement and fee-liquidity updates consistent in the final, non-crossing step.
The critical pool in the clearest realization path is the FRAX/USDC pool at 0x36240069ff26cecbde04d9e49a2af8d39146263e, but the same transaction applied the pattern to four other Kyber Elastic pools at:
0xfd7b111aa83b9b6f547e617c7601efd997f647030xfbc887823dd414edf76c5da88ffcd9eef2ba87cc0x93fc0acf77edd68e611f8a776c9995f350f842740x35e6f409565a98500001783ea090e6f669744c830x36240069ff26cecbde04d9e49a2af8d39146263eThe attacker needed no privileged contract access. The seed trace shows public flash liquidity calls into Aave, public token transfers, direct pool swaps, and public position-manager mint and removeLiquidity calls. The AntiSnip position manager is relevant because it is the public whitelisted path used to create and rebalance the narrow boundary position that makes the rounding window exploitable.
The safety invariant that matters is simple: when a swap step reaches or crosses the next initialized tick, the pool must run the tick-cross transition so that baseL reflects the correct active range. If price ends up past the boundary but the pool still takes the non-cross branch, liquidity accounting and price state diverge.
Kyber Elastic documents that nextSqrtP should not exceed targetSqrtP, but the implementation breaks that guarantee in one exact-input path. In SwapMath.estimateIncrementalLiquidity, the exact-input token1 branch uses FullMath.mulDivFloor even though the nearby comment states that deltaL must be rounded up to force nextSqrtP down. Because deltaL is understated, calcFinalPrice can place the post-step price beyond the intended boundary. Pool.swap then compares the returned sqrtP against nextSqrtP and treats the step as non-crossing, which skips _updateLiquidityAndCrossTick and leaves baseL stale. The attacker deliberately engineered a narrow position around the lower boundary so the stale baseL became economically exploitable on the reverse swap. That second swap re-added liquidity that should already have been removed, which is why the pool logs show liquidity doubling from 5109053135792022 to 10218106271584044. This is an ATTACK root cause, not pure MEV, because the exploit depends on a broken code-level invariant in swap execution.
The explicit violated principles are:
The first breakpoint is in Kyber Elastic swap math. The exact-input token1 final-step path says it must round deltaL up so that nextSqrtP is rounded down, but the implementation calls mulDivFloor instead:
// Kyber Elastic SwapMath exact-input token1 path
if (isExactInput) {
if (isToken0) {
deltaL = FullMath.mulDivFloor(
currentSqrtP,
absDelta * feeInFeeUnits,
C.TWO_FEE_UNITS << C.RES_96
);
} else {
// Because nextSqrtP = (liquidity + absDelta / currentSqrtP) * currentSqrtP / (liquidity + deltaL)
// so we round up deltaL, to round down nextSqrtP
deltaL = FullMath.mulDivFloor(
C.TWO_POW_96,
absDelta * feeInFeeUnits,
C.TWO_FEE_UNITS * currentSqrtP
);
}
}
That understated deltaL feeds calcFinalPrice, so the returned sqrtP can land past the target boundary even though the step is treated as a final non-crossing step. The second breakpoint is the branch in Pool.swap that assumes any step with swapData.sqrtP != swapData.nextSqrtP did not cross the next initialized tick:
// Kyber Elastic Pool.swap branch after computeSwapStep
(usedAmount, returnedAmount, deltaL, swapData.sqrtP) = SwapMath.computeSwapStep(
swapData.baseL + swapData.reinvestL,
swapData.sqrtP,
targetSqrtP,
swapFeeUnits,
swapData.specifiedAmount,
swapData.isExactInput,
swapData.isToken0
);
if (swapData.sqrtP != swapData.nextSqrtP) {
if (swapData.sqrtP != swapData.startSqrtP) {
swapData.currentTick = TickMath.getTickAtSqrtRatio(swapData.sqrtP);
}
break;
}
(swapData.baseL, swapData.nextTick) = _updateLiquidityAndCrossTick(
swapData.nextTick,
swapData.baseL,
cache.feeGrowthGlobal,
cache.secondsPerLiquidityGlobal,
willUpTick
);
Because the bugged sqrtP is already beyond the boundary, that break leaves baseL representing the old tick range even though currentTick has moved below the minted lower tick. The FRAX/USDC pool logs show the stale state directly:
Decoded FRAX/USDC events during the seed transaction
Swap log 0x26f:
deltaQty0 = 27736096068180377599999
deltaQty1 = -377259
sqrtP = 289301399671799345325
liquidity = 5109053135792022
currentTick = -388583
Swap log 0x278:
deltaQty0 = -40410314811613531939916
deltaQty1 = 546747
sqrtP = 293539049659837832076
liquidity = 10218106271584044
currentTick = -388292
Those values matter because the attacker’s narrow position sits at ticks -388582 to -388180. After the trigger swap, currentTick is already below tickLower, yet liquidity still reports 5109053135792022 instead of being removed from the active range. The reverse swap then traverses the same boundary again and re-adds liquidity that should already have been removed, which is why the reported active liquidity doubles.
The attacker prepared that state deliberately. The decoded helper logs for the same pool show the exact liquidity engineering:
Step 3, building up fake liquidity:
initL = 3547889445829
Glitch Liquidity = 5112601025237851
exactLiqNeeded = 5109053135792022
amt0 = 150481319823445010406
amt1 = 452415
That matches the pool receipt logs:
0x25b: qty = 6130843304189434, qty0 = 150480817665596601916, qty1 = 4524150x261: qty = 1021790168397412, qty0 = 25079717812725759910, qty1 = 75401So the exploit sequence is deterministic at code level and on chain:
baseL equals the exact glitch-liquidity target.Pool.swap still takes the non-cross branch.The full adversary cluster is:
0x50275e0b7261559ce1644014d4b78d4aa63be8360xaf2acf3d4ab78e4c702256d214a3189a874cdc130xc9b826bad20872eb29f9b1d8af4befe8460b50c6The transaction sequence contains one adversary-crafted transaction, 0x485e08dc2b6a4b3aeadcb89c3d18a37666dc7d9424961a2091d6b3696792f0f3, against pre-state sigma_B at block 18630391. The seed trace shows the helper receiving public flash liquidity, then repeating the same four-stage pattern across five pools.
For the FRAX/USDC pool, the decoded execution flow is:
deltaQty0 = 5767742213478846776600, deltaQty1 = -4807432959, sqrtP = 295147905179352825856, and currentTick = -388182.-388582 to -388180 through AntiSnipAttackPositionManager::mint, then burns part of it with removeLiquidity until active liquidity becomes 5109053135792022.deltaQty0 = 27736096068180377599999 and deltaQty1 = -377259, pushing currentTick to -388583 while the pool still reports active liquidity.40410314811613531939916 FRAX against only 546747 USDC paid in, and the reported active liquidity jumps to 10218106271584044.The decoded helper logs summarize the pattern succinctly:
STARTING Pool...
Step 1 Complete.
Step 2, finding liquidity required
Step 3, building up fake liquidity.
Step 4, pulling off the doubling move.
DONEEEEE...
The same helper contract repeats this strategy across the other Kyber Elastic pools in the same transaction. The payout address then receives the extracted assets. The balance diff shows transfers to 0xc9b826bad20872eb29f9b1d8af4befe8460b50c6 of:
6255995712288710961401 FRAX4806811056 USDC11907522555278990764 frxETH17181396346774484787 MONA261977312989387423555651 MEMEThe sender EOA paid 615095561124017350 wei in gas for the transaction.
The transaction drained public reserves from five Kyber Elastic pools and left the FRAX/USDC pool in a corrupted post-state with doubled active liquidity after the reverse swap. The measurable pool-side losses recorded in the analysis are:
11908702998026754674 base units (18 decimals)17182235077189764520 base units (18 decimals)261977528777761427077256 base units (18 decimals)6781075430101436721311 base units (18 decimals)4806886457 base units (6 decimals)The lower-bound profit predicate is deterministic even before valuing the volatile assets. Using only stablecoins transferred to the payout address, the attacker realized:
6255.995712288710961401 USD-equivalent at a 1 USD lower-bound assumption4806.811056 USD11062.806768288710961401 USDThe transaction fee side is also deterministic. The transaction used 13298675 gas at 46252394402 wei, for 615095561124017350 wei total. Using the public Chainlink ETH/USD feed 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419 at block 18630392, with latestRoundData answer 206577870000 and 8 feed decimals, the gas cost was 1270.651308634543100060445 USD. That gives a stablecoin-only lower-bound net gain of 9792.15546 USD, excluding the additional frxETH, MONA, and MEME value also transferred to the payout address.
0x485e08dc2b6a4b3aeadcb89c3d18a37666dc7d9424961a2091d6b3696792f0f3SwapMath.sol for the rounding bugPool.sol for the skipped tick-cross branchAntiSnipAttackPositionManager.sol for the public mint and rebalance path18630392https://blog.kyberswap.com/post-mortem-kyberswap-elastic-exploit/