Uniswap swaps move from a quote to a verifiable onchain result

Uniswap lets a wallet holder exchange compatible tokens through smart-contract liquidity pools while retaining control of the wallet. A quote proposes an input, output, route and minimum acceptable result. Approval authorizes token spending when required, wallet confirmation submits the transaction and the network decides its final state. Completion means more than seeing a success message: the transaction record, token movements and wallet network should describe the same settled swap.

In short: A reliable swap ends only when the transaction status, asset movement and wallet network all agree.

Choose the compatible path before requesting a quote

A same-network path exists only when both assets are available on the selected network and an execution route connects them. A crosschain path instead requires support for both its source and destination networks. The wallet must also hold the network asset required to submit any approval and swap transactions.

For ERC-20 inputs and outputs, verify token contract addresses because symbols and names can be copied. A same-network swap draws from pools deployed on that chain, while a crosschain route adds bridge settlement and can use fillers on the destination network. Protocol versions and pool availability can differ by network. If an asset, contract or network does not match, switch to a supported configuration before granting permission. Changing the display token alone does not move an asset between networks.

What changes between the quote and wallet confirmation?

The quote is a temporary proposal, while wallet confirmation authorizes execution under defined limits. It should identify the input, estimated output, route, price impact, pool fees, network cost and minimum output. Pool state and network conditions can move before inclusion, so the quoted amount is not a settled balance. Price impact comes from the swap itself. Price slippage is the difference between the expected and executed results.

An ERC-20 input may require an onchain approval for a designated spender. A permit signature can grant amount-limited, time-bound permission to a designated spender without itself transferring tokens. Approval changes an allowance; the swap changes balances. The onchain approval and swap records can succeed or fail independently, so an approval receipt never proves that the exchange occurred.

Before signing, check these five conditions:

• The network and token contracts match the intended assets.
• The input, estimated output and minimum output remain acceptable.
• The route and any custom pool or bridge dependency are understood.
• The wallet holds enough network asset for every onchain step.
• The approval scope matches the intended amount and spender.

Pool state and routing set the executable result

Liquidity pools supply the inventory that makes a swap executable. In a v2-style pool, the familiar x × y = k relationship links the two reserves. A swap changes both reserves and therefore the pool price for the next unit, while the fee affects how the reserves update. Trade size therefore matters relative to available liquidity, not merely as an absolute amount.

A route can use one pool, cross multiple pools or split the input across paths when that improves the quoted outcome after costs. Uniswap v3 concentrates liquidity inside chosen price ranges, so active depth can differ sharply by price. Uniswap v4 retains concentrated liquidity and adds hooks that can alter pool behavior at defined points. A hook is separate smart-contract code, and its rules belong in the route assessment.

View image file

How do you prove the swap finished?

For a same-network swap, a successful transaction that has reached finality and the expected balance changes prove that it finished. The receipt should belong to the intended network and show the submitted transaction hash. Token transfer events and balance changes then show which contracts and addresses moved value. An interface notification is useful, but it is not a substitute for the chain record.

Submitted, pending, successful and reverted are different states. A transaction shown for signature may never reach the network, while a pending transaction has no final outcome yet. A successful approval changes spending permission only. A reverted swap reaches the chain but rolls back its intended token exchange.

Crosschain execution adds another boundary. Source-chain success may begin the route without proving destination delivery. Check the route status and the receiving network separately. If the destination wallet view lacks the asset, compare its network and token contract with the completed record before repeating any action.

Pending, reverted and expired states need different responses

A pending transaction calls for a status check before another submission. Confirm whether the network received it and whether an earlier transaction from the same wallet is blocking progress. Waiting, replacing or cancelling may be available through the wallet, but each choice depends on the network and transaction state. Submitting the swap again too early can create a second valid transaction or order.

A reverted onchain transaction can still consume a network cost because the network processed it. Common causes include a minimum output that the pool can no longer satisfy, an expired deadline, insufficient allowance or incompatible token behavior. Raising slippage does not fix a wrong contract, unsupported token logic or missing network funds. An expired quote or signed order needs a fresh quote or order. For other failures, requote only after the specific condition has changed.

Liquidity provision creates a different commitment

Providing liquidity commits assets to a pool position rather than exchanging one balance for another. The position earns its share of applicable swap fees, but its token composition changes as traders use the pool.

Uniswap v2 positions cover the full price range. V3 and v4 positions can concentrate liquidity within selected bounds or span the full range. A concentrated position stops earning swap fees when price moves outside its chosen range. Range choice therefore affects capital exposure, active liquidity and how often the position needs attention.

Withdrawal returns the assets represented by the position at that time, not necessarily the quantities originally deposited. Relative price movement can leave the provider with a different mix than simply holding both assets. Accrued fees may offset part of that difference, but they do not promise a profit.

V4 hooks add another contract dependency. They can customize fees, liquidity handling or swap execution at defined points. Their behavior comes from the hook code rather than the base pool alone, so a provider needs to understand those rules before committing assets or approving token spending for that position.

Reconcile permissions and records after settlement

A clean exit matches current balances, transaction status and remaining permissions against the intended outcome. This final pass separates a completed swap from a successful approval, a partial crosschain route or a wallet display problem.

Review any token allowance left for the spender after the transaction. Revoking an allowance limits future spending authority but does not undo a completed swap. Revocation is a new onchain action and can require a network cost. A narrowly scoped allowance reduces what remains available to the approved contract.

Keep the relevant transaction hashes, networks, token contract addresses, input amount and received amount together. These fields provide a durable starting record for later reconciliation. If the balances or liquidity position change again, use the newer transaction as another record rather than rewriting the earlier result. The next action should begin from the confirmed onchain state, not an old quote or cached wallet screen.

Uniswap: the short answers

Updated on 16 September 2026