Uniswap settles signed transactions and orders only when route-specific limits pass, recording token balance changes and any pool updates.

A swap becomes a state transition

One submitted transaction can coordinate the transfer, pool calculation, fee accounting, and delivery of the output token. Before submission, an interface or routing service reads pool state and simulates possible paths. This produces a quote without moving funds or reserving liquidity. The wallet then authorizes the specific transaction or signs an order containing its execution limits.

In a classic pool swap, a router calls the selected pool contracts after the transaction enters a block. Each pool calculates how much output its current state permits. Successful execution reduces the wallet's input balance, increases its output balance, updates pool accounting, and emits transaction logs. Those changes occur together. If a required call fails, the chain discards the attempted balance and pool updates rather than leaving a partly completed route.

Pool liquidity supplies the executable price

Two token reserves define the basic Uniswap v2 market. Its contracts use the constant-product relationship between those reserves to price a swap. Buying one side changes the reserve ratio, so the next unit becomes more expensive. Trading fees enter the pool's accounting, which means the reserve product can grow rather than remaining numerically fixed after every completed trade.

Uniswap v3 lets liquidity providers concentrate liquidity within chosen price ranges rather than spreading it across the full range. A swap can cross several active ranges, and each crossing changes which liquidity contributes to the calculation. Uniswap v4 retains concentrated liquidity while placing pool accounting under a shared manager contract. It also permits hooks, which can add pool-specific logic around swaps, liquidity changes, and fees.

The version matters because reserve accounting, position structure, and permitted customization differ. A quote therefore belongs to a particular route through particular pools. It is not a universal exchange rate for every version or pool carrying the same token pair.

Routing chooses where balances change

A route may use one pool, several sequential pools, or a split across parallel paths. The routing calculation compares expected output while accounting for pool fees, available liquidity, price impact, and estimated network cost. A longer path only helps when its improved execution outweighs the added calls and cost.

Multi-hop execution uses an intermediate token between the selected input and output. A split route sends portions through different pools, then combines the proceeds. Every participating pool receives its own state update, but the transaction remains atomic. The wallet should receive the intended final token rather than retaining intermediate balances when all calls complete as designed. Failure in any required hop reverts the entire onchain route.

Approvals set the spending boundary

One authorization can determine whether the router may move the input token at all. Tokens using the ERC-20 allowance model generally require an approval before a contract can transfer them from a wallet. That approval is separate from the swap, so a successful approval does not prove any exchange occurred.

The spending boundary can be an exact amount, a larger cap, or an unlimited allowance. A wider allowance avoids repeated approval transactions but grants more continuing authority to the approved contract. Some routes use Permit2 signatures to express token permissions and time limits without creating a new approval transaction for each swap. Native network assets follow different transfer rules because they are not ERC-20 tokens. The required authorization therefore changes with the input asset and execution path.

What changes between the quote and execution?

The onchain state can move between quotation and inclusion, causing the executed output to differ from the preview. Other swaps may alter reserves, active liquidity, or the route offering the best return. The submitted transaction does not gain priority merely because an earlier simulation produced a favorable quote.

For an exact-input swap, slippage tolerance normally becomes a minimum acceptable output. The relationship is minimum output = quoted output × (1 - tolerance). The transaction reverts if execution would deliver less. An exact-output swap instead limits the maximum input it may spend. Price impact is different: it is the price movement caused by the swap itself as it consumes liquidity. Market movement before execution and the swap's own impact can both affect the final calculation, while the limit defines the boundary the contracts must enforce.

---

A worked swap when token compatibility decides the outcome

Every quantity and condition in this worked example is hypothetical. A reader wants to exchange 137.5 units of an input token. The displayed route quotes 82.6 units of an output token, and the reader chooses a 1.0% tolerance. The minimum acceptable output is therefore 81.774 units.

