Fee Growth

Fee growth is Uniswap V3's answer to a problem that has no cheap iterative solution: how does a pool credit fees to thousands of positions, each covering a different price range, without ever looping over them?

The pool maintains two global counters, feeGrowthGlobal0X128 and feeGrowthGlobal1X128, one per token. Each holds the total fees collected so far divided by the liquidity that was active when they were collected, in Q128.128 fixed point. A position's earnings are then the change in that counter across the time the position was held, multiplied by the position's own liquidity.

Why the division happens first

Dividing by active liquidity at collection time is what makes the counter universal. Two providers holding different amounts of liquidity over the same interval read the same delta and multiply by their own size. The counter never needs to know who is in the pool.

The counter only ever increases, and it is allowed to overflow. The unchecked arithmetic around it is not a gas optimization. Because every read is a subtraction of two snapshots, an overflow between them cancels out in two's complement, and the difference stays correct. Adding overflow checks would revert on a computation that is mathematically sound.

The part that makes ranges work

A global counter alone would credit every position for every fee, including fees earned while the price was outside that position's range. Uniswap V3 fixes this with a per-tick value called feeGrowthOutside, stored on both boundary ticks of every initialized range.

feeGrowthOutside records the fee growth that accumulated on the far side of that tick. By subtracting the outside values of the lower and upper ticks from the global total, the pool derives feeGrowthInside — the growth that happened strictly within the range — with three storage reads and no iteration, regardless of how long the position has existed or how many times the price crossed it.

The trick that makes this work is that feeGrowthOutside is not maintained continuously. It is initialized on the assumption that all prior growth happened below the tick, and then flipped, by subtracting it from the current global, every time the price crosses. The value is only meaningful relative to the current price, which is exactly the context in which it is ever read.

Settlement is lazy

Nothing is credited when a fee is earned. A position's feeGrowthInside snapshot is only compared against the current one when the position is touched — minted, burned, or poked with a zero-liquidity burn. Fees owed are computed at that moment and moved into a tokensOwed field, from which the owner collects separately.

This is why fees in V3 do not compound. In V2, fees stayed in the reserves and grew the value of every LP share automatically. In V3 they sit in tokensOwed earning nothing until claimed, and a provider who wants compounding has to withdraw and re-mint.

Where it goes wrong

Fee growth is a common source of bugs in forks. The three failure modes worth checking are: computing feeGrowthInside with the checked arithmetic that a compiler upgrade silently introduced, which reverts once the counter wraps; failing to flip feeGrowthOutside on a tick cross, which quietly misattributes fees between ranges; and initializing feeGrowthOutside for a new tick without the current-price convention, which credits a fresh position for fees earned before it existed.