Uniswap
Uniswap liquidity pools turn compatible assets into positions whose token mixes change with swaps
Uniswap liquidity pools let a provider supply token inventory to a smart contract and earn a share of applicable swap fees. The position does not preserve the original token amounts. Swaps change the pool balance, while the selected protocol version, fee setting and price range determine when that inventory participates and what the provider can later withdraw.
A sensible first position starts with compatibility and a bounded commitment. Review the token contracts, network, pool version and range before granting access to either token.
Choose the Position Before Approving Tokens
The first session should move from reversible choices to an onchain commitment. Select the pair, inspect the existing pool and define the position before approving spending. Nothing enters the pool while the draft remains unsigned, so that point provides a clean place to stop if the inputs or expected token mix look wrong.
Network and Token Match
Network compatibility comes first because tokens on different networks do not share one pool. Confirm that the wallet uses the intended network, that both contract addresses identify the intended assets and that the wallet holds the network’s transaction token. A familiar symbol alone cannot establish token identity.
Version, Fee Setting and Range
The version determines which choices exist. Uniswap v2 uses full-range liquidity, while v3 and v4 permit custom or full-range positions. In v3, the token pair and fee tier identify a pool. In v4, tick spacing and an optional hook address also distinguish pools for the same pair and fee setting. A hook can change pool behavior, so its configuration belongs in the compatibility check.
Wallet Review and Stop Boundary
The wallet review separates preparation from commitment. Read each approval and transaction request, including the network and contract involved. Rejecting a request leaves the proposed position uncreated. After approval, creation still requires a separate confirmed transaction, so an allowance does not itself prove that liquidity entered the pool.
Compare the Changing Token Mix With Holding
A liquidity position tracks a share of pool inventory rather than two fixed token balances. Traders add one token and remove the other, while arbitrage activity tends to move the pool price toward prices available elsewhere. The provider’s claim therefore shifts toward one asset as the relative price changes. Withdrawal returns the position’s resulting mix, not the quantities originally deposited.
This change creates the comparison commonly called impermanent loss: the position can be worth less than simply holding the starting tokens outside the pool. The word “impermanent” does not promise that the difference will reverse. Fee income may offset some or all of it, but that outcome depends on trading activity, active liquidity and the eventual price path.
Match the Range to Inventory Exposure
The range controls where concentrated liquidity participates. A narrow range places more of the position near selected prices, while a wider range covers more possible price movement. That trade-off affects fee eligibility, inventory conversion and how often the position may need attention.
Inventory While the Price Is in Range
An in-range v3 or v4 position normally holds both pool tokens. Each swap changes their proportions according to the pool state and the position’s boundaries. Active liquidity can earn its proportional share of applicable pool fees, but a larger share of active liquidity does not remove exposure to adverse token-price movement.
Inventory Beyond a Boundary
In Uniswap v3 and v4, a concentrated position outside its chosen range becomes single-sided and stops earning liquidity-provider fees until the pool price returns to that range. The position still exists, and its ownership record remains in the wallet. Price movement through the range, rather than a manual exchange, produced the one-token state.
Full-Range Coverage
Full-range liquidity remains active across the protocol’s supported price span. It requires less range management than a narrow concentrated position, although its capital is spread across more prices. Uniswap v2 provides only this form. V3 and v4 let the provider choose full-range coverage instead of setting custom boundaries.
Compare the Version Boundaries
Protocol versions place different boundaries around the same basic task. Each version differs in how it represents ownership, allocates liquidity across prices and permits custom pool behavior.
| Version | Range and Contract Boundary |
|---|---|
| Uniswap v2 | Full-range liquidity with a fungible UNI-V2 token representing the pool share. |
| Uniswap v3 | Custom or full-range liquidity with an NFT recording position-specific boundaries and fee settings. |
| Uniswap v4 | Custom or full-range liquidity with an NFT; optional hooks may alter defined parts of pool behavior. |
A simpler range model does not eliminate token or smart-contract risk. Conversely, added customization is useful only when its behavior matches the intended position. A v4 pool with a hook deserves inspection as its own configuration rather than being treated as interchangeable with every other pool for the same pair.
Read Fee Earnings Beside Inventory Changes
Fee income comes from swaps that use the pool and the position’s active liquidity. Earnings therefore depend on volume, the applicable fee setting, competition from other active liquidity and time spent in range. A displayed annualized rate can change quickly and cannot show whether the position outperformed holding the tokens after network costs and token-price movement.
Fee handling also differs by version. In v2, swap fees remain in pool reserves and affect the value represented by the liquidity tokens. V3 and v4 track position fees separately, allowing collection without removing the underlying liquidity. Collection itself requires an onchain transaction and its associated network cost.
Use Ticks to Interpret Price Boundaries
A tick is a discrete price boundary used by concentrated-liquidity pools. Custom minimum and maximum prices must align with valid ticks, and the permitted spacing relates to the pool configuration. An interface may round a typed price to the nearest usable boundary, so the review screen can differ slightly from the entered decimal.
Ticks also explain why a range changes state at a precise boundary. Liquidity becomes active as the pool price crosses into its interval and inactive after crossing out. The price display may reverse the quoted token order, so both the token order and the numerical range need review before the position is created.
Protect the Record That Controls the Position
Uniswap v2 positions are represented by UNI-V2 tokens, while v3 and v4 positions are represented by NFTs that record position-specific data. The wallet holding that token or NFT controls the associated liquidity rights. Sending the ownership record to another address transfers control rather than merely sending a decorative receipt.
The ownership record supports later actions such as adding or removing liquidity and collecting eligible fees. Wallet security therefore protects more than the tokens currently visible as ordinary balances. An address that gains control of the position token can act on the underlying position within the rules of its version.
Separate Approval Costs From Position Creation
Token approval authorizes a contract to transfer a token within the granted allowance. Creation is a later action that actually supplies liquidity. A first position may consequently require more than one wallet interaction and more than one network charge. Existing allowances can change that sequence, while a signed message may not carry a network cost even when the final transaction does.
Keep enough of the network’s transaction token outside the proposed deposit to cover creation and a future exit. Network cost changes with demand and transaction complexity, so a profitable-looking fee estimate can still be uneconomic for a small position. Approving an unlimited amount also creates a broader allowance than the immediate deposit requires.
Check Transaction Status Before Retrying a Failed Creation
A failed or rejected creation should lead back to the last verified state. First determine whether any transaction reached the network. A wallet rejection leaves no submitted creation, while a reverted transaction can still consume a network charge. A pending or confirmed transaction needs its own record checked before another submission.
Correct one mismatch at a time: the connected network, token allowance, available balance or reviewed range. Then rebuild the same bounded action and inspect its wallet request again. Repeated submissions without checking transaction status can create duplicate pending requests or spend additional network costs without fixing the underlying incompatibility.
Monitor Price, Inventory and Active Liquidity Together
The pool price shows where the position sits relative to its range, token balances show how inventory has shifted and fee data shows what active trading produced. Looking at fees alone can hide a growing difference from holding, while looking only at token amounts can miss fees that remain uncollected.
Range management has its own cost. A provider who wants different boundaries must remove liquidity and establish a new position rather than editing the existing range in place. More frequent repositioning may keep liquidity near the market, but each adjustment introduces transaction costs and another opportunity to approve an unintended input.
Reconcile the Exit Against the Starting Mix
Liquidity removal converts the position’s pool claim into wallet balances at the pool’s state when the transaction executes. Partial removal leaves the remaining share exposed. Full removal ends that exposure, while any uncollected fees must also be accounted for under the version’s fee mechanics. The received proportions may differ substantially from the deposit.
A complete reconciliation compares the withdrawn tokens and collected fees with the original inventory, subsequent additions and total network costs. It should also use the same valuation point for the pooled and hold-only cases. The appropriate stopping point changes if removal costs outweigh the value being recovered or a token’s transfer behavior prevents normal settlement.
Quick answers about Uniswap liquidity pools
Does an in-range Uniswap v3 or v4 Position Require Both Tokens?
Yes, an in-range v3 or v4 position generally requires both pool tokens because the current price lies between its selected boundaries. The required proportions follow the current pool price and range rather than a fixed 50/50 token count. A position outside the current price can instead be supplied with one token, but it remains inactive until the price enters its range.
What Happens If a Token Charges a Transfer Fee or Changes Balances Through Rebasing?
Nonstandard transfer behavior can prevent a liquidity position from operating or exiting as expected. Uniswap v3 and v4 do not support fee-on-transfer, rebase or reflection tokens, and liquidity supplied with such tokens may become irretrievable. Check the exact token contract and its transfer rules before granting an allowance, even when its symbol matches a familiar asset.
How Are Uncollected Fees Used When More Liquidity Is Added to a v4 Position?
Uncollected v4 fees can be applied as part of the added liquidity. The transaction uses those accrued token amounts first, reducing what must come from the wallet to reach the selected addition. Review the final wallet debit because it may be lower than the total amount being added, and remember that the resulting position remains subject to its existing range.
Is an out-of-range Concentrated Position Liquidated?
No, crossing a range boundary does not liquidate a Uniswap v3 or v4 position. The position becomes single-sided and stops earning liquidity-provider fees while the pool price remains outside its range. It can become active again if the price returns. The provider can also remove the available token, subject to transaction execution and network cost.
Are Newly Created fee-tier Pools Guaranteed to Receive Trades?
No, creating a pool for a pair and fee setting does not create trading demand. Swaps use routes selected under prevailing liquidity and execution conditions, so a new or shallow pool may receive little activity. Without relevant swaps, its providers earn little or no swap-fee income even though the position exists and its creation transaction succeeded.
Could a v3 or v4 Price Range Be Edited After the Position Is Created?
No, the boundaries of an existing concentrated-liquidity position cannot be edited in place. Changing them requires removing liquidity and creating a new position with the desired range. That process realizes the current token mix, collects applicable fees and introduces new transaction costs. The replacement should be reviewed as a separate onchain commitment.
Why Might a New Position Contain Unequal Values of the Two Tokens?
The required token proportions depend on the pool price, selected range and usable tick boundaries. A range centered differently around the current price may require more value from one token than the other, and interface rounding can produce a small imbalance. A fully out-of-range position is single-sided, so unequal values do not by themselves show that creation failed.