Uniswap

Uniswap Swap Lifecycle: Commitment and Reconciliation

On EVM networks, Uniswap turns a quoted token exchange into a verifiable onchain result through wallet authorization, smart-contract execution, and a transaction receipt. A quote is provisional: pool state, routing, fees, and network conditions may change before execution. For EVM routes, the decisive records are the signed request, its transaction hash or order identifier, the relevant receipts on the selected network or networks, and the resulting balances. The lifecycle runs from token and network checks through commitment, confirmation, reconciliation, any applicable allowance review, and exit. Pool versions, filler-based orders, and liquidity positions change what a reader should expect to observe at each stage. On Solana, the interface uses Jupiter routing, so verify the Solana transaction record and resulting balances; the ERC-20, Permit2, receipt, and nonce details below are EVM-specific.

Bottom line: A swap is complete only when each required network stage records success and the resulting balances, fees, and any applicable allowances reconcile.

From Quote to Recorded Outcome

A swap record begins before signature. Match the network, token contract or mint addresses, input amount, quoted output, route, price impact, and network cost with the intended exchange.

A quote estimates execution under a recent state; it does not reserve liquidity or fix the final network charge. For an exact-input trade, the controlling protection is generally the minimum acceptable output. For an exact-output trade, it is generally the maximum input. The wallet review should reflect the same assets and limit. Approval, swap, and bridging requests are separate authorizations when the chosen path requires them. After submission, preserve the transaction hash or order identifier. Completion means the selected network recorded the intended state change and the wallet balances match that record, not merely that an interface displayed a success message.

What Changes When the Route Changes?

The route changes which contracts and liquidity sources execute the trade, who submits the settlement transaction, and which records prove completion. A route may use one pool, several pools, or a split across paths when that yields a better effective output after costs. Liquidity from v2, v3, and v4 can therefore appear within one routing decision. The reader still evaluates the quoted output and price impact, while the router selects a path from available pools.

A standard EVM automated market maker route sends an onchain transaction from the wallet to a router or pool-facing contract. A UniswapX route instead signs an order that third-party fillers compete to settle, possibly using onchain pools or their own inventory. A crosschain swap adds source-network and destination-network stages, so one successful source transaction may not yet show the final asset on the destination network. Each form needs its own completion evidence.

Approval and Signature Boundaries

An allowance authorizes a contract to transfer a specified ERC-20 token up to an allowed amount; it does not execute the swap. The approval itself can be an onchain transaction, so it has a separate hash, fee, and receipt. Permit2 separates the one-time onchain token approval from a later signature that limits a protocol's permission to spend. Before accepting a wallet prompt, identify its exact action, such as token approval, Permit2 signature, swap, wrapping, bridge, or cancellation.

A narrow allowance limits exposure but can require another approval for a later trade. A larger allowance reduces repeated approvals while leaving more spending authority in place. After a swap, the remaining allowance may exceed zero even though the intended token movement finished. Revoking it creates another onchain transaction and network cost. Disconnecting a wallet from an interface does not revoke an ERC-20 allowance because the allowance lives in the token contract's state.

When Does a Swap Cross the Commitment Boundary?

An ordinary onchain swap becomes operationally committed when the wallet broadcasts the signed transaction, while its balance change is recorded only after successful inclusion. Before signing, changing the amount, route, or limit simply abandons the quote. While a transaction is pending, a wallet may attempt to replace it with another transaction using the same nonce and a competitive fee. That attempt is a race, not a guaranteed undo action, because the network may include the original first.

A signed filler order uses a different boundary. The signature authorizes settlement within the order's terms, and the onchain fill creates the final transfer record. An open limit order can expire or be canceled, but the network must process an onchain cancellation before a competing fill to prevent execution. Once a successful fill appears onchain, trading the received asset again requires a new transaction.

Reading the Onchain Receipt

A transaction receipt is the network's execution record for the submitted hash. Use it to check status, the containing block, gas consumption, the sending address, the called contract, and event logs. A transaction receipt becomes available only after the transaction is included in a block. A successful receipt does not prove that the user selected the intended token contract.

Token transfer logs reveal movements involving the router, pools, and recipient, but the wallet's net change may differ from any single log. Multi-hop routes can produce internal transfers that never represent a spendable intermediate balance for the user. Network fees usually reduce the native asset separately from the traded token. Reconciliation therefore combines the receipt, logs, and before-and-after balances instead of treating one transfer row as the whole swap.

Failure States and Safe Retries

A rejected wallet request never reaches the network. No transaction hash usually means there is no new onchain state, although a previously completed approval remains effective.

A pending transaction has reached the network without final execution. Check its hash and nonce before submitting another swap, since a second transaction from the same account may wait behind it. A replacement or cancellation competes for inclusion and incurs a network cost only if the replacement transaction is included. Confirm which transaction the network accepted before treating either request as abandoned.

View full-size image

A reverted transaction reached execution but failed its contract conditions. The network consumes gas and the account nonce, while contract state changes and token transfers revert. Any separate approval transaction that succeeded earlier can remain active. A retry should use a fresh quote and address the actual cause, such as an expired deadline, output below the minimum, input above the maximum, or incompatible token behavior.

An unfilled UniswapX order differs from an onchain revert because no filler completed the settlement. The swap can be resubmitted after the order is confirmed no longer open or fillable, but a prior token approval or native-token wrapping transaction remains a separate state change. An order that is still open should not be duplicated until its expiry or cancellation state is clear.

Liquidity Provision Beyond a Single Swap

Liquidity provision is the other principal path through the Uniswap Protocol. A v2 position supplies both pool assets across the full price curve and receives fungible liquidity tokens representing its share. Versions v3 and v4 allow liquidity within selected price ranges. A concentrated position outside its active range stops earning swap fees and can become composed entirely of one asset. Pools using v4 hooks may also apply pool-specific logic at defined stages of a swap or liquidity change.

Adding, modifying, collecting from, and removing a position each creates its own record when the action changes onchain state. Reconciliation includes the deposited amounts, position ownership, collected fees, withdrawn assets, and network costs. Fee income does not necessarily offset changes in inventory value relative to holding the assets separately. The correct exit evidence therefore depends on the position version, selected range, and any hook behavior.

A Deliberate Exit Record

A useful exit record contains the network, token contract or mint addresses, transaction hash or order identifier, block or settlement time, quoted limit, executed amounts, network fee, remaining allowance, and final balances. Keeping those fields together makes later accounting and troubleshooting possible without relying on an interface's activity label. Store only what the task requires because public networks expose wallet addresses, transfers, and transaction histories.

The exit point depends on any state that remains after the swap, order, or liquidity action. An open limit order or unfinished crosschain stage remains unresolved, while a remaining allowance or liquidity position requires a deliberate decision to keep or close it. A plain same-network swap can end after a successful receipt and matching balances; a multi-stage route ends only after its intended destination state appears.

Uniswap: frequently asked questions

Updated · 16-Sep-2026