1. The reader confirms a route whose contracts can transfer and account for both tokens as quoted. The wallet has enough input tokens, sufficient authorization, and the native asset required for execution costs.
2. By the time the transaction executes, pool state permits an output of 82.2 units. That amount exceeds 81.774, so the swap succeeds. The wallet gives up 137.5 input units and receives 82.2 output units, while the affected pool state records the corresponding changes.
3. The transaction receipt reports success, and the resulting wallet balances agree with the executed amounts. This evidence distinguishes the completed swap from an approval, a pending submission, or a simulation.
4. In the edge case, the input token deducts a transfer fee the selected route does not support. The router receives less than its calculation assumed, so its accounting or minimum-output check fails. The transaction reverts, the requested swap does not change the requested token balances or pool state, and execution cost may still be charged.

A compatible quoted route is the fallback only if it explicitly handles the token's transfer behavior. Increasing tolerance cannot repair an accounting incompatibility. If no compatible route exists, the swap cannot complete through that path.

View full-size image

Confirmation provides settlement evidence

A pending transaction proves submission, not execution. While it waits for inclusion, the relevant pool state can continue changing. The transaction may eventually succeed, revert, be replaced, or disappear from the pending queue. Its deadline can also make it invalid if execution occurs too late.

After inclusion, the receipt records success or failure and identifies the block containing the attempt. A successful receipt, the resulting balance changes, and the expected contract events together show the onchain exchange occurred. Additional block confirmations reduce uncertainty from short chain reorganizations. A wallet interface may refresh slowly or hide an unfamiliar token, so its display alone is weaker evidence than the recorded balance and transaction status.

Reverts protect pool accounting

A revert cancels the swap's requested state changes when an execution boundary fails. Common causes include:

• The output falls below the minimum, or the required input exceeds the maximum.
• The transaction reaches execution after its deadline.
• The wallet lacks the required input balance or token allowance.
• A token's transfer, rebase, or reflection behavior conflicts with the selected router.
• A pool hook or another contract check rejects the operation.

The network still performed work before discovering some of these failures, so a reverted transaction can consume gas. Retrying with the same stale quote may reproduce the error. A fresh simulation can account for updated liquidity, but it cannot make an unsupported token implementation compatible. Widening slippage also changes the economic boundary and should not be treated as a universal repair.

Pool routes and UniswapX use different executors

A classic swap sends an onchain transaction through Uniswap protocol pools. The wallet submits the transaction, the router invokes the pools, and the selected chain processes the calls. Liquidity providers supply the reserves used by those pools, while the swapper pays the execution cost unless another mechanism sponsors it.

UniswapX sends a signed order to an open network of third-party fillers that compete to execute it. A filler may use automated market makers or other available liquidity, then submits the settlement transaction. The signed order defines the acceptable result, and funds move only when a valid fill satisfies those terms. An unfilled or expired order does not perform the requested exchange. Its explorer record can also look different because the filler, rather than the swapper, submits the settlement transaction.

Liquidity providers reconcile fees and inventory

Liquidity providers make pool execution possible by depositing token inventory and receiving a position claim. Swaps change the quantities held for that position as traders move the pool price. Fees accrue under the rules of the pool version and, for customized v4 pools, any applicable hook logic.

Position accounting is not identical across versions. Uniswap v2 represents a share of paired reserves, while concentrated-liquidity versions track liquidity within selected price ranges. A position outside its active range does not supply the same two-sided liquidity as an in-range position. When a provider removes liquidity, the withdrawn token mix can differ from the amounts originally deposited because completed swaps changed the pool composition.

Reconciliation therefore uses the current position amounts and any collectible fees, not the initial deposit alone. Exiting a position withdraws the provider's available share; it does not reverse swaps already settled against the pool.

Contract identity closes the reconciliation loop

A complete settlement check ties together the network, token contract addresses, transaction status, and resulting balance changes. Token names and symbols are not unique identifiers. Two contracts can display the same label while representing unrelated assets, so a familiar ticker does not establish compatibility or value.

The transaction record can show which contracts were called, which assets moved, and whether execution succeeded. It cannot prove a token is economically sound or that a broad approval remains desirable. Revoking an unused allowance limits future spending authority, but it does not alter a completed swap.

For a route contained on one network, one successful atomic transaction normally records the exchange. A cross-network operation has a different proof boundary: source-chain success alone does not establish destination delivery. Reconciliation must also find the destination-side completion and balance change. The evidence required changes when execution crosses that network boundary.