Uniswap liquidity pools turn reserve balances into executable swap prices

Uniswap liquidity pools enable swaps by holding two assets and applying a pricing function to their changing balances. When a trader adds one asset and removes the other, the contract computes an output, charges the pool's configured fee, and commits both balance changes together. The resulting balances and pool state become the starting point for the next swap.

Updated · Wednesday 16 September 2026

That mechanism varies across protocol versions. Uniswap v2 exposes a full-range constant-product pool, while v3 and v4 divide concentrated liquidity across price ranges. Estimating a swap therefore requires the pool state, active liquidity, fee configuration, and caller limits.

Follow reserve state from quote to settlement

A pool calculation starts with a state snapshot and finishes when the transaction either commits a new state or leaves the prior state intact.

Readiness starts with the pool state

A quote reads the current price, reserve relationship, applicable fee, and available liquidity. In a concentrated-liquidity pool, it must also account for initialized ticks along the proposed price path. The quote does not reserve those conditions. Another swap can update the same state before the submitted transaction executes.

Execution recomputes the output

The contract uses the state available during execution, not a previously displayed figure. It applies the input amount, subtracts the portion used for the swap fee, and moves the price along the pool's curve. A concentrated-liquidity swap may activate or deactivate liquidity as it reaches position boundaries. Caller-supplied price or output limits determine whether the calculated result remains acceptable.

Settlement provides the observable result

A successful transaction records the asset deltas, fee accounting, and updated pool state together. If a required payment, price limit, or minimum output condition fails, the transaction reverts its pool changes. The transaction receipt and resulting balances provide stronger completion evidence than an interface estimate.

How does the constant-product curve set the output?

In Uniswap v2, the post-swap reserve product x × y must be at least as large as it was before the swap. A trader adds to one reserve and receives assets from the other. The curve selects an output preserving the invariant after accounting for the swap fee.

View full-size image

Without a fee, adding effective input Δx produces a new output-side reserve of k divided by (x + Δx). The trader receives the difference between the old and new output reserve. Each additional output unit becomes costlier because removing it pushes the reserve ratio further from its starting point.

Reserve depth controls price movement

Price impact depends on trade size relative to usable liquidity near the current price. A small input against deep liquidity changes the reserve relationship modestly. The same input against shallow liquidity moves further along the curve and receives a worse average rate. Total pool value alone can mislead because concentrated positions outside the current range do not support the swap.

Concentrated liquidity narrows the usable reserve range

Uniswap v3 and v4 let providers allocate liquidity within selected price intervals. The pool combines all positions covering the current price into its active liquidity.

Ranges supply local depth

A narrower in-range position can supply more depth around its chosen prices than the same capital spread across the full curve. The position also has boundaries. Once the price leaves them, its liquidity becomes inactive and stops earning swap fees. Its principal then consists of one pool asset, while previously accrued fees can include either asset.

Ticks change the active set

Ticks divide price space into discrete intervals and mark position boundaries. Within one interval, the swap follows the curve using the current active liquidity. Reaching an initialized tick changes the active amount by adding positions beginning there or removing positions ending there. The pool then continues with the revised depth.

What changes when a swap crosses a tick?

Crossing an initialized tick adds or removes the liquidity attached to positions whose boundary lies there. The price continues in the same direction, but the relationship between further input and price movement can become steeper or flatter. A large reduction in active liquidity makes the remaining portion of the swap move the price faster.

Tick crossing also adds computation because the contract updates tick and fee-growth records. An uninitialized tick does not change active liquidity. If active liquidity falls to zero, the core swap can advance the price through an empty interval to the next initialized tick without exchanging assets there. It cannot move past the caller's price limit.

Fees alter reserve and position accounting

Every swap applies the fee configured for its pool. In v2, the fixed 0.30% swap fee reduces the input used to calculate output, while the full input enters the reserves. This structure increases the reserve product. When the protocol fee is enabled, the pair later mints liquidity tokens to the fee recipient, so existing providers retain only the remaining fee value.

V3 and v4 track the liquidity-provider portion of swap fees as claimable amounts associated with positions rather than automatically adding it to position principal. Only liquidity active while the swap passes through a price interval earns the liquidity-provider portion. V4 can also use dynamic fee logic through a pool's hook, so a stored or displayed fee must match the pool configuration used for execution.

Can a pool run out of usable liquidity?

A pool can lose usable liquidity for a requested trade even while assets or inactive positions remain associated with it. In a v2-style full-range pool, the curve makes each remaining output unit increasingly expensive as its reserve approaches zero. Ordinary swaps therefore encounter extreme price movement before mathematically draining that reserve.

Concentrated-liquidity pools have a different boundary. A core swap can cross an empty interval to reach a later active range, but it cannot cross the caller's price limit. If it reaches that limit before producing enough output, surrounding router conditions can reject the result. Positions beyond the limit do not support that execution.

Pool versions store liquidity in different ways

The same reserve idea appears through different contract structures. Version, fee configuration, and active range determine which state controls the swap.

Uniswap v2 uses separate pair contracts

Each v2 pair contract holds two token reserves and applies the full-range constant-product relationship. Fungible liquidity tokens represent proportional claims on the pool. A reserve reading therefore describes the assets supporting the curve across its entire mathematical price range, although execution quality still changes sharply near either extreme.

Uniswap v3 combines range positions

Each v3 pool stores a current price, active liquidity, ticks, and fee-growth data. Individual positions contribute only inside their selected ranges. Raw token balances do not reveal how much liquidity supports the next price interval, so an accurate output calculation follows initialized ticks and their net liquidity changes.

Uniswap v4 centralizes pool accounting

V4 stores distinct pool states inside the PoolManager rather than deploying one contract for every pool. A pool's currencies, fee setting, tick spacing, and hook identify its behavior. Flash accounting tracks interim balance deltas and requires settlement before the operation finishes. A reserve total without the pool version, current price, fee, hook, and active liquidity cannot provide a complete execution forecast.

Uniswap liquidity pools: what people ask