HyperByte

Uniswap-V3 after V2

2026-09-24

Suppose the real-time price of the ETH/DAI trading pair is 1500 DAI/ETH.

Initial state: The pool holds 4,500 DAI and 3 ETH, with a price of 1,500 DAI/ETH.

After a price drop: ETH falls to 1,300 DAI/ETH, and arbitrageurs will buy ETH from the pool until the pool price also reaches 1,300.

Final state: The pool ends up with 4,192.54 DAI and 3.22 ETH.

  • The DAI balance in the pool decreased by 6.84%.

  • The ETH balance in the pool increased — from 3 to 3.22.

If you’re an LP and you put your money in, then when ETH’s price drops, the pool will automatically “sell” some DAI to buy ETH. This process changes the composition of the assets you hold, and it usually results in impermanent loss.

[ Uniswap-V3 ]

Uniswap V3 introduced concentrated liquidity, letting LPs choose their own price range. This gives them more control over their impermanent loss exposure — a narrower range means less IL risk, but requires more rebalancing.

Scenerio:

1. Create the pool (anyone can do this)

2. LP A adds liquidity

3. LP B adds liquidity

4. LP C adds liquidity

Price axis:
►
1000 1500 2000 2500 3000
│ │ │
LP A:
[ 1500~2500 ]
LP B:
[ 1800~2200 ]
LP C:
[ 1500~3000 ]

LP A,B,C, they only earn fees within their own range.

Price range Live LP total liquidity
1000~1500 LP A 100
1500~1800 LP A + LP B 300
1800~2000 LP A + LP B + LP C 600
2000~2200 LP B + LP C 500
2200~2500 LP B 200

Tick

​

  • tick = 0 → price = 1
  • tick = 1 → price = 1.0001
  • tick = 100 → price = 1.0001^100 ≈ 1.01005
  • tick = -100 → price = 1.0001^-100 ≈ 0.99005

But, Why 0.0001 ?

​ A 0.01% price change — that’s precise enough.

example:

  • LP wants to provide liquidity in the range [1500, 2500]
  • Convert to ticks:
    tickLower = tick(1500) ≈ -23028
    tickUpper = tick(2500) ≈ 19570
价格轴(从低到高):
►
tick A
│
▼
100 USDC
tick B
│
▼
500 USDC
tick C
│
▼
200 USDC
tick D
│
▼
800 USDC
Question:
Why does each tick need to record liquidity separately?
Because price is discretized into ticks, and liquidity only changes at tick boundaries — so tracking liquidity per tick lets the pool know exactly how much active liquidity exists at any given price.

Scenario of a real trade within V3:

  1. The current price is between tick 1800 and 2000
    → Active liquidity = 600
  2. Someone buys ETH, and the price moves from 1900 to 2100
    → The price crosses tick 2000 (where LP A’s range ends)
    → Active liquidity = 600 - 100 = 500
    → Continue calculating with 500
  3. The price keeps rising to 2300
    → It crosses tick 2200 (where LP C’s range ends)
    → Active liquidity = 500 - 300 = 200

key takeaway: each tick records the change in liquidity.

← Back to Home