Uniswap

Uniswap routes token swaps through liquidity pools and lets providers manage onchain positions.

A connected wallet can swap supported tokens through Uniswap pools, while a provider can supply assets to those pools. Before committing, confirm the network, then verify each token contract or identify the network’s native asset. Inspect the quoted output, route, price impact, pool fee, and network cost, then verify the onchain receipt and final balances.

Pool liquidity turns input into output

Each pool pairs two assets, and a swap adds one while removing the other. The pool’s pricing function determines how much output the input can buy. Larger trades move farther along that function, so the execution price changes during the trade rather than waiting for a matching order.

Uniswap v2 prices swaps through the constant-product relationship x × y = k before accounting for the input fee. In v3 and v4, liquidity can occupy selected price ranges. The active liquidity near the current price therefore matters more to execution than liquidity assigned to ranges the trade never reaches.

What does pool depth change for a swap?

Pool depth determines how much active liquidity can absorb a trade near the current price. A small order relative to that liquidity usually moves the pool price less. The same order can produce much greater price impact in a shallow pool or a concentrated pool with little liquidity across the required range.

Price impact comes from the trade itself. Slippage describes a change between the quoted result and the executed result while the transaction waits. A deep pool can reduce price impact, but it cannot freeze market conditions or guarantee that a pending transaction will execute at its first quote.

Routing across available liquidity

A route may use one pool, pass through an intermediate token, or split the input across several pools. The routing system compares expected output after pool fees and estimated network costs. An extra hop only helps when its pricing improvement exceeds the added execution cost.

Available routes can span v2, v3, and v4 liquidity. An eligible interface trade may also use UniswapX, where third-party fillers compete to complete an order. This is a different execution path from a direct pool swap, so the displayed route and settlement terms deserve attention before signing.

Which cost belongs to which part of execution?

A swap can include a pool fee, a network cost, and token-level transfer behavior. Pool fees and network costs have different recipients, while token behavior can change the received amount or make the route fail. Combining all three into one percentage obscures the execution result.

Pool fee

The pool fee is applied under that pool’s rules. Its size depends on the protocol version and pool configuration. A v4 pool may use a hook that changes fee behavior. The quote should therefore identify the fee attached to the selected route rather than relying on a fee remembered from another pool.

Network cost

The network cost pays for transaction processing. Demand, transaction complexity, and the selected network affect it. A new token approval can require a separate onchain transaction, and a reverted swap can still consume the network asset used for execution.

Token contract behavior

Some token contracts deduct transfer fees, change balances, or depart from ordinary ERC-20 transfer behavior. Those mechanics can reduce the received amount or make a route fail. A pool’s existence does not prove that its tokens behave normally.

Slippage defines the commitment boundary

Maximum slippage determines the worst execution change that the transaction will accept. For an exact-input swap, the route translates that tolerance into a minimum output. If execution would deliver less, the transaction should revert instead of settling outside the signed boundary.

A wider tolerance does not improve the quote or create deeper liquidity. It merely accepts a broader set of outcomes. A transaction deadline is a separate constraint: it limits how long the submitted instruction remains valid, while the minimum output limits the price movement it will accept.

Liquidity choices across protocol versions

Protocol versions differ in how providers distribute capital, represent positions, and collect fees. The version label alone does not identify the better position. The relevant comparison is where liquidity will be active, what fee rules apply, and how much management the chosen structure requires.

Full-range v2 positions

Uniswap v2 distributes a position across the full possible price range and charges a fixed 0.30% swap fee. Pool shares represent a proportional claim on both reserves. Fees remain in the pool, increasing the reserves represented by those shares until liquidity is removed.

Concentrated v3 and v4 positions

Uniswap v3 introduced concentrated liquidity, allowing providers to assign capital to selected price ranges. Concentration can supply more liquidity near the active price with the same assets, but the position stops earning swap fees when price leaves its range. V4 keeps concentrated liquidity and adds configurable hooks and more flexible pool fee choices, so two pools for the same pair can behave differently.

Position state affects fee accrual and inventory

A liquidity position changes composition as swaps move the pool price. The provider is continually exchanging one asset for the other through the pool’s pricing function, even without manually placing separate orders.

While the position is active

In-range v3 and v4 liquidity participates in swaps and can accrue the provider’s share of applicable fees. Those fees remain available for collection under the position’s accounting rules; they are not automatically proof that the position outperformed holding the two assets outside the pool.

After price leaves the range

An out-of-range position becomes entirely one-sided and stops earning new swap fees. It can become active again if the pool price returns to its range. Until then, creating a wider or differently placed position, waiting, and withdrawing carry different network costs and exposure.

Impermanent loss compares the position’s value with the value of retaining the supplied assets separately. Fee income may offset that difference, but it does not remove the comparison. Evaluation therefore needs both token quantities and collected or uncollected fees.

Token identity and approval scope

An ERC-20 token is identified by its contract address and network, not by its name, symbol, or icon. Anyone can create a token or a pool, and unrelated contracts can display identical symbols. Selecting the wrong contract can produce a valid transaction involving the wrong asset.

An ERC-20 approval grants a named spender permission to move up to an allowed amount. Uniswap interfaces may combine an onchain Permit2 approval with a separate signature that limits a later spend. A gasless signature still carries authority, so its spender, token, amount, and expiry should match the intended action. Revoking an allowance changes future authority but cannot undo a completed transfer.

Failure states and reconciliation

A quote error, pending transaction, reverted transaction, and successful transaction describe different states. A quote that never reaches the network changes nothing. A pending transaction has no final result. A revert rolls back the swap’s state changes, although the network cost is generally spent.

View full-size image

A separate approval that succeeded before a reverted swap normally remains in force. Reconciliation should therefore inspect each transaction independently. The successful swap receipt, emitted token-transfer events, and final wallet balances establish what executed. A delayed interface display does not by itself prove that the onchain transaction failed.

When should a liquidity position be changed or closed?

A position may need attention when its range no longer matches the intended exposure, its inventory has shifted too far toward one token, or expected fee income no longer justifies management costs. There is no fixed schedule. Pool price, active range, accrued fees, network cost, and desired token balance supply the relevant evidence.

V2 liquidity has no adjustable range, so changing its structure requires removing liquidity and supplying it under a different setup. A v3 or v4 provider can remove some or all liquidity, collect available fees, and create another range if desired. Repositioning is a new onchain commitment, not a free edit. A v3 position that ends entirely in one token, for example, shows that its selected price boundary has been crossed.

Questions worth asking