Liquidity Net

Liquidity net is the field that lets a Uniswap V3 pool keep a single running total of active liquidity instead of recomputing which positions are in range on every swap.

Each initialized tick stores an int128 liquidityNet. When a position is minted over the range [lower, upper], the pool adds that position's liquidity to liquidityNet at the lower tick and subtracts it at the upper tick. Burning does the reverse. The tick therefore never records who is on either side of it, only the net effect of stepping across it.

How the swap loop uses it

The pool keeps one uint128 liquidity variable holding the active liquidity at the current price. During a swap, whenever the price crosses an initialized tick, the loop reads that tick's liquidityNet and applies it: added when moving up, subtracted when moving down.

That sign flip is the whole mechanism, and it is why the same field serves both directions. Crossing a range's lower tick upward brings the position into range and its liquidity into the total. Crossing that same tick downward takes it back out. The pool never asks which positions exist; it only applies the deltas it meets.

The cost of a swap is therefore proportional to the number of initialized ticks crossed, not to the number of positions in the pool. A pool with a million positions and a price that moves within one tick spacing does the same work as a pool with one.

The overflow that has to be prevented

Because liquidityNet accumulates the liquidity of every position using that tick as a boundary, and the pool's liquidity variable is a uint128, an attacker who could pile enough liquidity onto one tick could overflow the active total on a cross. Uniswap V3 closes this by deriving a per-tick maximum from the tick spacing — roughly type(uint128).max divided by the number of usable ticks — and rejecting any mint that would push a tick past it.

Forks that change tick spacing without recomputing that maximum reopen the hole. It is one of the first things worth checking in a V3 fork diff.

Reading it during a review

Two invariants are worth holding in mind. First, the sum of every initialized tick's liquidityNet across the whole pool must be zero, because every position contributes an equal and opposite pair. A pool where it is not zero has lost or duplicated a position. Second, liquidityNet is signed while the pool's running liquidity is unsigned, so the addition is done through a helper that reverts on underflow. Replacing that helper with plain arithmetic in an unchecked block turns an impossible state into a silently wrapped one.