Uniswap swaps move from wallet readiness to a verifiable onchain result
A same-network Uniswap swap moves through four states: a quote, wallet authorization, submission, and a final onchain record. Before signing, the wallet needs the input asset, the network fee token when the route requires an onchain transaction, and any required token allowance. The quote remains conditional because liquidity, routing, and network costs can change before execution. A classic EVM route submits a blockchain transaction, while an eligible UniswapX route hands a signed order to fillers. The interface animation alone does not prove completion. The applicable transaction, order, or bridge records must show success, and the expected output must reach the intended address on the correct destination network. Before authorizing a fresh quote, confirm the earlier action has failed, expired, been replaced, or is otherwise unable to execute.
Updated ยท
Routing choices decide the execution handoff
The selected route determines who submits execution, where liquidity comes from, and which record proves the swap finished.
| Route choice | How execution proceeds | Check before continuing |
|---|---|---|
| Default routing | For same-network EVM swaps, the interface compares eligible UniswapX quotes with Uniswap v2, v3, and v4 pool routes, including split routes when useful. | If the offer changes before authorization, review the replacement quote and authorize only its terms. |
| Classic pool route | The wallet broadcasts one onchain transaction, and router contracts move the swap through the selected pools. | Read its transaction status before replacing, cancelling, or retrying the action. |
| UniswapX order | The wallet signs an order, and a third-party filler submits the settlement transaction. | If no filler completes the order before expiry, request a new quote after the order is no longer fillable. |
Default routing selects a quote; it is not a separate settlement system. It may compare pool liquidity, route length, estimated output, and network cost before presenting an executable path. On EVM networks, direct routes, split routes, and filler-backed orders therefore leave different traces. Crosschain swaps add an Across bridge step between origin and destination networks, while Solana web swaps use Jupiter routing. Match the displayed route to the wallet request because a transaction confirmation and an order signature carry different commitments.
What must be ready before signing?
The wallet needs the correct network, enough input balance, the required spending permission, and any fee asset the selected path places on the swapper.
Balances and network context
For a same-network swap, the input and output tokens must be on the quoted network, and a balance elsewhere cannot fund it. A crosschain quote instead names an origin and destination; the input balance must be on the origin network, and the output arrives on the destination network. Classic execution also needs enough of the network fee asset for approval and swap transactions when those actions are required. On an eligible filler-backed route, the filler pays the settlement transaction's network fee but factors that cost into the swap price. A preliminary approval or native-token wrapping transaction can still require the swapper to hold the network fee asset.
Token identity and spending permission
A ticker and token name do not establish contract identity. The selected token contract, network, and wallet balance must agree before authorization. Connecting a wallet lets an interface read the address and prepare requests; it does not grant token spending power. If the token needs an allowance, the approved amount must cover the intended input. Approval is its own state change, so a successful approval does not mean the swap has executed.
A quote describes conditions, not a reservation
A quote calculates a possible output from the available routes and state at that moment. It can include the path, estimated output, network cost, price impact, minimum received, and an execution deadline. It does not reserve pool liquidity or freeze the market. Price impact describes how the proposed size and route affect the quoted exchange, while slippage tolerance defines how far execution may move before the transaction must stop.
For an exact-input classic swap, the minimum output is the binding protection. If execution would deliver less, or if the transaction reaches the contract after its deadline, the transaction reverts instead of accepting worse terms. The reverted swap does not deliver output tokens, although the network can still charge for processing the attempt. Raising the slippage limit weakens the minimum-output protection; it does not create liquidity or restore an expired quote.
What exactly does the wallet authorize?
The wallet may show a connection, an allowance transaction, a Permit2 signature, and the swap itself as separate requests. Each grants a different capability.
Onchain token allowance
An allowance transaction authorizes a named spender contract to transfer up to a stated amount of one token. The wallet should display the token, spender, amount, and network. An allowance can remain usable until its amount is spent or changed, while a related signature may have its own expiry. Because allowance is separate from execution, rejecting the later swap request can leave that permission in place.
Permit2 signature
Permit2 can pair an earlier onchain token approval with a later signature that narrows the spender, amount, and validity period. The signature itself has no network cost, but it still carries authority over the approved token within those limits. Treat its readable fields as transaction terms, not as a harmless login message. A mismatched token, spender, amount, or expiration is a reason to stop before signing.
Swap transaction or order
A classic swap confirmation authorizes the wallet to broadcast a transaction calling the selected router path. An UniswapX confirmation signs an order a filler may settle under its encoded limits. Neither action should be inferred from the button label alone. The wallet request reveals whether it is sending an onchain transaction or producing an offchain signature, and that distinction determines the next status to follow.
Submission creates the record to follow
After a classic transaction is broadcast, its hash becomes the stable handle for tracking the pending action. A changing interface message does not create a second execution record.
Pending means the network has not produced a final receipt. Inclusion time depends on network conditions and the fee settings attached to the submission, so no fixed completion duration applies. A long wait is not proof of failure, and a refreshed quote does not cancel the original transaction.
When one transaction carries a multi-pool route, its contract calls execute as one atomic operation. Every required transfer and pool interaction must succeed, or the state changes revert together. The swapper can still pay a network fee for the computation used before the revert.
An UniswapX order follows a different handoff. The signed order enters a filler process, and a filler submits settlement if it can satisfy the encoded terms. Until the order fills or expires, the input balance and permission must remain sufficient. Moving the input or removing authority can make settlement fail without turning the old quote into a completed swap.
The submitted deadline or expiry sets the time boundary; there is no universal completion time. Determine whether the original action is successful, reverted, replaced, cancelled, expired, or still pending before deciding what to do next.
How can the final status be verified?
Verify a same-network swap by matching its execution record to the expected token transfer on the quoted network. For a crosschain swap, also confirm the bridge completed and the output arrived on the destination network.
Receipt before interface status
Use the transaction hash and network together to identify a classic EVM transaction. Open that record on the correct network and read its status rather than relying on a cached activity label. A successful receipt means the transaction did not revert. A failed receipt means its intended state changes were not committed, while a pending record still lacks a final result.
Balances and transfer details
Next, inspect the recipient, input token, output token, and delivered amount. The output transfer should match the token identity and destination network expected from the authorized quote. For a crosschain swap, a successful origin transaction does not prove completion while the bridge is still processing. For a classic same-network swap, the network fee appears separately from the token exchange, so a smaller native balance does not by itself prove the swap failed. A wallet can hide a token or lag in refreshing its display; transfer records remain the stronger completion evidence.
Filler-submitted settlement
A filled UniswapX order may not resemble a classic transaction sent directly from the swapper address because the filler submits settlement. Follow the order status to its settlement transaction, then confirm the output transfer reaches the intended recipient. An unfilled expired order has no completed transfer to reconcile. A filled order should align with both a settlement record and the wallet's received token balance.
Recovery starts at the last confirmed state
A pre-submission warning calls for a new quote or a corrected prerequisite, not repeated confirmations. Recheck the network, token contract, balance, allowance, fee asset, minimum output, and deadline relevant to the rejected request. If route simulation changes, read the new terms as a new offer.
For a pending classic transaction, inspect the original network and hash before acting. Waiting, replacing, or cancelling may be available, but a cancellation is another transaction and is not final until the network includes it. For an unfilled order, wait until it expires or becomes unfillable before authorizing a replacement. Confirm the original is final or no longer executable before authorizing a fresh swap, so the original and replacement cannot both execute.
A reverted transaction needs a fresh quote after its specific cause is corrected. A successful record paired with a missing wallet display calls for the correct network and token contract view, not another swap. Stop when the execution record and received balance agree. For a classic swap, use the transaction hash to connect the submitted wallet request with the final receipt.
Quick answers about Uniswap
-
Can I close the interface after a classic swap is broadcast?
- Yes. Closing the page does not cancel a classic transaction the wallet has already broadcast. Save the transaction hash and check it on the same network later. If the wallet never produced a hash, confirm whether it actually sent the request before assuming anything is pending. Do not submit another swap solely because the interface window is gone.
-
What happens to my tokens if a UniswapX order expires?
- An unfilled expired order does not complete the intended token transfer. The order can no longer be filled under those terms, so request a new quote instead of assuming the expired output remains available. Any underlying token allowance is separate and can remain active after the order expires until the allowance is spent, changed, or revoked.
-
Is revoking an allowance the same as cancelling a pending swap?
- No. Revocation changes a spender's future authority after the revocation transaction is confirmed; it does not erase a finalized swap. If a swap and revocation are both pending, their network ordering determines which action can execute first. Check both transaction records before treating the swap as stopped, and remember the revocation itself can require a network fee.
-
Does switching wallet networks cancel a pending transaction?
- No. Changing the network displayed in a wallet does not alter a transaction already broadcast on another network. Return to the original network or use its explorer to inspect the transaction hash. The pending action can still succeed, fail, or be replaced there, even when the wallet interface is currently showing a different balance and activity list.
-
Are the approval and swap network costs charged in one transaction?
- Not necessarily. An onchain token approval and a classic swap can be separate transactions, each with its own network cost. A Permit2 signature is offchain and has no network fee, although the earlier approval may have one. With an eligible UniswapX order, a filler can submit settlement, but any required preliminary onchain approval remains a separate wallet action.