Uniswap
Uniswap liquidity changes pool state when v2 deposits mint LP tokens and v3 or v4 deposits create or increase ranged positions
Uniswap liquidity enters a two-asset pool through a transaction that transfers the required asset amounts and records the provider's claim. In v2, the deposit increases pooled reserves and mints fungible LP tokens. In v3 and v4, the transaction adds liquidity between chosen tick boundaries and creates or increases a position tied to that range. The pool's current price determines the required token mix, while the selected range determines when the position supplies active liquidity and earns swap fees.
A deposit changes the pool and the provider record
Every successful deposit updates two related layers of state. The pool records more assets or liquidity available for swaps. A separate ownership record tracks the provider's claim. Those layers aren't interchangeable: pooled balances describe the shared market, while an LP token balance or position token identifies one provider's share under that version's rules.
In v2, minting raises the pair's reserves and total LP token supply. In v3 and v4, a mint or increase adds a liquidity amount between lower and upper ticks. An in-range addition also raises the liquidity currently available to swaps. An out-of-range addition updates the position and its boundary ticks, but it doesn't raise active liquidity at the current price.
Position designs produce different state records
The selected protocol version and range determine how the same basic deposit is represented. Full-range liquidity remains available across the supported price interval. Concentrated liquidity assigns capital to a narrower interval and becomes inactive beyond either boundary.
| Position choice | How the deposit is recorded | Binding range condition |
|---|---|---|
| Uniswap v2 full range | The pair mints fungible ERC-20 LP tokens representing a proportional reserve claim. | Providers can't choose a finite price interval; liquidity spans the full curve. |
| Uniswap v3 full range | A non-fungible position records liquidity between the extreme usable ticks. | The endpoints must be valid for the pool's tick spacing. |
| Uniswap v3 concentrated range | A non-fungible position stores liquidity with selected lower and upper ticks. | Liquidity is inactive when the price lies outside those boundaries. |
| Uniswap v4 concentrated range | A position token identifies liquidity for a specific pool and tick interval. | Ticks must match the pool spacing, and configured hooks may affect liquidity actions. |
V3 and v4 also permit full-range positions, so concentrated liquidity isn't compulsory. The meaningful comparison is the state the position creates. A wider range stays active through more price movement, while a narrower range concentrates capital within a smaller interval. Neither choice fixes the assets a provider will eventually withdraw.
How does the current price set the deposit mix?
The current pool price and the chosen boundaries determine whether a concentrated position needs both tokens or only one. When the price lies inside the range, the deposit uses both assets. As the price approaches a boundary, the required mix leans toward one asset. A range entirely above or below the current price can begin with a single token, although its liquidity starts inactive.
The direction of that single-sided deposit depends on token ordering and which side of the range contains the current price. Typed display prices can also be inverted without changing the underlying position. Deposit builders therefore calculate amounts from the pool's live square-root price, current tick, tick spacing, and selected bounds. Maximum input amounts or minimum-use protections limit what a transaction may consume if state moves before inclusion.
Tick boundaries control active liquidity
Concentrated positions divide the price curve into intervals. The pool maintains active liquidity for the interval containing its current price, then adjusts that total as swaps cross initialized boundaries.
State inside the selected range
Pool-level liquidity
Each v3 or v4 range is bounded by initializable ticks. A deposit whose range contains the current tick contributes immediately to the pool's active liquidity. Other positions may share either boundary, so tick state aggregates changes from many providers.
Position-level accounting
The position stores a liquidity quantity rather than two fixed token balances. Its withdrawable token amounts derive from that quantity, the range, and the pool price at the time of calculation. Fee-growth checkpoints also let the position account for its share of fees earned while active without assigning particular pooled coins to one provider.
Position inventory outside its range
When price moves beyond a concentrated range, the position becomes inactive and ends up composed entirely of one token. Its boundaries don't move with the market. If price later re-enters the interval, the same liquidity becomes active again. Changing the interval instead requires removing liquidity and creating a position with different ticks.
An empty pool separates starting price from usable depth
Creating or initializing a pool doesn't necessarily supply assets for trading. In v2, the first liquidity deposit establishes the initial reserve ratio. V3 and v4 pools use an initialized starting price, then require liquidity positions before swaps have usable depth. V4 can initialize a pool separately or combine initialization and the first mint in one transaction.
The starting price affects the token amounts required by the first position. If it differs from prices available elsewhere, arbitrage can move the pool toward those markets and alter the provider's inventory. Thin initial liquidity also allows a given swap to move price farther than it would in a deeper pool. Initialization is therefore a state-setting action, not proof of an external market value.
What changes when liquidity is added to an existing position?
An increase raises the position's liquidity without changing its existing range. The required token amounts are recalculated from current pool state, so they may differ from the original deposit mix. V3 and v4 range boundaries can't be edited through an increase. A different interval requires a new position, while the existing position may remain open. In v2, another proportional deposit raises reserves and mints additional fungible LP tokens.
Swaps reshape inventory without rewriting the position
A v2 swap adds one reserve asset and removes the other. The constant-product relationship, commonly written as
x * y = k, links those reserve changes to the pool price. Swap fees retained in the pool can increase the invariant. The provider's LP token count doesn't change merely because other accounts trade against the reserves.
V3 and v4 apply similar curve logic within the active price interval. As a swap moves price, it changes the token composition represented by each active position. Crossing a tick removes some ranges from active liquidity and introduces others. The position's owner, pool identity, and tick boundaries remain unchanged until a separate liquidity-management transaction modifies them.
Fee accounting follows active liquidity
In v3 and v4, a position accrues swap fees only while the pool price sits inside its selected range. Its share depends on the liquidity it contributes relative to other active liquidity. Accrued fees remain separate from the position's liquidity quantity and don't automatically expand its range or reinvest themselves as additional concentrated liquidity.
V2 handles fees differently. Swap fees remain in the pair reserves, so the proportional reserve claim represented by LP tokens reflects them when liquidity is removed. V3 and v4 positions can collect owed fees without withdrawing principal liquidity. A protocol fee or v4 hook configuration may affect fee handling, which makes the exact pool configuration part of the position's economic state.
Ownership records aren't fixed token balances
An LP record proves a claim under the pool's accounting rules; it doesn't reserve two static piles of tokens. V2 uses interchangeable LP tokens for proportional ownership. Standard v3 and v4 position-management flows use position token IDs because ranges and fee records can differ between providers. The amounts available on withdrawal still depend on current pool state, the position's liquidity, its boundaries, and fees owed.
Position checks distinguish successful, pending, and reverted liquidity changes
Checking a position increase against recorded state
Before commitment, read the exact network, token contracts, protocol version, pool identifier, current price, and position range. Use that state to set the proposed input limits and slippage protection. A mismatched pool or range is a reason to stop before signing.
The commitment point arrives when the wallet submits the liquidity transaction. A prior token approval only authorizes spending and doesn't alter the pool. Once broadcast, a transaction hash shows submission, but it doesn't prove the position increased.
The expected state after execution includes a successful receipt, higher position liquidity, and wallet balance changes consistent with the assets used. Active pool liquidity rises only if the position range contains the price when execution occurs.
The observed state may instead show a successful increase while active liquidity remains unchanged. Price may have moved outside the range before inclusion. The deposit is valid but inactive, leaving a choice between waiting for price to re-enter or removing liquidity and creating a different range.
A reverted transaction doesn't mint or increase the position, although it can still consume network gas. If no final receipt exists, wait and reconcile the transaction status before submitting a replacement. Stop when the recorded pool or bounds are wrong, then rebuild the action from fresh state.
Removing liquidity settles the current claim
Removing liquidity reverses part or all of the provider's claim at current pool state. It doesn't restore the original deposit quantities or undo intervening swaps. V2 burns LP tokens and returns the corresponding share of both reserves, including fees embedded in those reserves. V3 and v4 decreases calculate token amounts from the current price, range, and liquidity removed.
A partial decrease leaves a smaller position. Closing a concentrated position also requires handling any fees still owed before its record can be discarded under the relevant manager's flow. Reconciliation should compare the receipt, returned token balances, collected fees, and remaining position state. For v3 or v4, check the liquidity still recorded under the position token ID when reconciling principal.
Uniswap liquidity FAQ
Does a token pair uniquely identify a Uniswap v3 or v4 pool?
No. A token pair may have multiple pools distinguished by protocol version and fee configuration. Tick spacing also belongs to the pool configuration, while a v4 pool identity includes its hook address. Matching token symbols alone isn't enough because unrelated tokens can share a symbol. Compare contract addresses and the complete pool identity before adding liquidity.
Can a v4 hook change how a liquidity deposit behaves?
Yes. V4 hooks can run before or after liquidity is added or removed, and hook code may apply custom accounting or other pool-specific behavior. The hook address is part of the pool's identity, so two pools for the same currencies can behave differently. A deposit should be evaluated against the exact hook configuration attached to its selected pool.
Does transferring a position token also transfer its liquidity claim?
For standard v3 and v4 position-management flows, ownership of the position token controls the associated liquidity position and fee claim. Transferring that token changes who owns the position record without first withdrawing the pool assets. Existing operator approvals can affect who may manage the token, so ownership and authorization records both matter.
Could a full-range v3 position replace a v2 position exactly?
No. Both can keep liquidity active across the available price curve, but their records and fee accounting differ. V2 issues fungible LP tokens and keeps swap fees in pool reserves. V3 uses a non-fungible position with tick boundaries and separately claimable fees. Those differences affect management, transfer, and withdrawal even when the price coverage looks similar.
Are tick boundaries guaranteed to match a typed price exactly?
No. A v3 or v4 boundary must land on a tick permitted by the pool's tick spacing, so an interface or transaction builder may adjust a typed price to a usable tick. The displayed price also depends on which token is the quote asset. Review the resulting tick bounds and adjusted prices before signing.