Thread by @0xdoug

1/ Finished a preliminary deep dive into the Kyber exploit, and think I now have a pretty good understanding of what happened.

This is easily the most complex and carefully engineered smart contract exploit I've ever seen...

2/ First thing to note is this exploit is specific to Kyber's implementation of concentrated liquidity

There's no reason to believe that other reputable concentrated liquidity dexes, like Ambient or Uniswap, are at risk from this exploit. (Though Kyber forks obviously are)

3/ We'll look at the first pool the attacker drained on Ethereum, ETH/wstETH. Though all of the other pools followed a similar strategy.

The attack on this pool can be found in this transaction:

etherscan.io/tx/0x09a3a12d5…

4/ This particular transaction drained three separate pools, but for now we'll only look at the ETH/wstETH drain.

The process to drain each pool is independent, so we only need to understand one. Each pool exploit is carried out in a flash loan to manipulate price and liquidity

5/ In the wstETH/ETH case, the exploit started with a flash loan of 10 thousand wstETH (worth $23 million)

The next step was to swap 2800 wstETH ($6mn) into the pool to push the price from 1.05 ETH to 0.0000152. Unlike most flash loans, the reason wasn't to manipulate an oracle

6/ The point was to move the pool price to an area of the concentrated liquidity curve, where there was 0 existing liquidity. Since the attack relied on an extremely precise manipulation of Kyber's concentrated liquidity math, this basically created a "fresh canvas".

7/ The exploit mints 3.4 wstETH of liquidity in the price range of 0.0000146 to 0.0000153. Then the exploiter burns 0.56 wstETH of liquidity for some reason (probably to make the subsequent numerical calculations line up perfectly).

8/ The exploit executes two swaps around this price. Now remember there is no other liquidity here. In the absence of a numerical bug, someone doing this would just be trading back and forth with their own liquidity, and all the flows would net out to zero (minus fees)

9/ However what happens is an infinite money glitch.

The first swap is the exploiter selling 1056 wstETH for 0.0157 ETH pushing the price down to 0.0000146 (just barely below his liquidity's price range).

10/ The second swap is in the opposite direction. The exploiter buys 3911 wstETH from the pool for 0.06 ETH pushing the price of the pool back up to 0.00001637 (a bit above the upper edge of his liquidity range.

11/ And that's it. The exploit is complete. The pool is drained

Notice how in the second swap he received more money than he paid in the first (3911 vs. 1052 wstETH). Remember the only liquidity here is the ~3 wstETH he minted at the outset. Where did the extra money come from?

12/ This is where things get really tricky. It took me hours to even figure out what happened.

The first clue came from looking at the resting state of the pool's liquidity at the end of the second swap. Notice anything weird?

13/ In Kyber the value of the resting in-range liquidity is in the `baseL` poolData variable.

Shouldn't this be 0? Remember the second swap ended at a price *outside* the attacker's liquidity range. There should be no liquidity here.

14/ Somehow the exploit was able to make the pool think it had more liquidity than it actually did at these price ranges. And now we understand where the infinite money glitch comes from

If the pool thinks there's more liquidity than there actually is, it overpay for large swaps

15/ The second clue comes from comparing the call trace stack for the first and second swap.

In Kyber when tick boundaries are crossed, the `updateLiquidityAndCrossTick` is invoked. It adjusts the curve's liquidity value based on the LP range positions at that tick

16/ The second swap handles it correctly. It starts by being out of range above the LP position. updateLiquidityAndCrossTick is called once when the price moves in range. Then the swap ends at a price below the LP position. So it's called again as the price moves out of range

17/ However in the first swap updateLiquidityAndCrossTick is *never* called. Remember the curve price started in range, then the swap moved the price until it was just slightly out of range (carefully note "slightly")

It should have been called, but never was on swap 1

18/ And now the pieces are falling into place.

When an LP position moves out of range updateLiquidityAndCrossTick is responsible for removing that liquidity from the curve. When it moves back in range, it adds the liquidity back into the curve.

What would happen if it broke?

19/ If you could get it not to invoke when your LP position moved out of range, liquidity would never be removed from the curve. You've now tricked the pool into thinking it has more liquidity then it does.

20/ But when you move back in range, you make sure it invokes. And the liquidity gets added back in, even though it was never removed the first time. You're double dipping! The pool is double counting the liquidity from the original LP position.

The infinite money glitch

21/ How was the exploiter able to bypass the call to updateLiquidity on swap 1? This is where things get really technical

In concentrated liq AMMs, swaps are calculated as a series of steps. At each step you have to determine if you'll reach a tick boundary or exhaust the swap

22/ Kyber runs this swap step, and it checks to see if the ending price of the step is the same as the next tick price. If it is isn't it assumes the swap exhausted, it didn't reach the tick boundary and `updateLiq` doesn't need to be called.

23/ However note the check is inequality, not directional comparison. If you were somehow able to execute a swap step and get the price to end *outside* the tick boundary, the check would fail and `updateLiquidity` would never be called, even though you crossed a tick boundary

24/ Normally this shouldn't happen because `computeSwapStep` function first calculates an upper limit of the amount that can be swapped before reaching the tick

If that amount is less than remainder of the swap, it confidently predicts the ending price will *not* reach the tick

25/ However in this case something funny happened. calcReachAmount predicted the swap quantity would not reach the tick boundary, yet somehow the ending price ended just slightly *beyond* the tick boundary.

26/ And that's because the "reach quantity" was the upper bound for reaching the tick boundary was calculated as ...22080000, whereas the exploiter set a swap quantity of ...220799999

That shows just how carefully engineered this exploit was. The check failed by <0.00000000001%

27/ This has to do with how Kyber implements the quantity calculation (for the upper limit until a bounds is hit) and the price change. The two use very slightly different arithmetic.

28/ In a very carefully controlled and precisely engineered case, the bounds check will tell you that anything less than X swap qty will keep you inside the tick price.

But the parallel calculation price change calculation will apply X swap qty and wind up outside the tick bound

29/ I remember being endlessly paranoid about this when writing the smart contracts for @ambient_finance

For that reason, our code includes explicit checks on every step that were explicitly inside the tick boundary if the swap quantity exhausts.

@ambient_finance 30/ The good news at least, it would be pretty straightforward to patch the existing Kyber contracts with a similar assertion on the swap step to prevent this exploit in the future.