Why did the network charge me when the swap failed?

An onchain failure can still incur a network fee because validators processed the transaction before its execution reverted. The intended token exchange does not settle. A pre-submit interface error is different: if no transaction reached the network, there should be no execution fee for that attempt. Use the explorer record to distinguish the two cases.

Does a successful approval mean the token swap succeeded?

No. An approval only grants a contract permission to use a specified token amount under its terms. The swap is a separate action unless the wallet batches both operations into one transaction. Check whether the activity entry and explorer record describe an approval, a batched call or the swap itself. Token output proves the exchange, while an allowance change only proves permission.

When is it reasonable to retry an expired swap?

Retry only after the original transaction or order has expired or failed and can no longer complete the swap. Request a fresh quote because pool state, route, network cost and minimum output may have changed. If an onchain transaction remains pending, submitting another ordinary swap can create a second queued transaction rather than replacing the first. Resolve the pending nonce before trying again.

Why is a replacement transaction visible instead of my original swap?

A wallet may speed up or cancel a pending EVM transaction by broadcasting another transaction with the same nonce. Only one can be included, so explorers may label the first as replaced, dropped or canceled once the competing transaction wins. Review both hashes and the shared nonce. A successful cancellation prevents the original pending call from executing, but it does not reverse a swap already included.

Where should I look when a cross-network swap shows partial progress?

Check the source network record first, then inspect the route's destination or bridging status in the app. Source-chain success may only prove that the first step executed; delivery on the destination can remain in progress. Confirm the receiving address, destination network and token movement before retrying. Repeating the whole route while an intermediate step continues could create a separate transaction.

Could token transfer rules cause every retry to fail?

Yes. A token may charge a transfer fee, change balances through rebasing or use approval behavior that the chosen router does not support. Those conditions can make the quoted output unattainable or prevent the transfer. Raising slippage does not repair every incompatibility and increases the acceptable price movement. If identical attempts revert, inspect the failure reason and token behavior before submitting another transaction.

Uniswap swap status helps you decide whether to wait, verify, cancel or retry

For a direct onchain swap, read status from the transaction record rather than relying only on a wallet notification. A pending transaction has not yet been included in a block. A successful receipt means the call executed, while a failed receipt means it reverted. Before waiting, canceling or retrying, match the transaction hash, wallet address and selected network in a block explorer.

The same screen can describe an approval, a direct swap, an order or one stage of a cross-network route. Identify that action first. Each type leaves different evidence and calls for a different response.

The short version: Do not act on a wallet label alone. Match the swap to its onchain transaction, signed order or cross-network route before waiting, replacing or retrying.

A transaction hash separates submission from display

A wallet confirmation does not prove that the network received the swap. Check whether the transaction hash resolves in an explorer for the selected network. Once the wallet broadcasts a signed transaction, that hash identifies the submitted instruction on the selected network.

A hash that resolves in the matching explorer means the network knows about the transaction, even if the app still shows a spinner. The explorer can then show whether it remains pending or a block already contains it.

If the app reports an error before a hash appears, no onchain swap may exist. Check wallet activity and the correct explorer before sending another request. A newly broadcast hash can also take a short time to appear, so refresh before assuming submission failed.

Keep the hash with the wallet address and network. Those three details prevent a common mistake: checking a similar-looking transaction on the wrong network or account.

Pending status maps to several observable states

For a direct onchain transaction, pending means it has not yet produced a receipt. It does not show whether the eventual swap will succeed.

A wallet may retain a pending label for a request that never reached the public network. A local activity row and an explorer record are different evidence. Clearing cached activity can fix the display, but it cannot confirm or cancel an onchain transaction.

A visible pending record

The explorer has the hash, but no block contains it yet. Network demand, the offered fee and earlier transactions from the same account can affect inclusion. The quoted output may also become stale while the transaction waits.

No matching record

Search with the exact hash on the selected network, then inspect the wallet address. A missing record can reflect propagation or explorer delay. It can also mean the wallet never broadcast the transaction, so an immediate duplicate is not the first step.

Several queued transactions

On EVM networks, the account nonce orders transactions. An older pending transaction can hold up later transactions from that account. Resolve the earliest blocked nonce before treating each later entry as an independent Uniswap problem.

When should you keep waiting?

Keep waiting when the matching explorer still shows the original transaction as pending, you do not need to replace it and you accept that execution conditions may change. A pending transaction does not yet have an onchain receipt. Its final success or failure therefore remains unknown. Check the configured swap deadline as well. If execution occurs after that deadline, the call can revert rather than settle at an outdated quote.

Wallet and app indicators can lag or retain cached activity. Refreshing the display may clear a stale spinner, but it does not alter a genuinely pending network transaction. The explorer record remains the better basis for waiting.

Cancel and speed-up actions compete with the pending transaction

A speed-up request normally replaces the intended call at the same nonce with a higher fee. A cancellation usually sends a replacement that performs no swap. Both actions matter only while the original transaction remains pending.

On EVM networks, a cancellation attempt competes with the pending transaction by using the same account nonce. Whichever valid same-nonce transaction lands first determines the outcome. Cancellation can carry a network cost and it cannot undo a swap that already entered a block.

Submitting a fresh swap is different from replacing the pending one. The new request can sit behind the original nonce, leaving both instructions unresolved. When several entries are pending, inspect their nonce order before choosing any action.

A confirmed record still needs a success check

Confirmation proves block inclusion, but inclusion alone does not prove that the token exchange succeeded. Read the receipt result and the token movements.

Block inclusion

A block number and timestamp show where the network included the transaction. Additional confirmations strengthen settlement confidence under that network's rules. They do not convert a failed execution into a successful swap.

Receipt result

On an EVM network, the receipt status distinguishes a successful top-level call from a failed one. A failed call reverts the token movements and contract changes attempted by the swap. The explorer may still show a completed or confirmed record because validators did execute and include it.

Token movement

For a successful same-network swap, inspect the input and output token transfers, the receiving address and the amounts. A balance panel can hide an unfamiliar token or show another network. The transfers show completion more reliably than a green interface message.

Failed swaps require a cause-specific retry

A retry makes sense only after the condition that caused the failure has changed. Repeating the same call with the same limits often produces the same outcome.

An interface warning before submission is not an onchain failure. It may prevent a likely revert and leave no transaction hash. Resolve the warning's stated cause before trying again. Browser or connection errors also belong to this pre-submit state unless the wallet shows that it broadcast a transaction.

An expired deadline calls for a fresh quote and a new transaction. A minimum-output failure also calls for current route data, but blindly widening slippage accepts more price movement. Read the live limit before authorizing another attempt.

Insufficient network currency can stop submission because the account cannot cover the network cost. A gas limit that is too low can instead cause a submitted transaction to fail during execution. Token-specific transfer fees, rebasing behavior or non-standard approvals can also conflict with a route. Check the route's token support and approval requirements before trying again.

On EVM networks, a failed receipt can still consume a network fee because validators executed the transaction. The intended exchange does not settle, so the input tokens should not move through that reverted call. Compare the receipt, transfers and balance before retrying.

Checks to run before the next action

Use one consistent record set before choosing to wait, replace or retry. This prevents an interface delay from turning into a second transaction.

View image file

Match the transaction hash, wallet address and network.
Identify whether the entry is an approval, signature, swap or route stage.
For an onchain transaction, read the explorer state, receipt result and any replacement label.
For success, compare token transfers with the intended receiving address.
For pending or failure, resolve the nonce or cause before resubmitting.

Stop once the evidence establishes what happened. A successful receipt with the expected transfer means the swap succeeded even if the wallet display has not updated. A failed receipt needs diagnosis. A still-pending hash needs a wait or replacement decision rather than an ordinary retry.

Approval, order and cross-network states need different evidence

A status label becomes useful only when it refers to the action you intended. One swap flow can create more than one permission or settlement record.

Approval before execution

An approval changes spending permission; it does not exchange the tokens. Some wallets can batch approval and swap actions, while others show separate requests. If only the approval succeeded, the wallet balance should not yet reflect the intended output.

Signed orders and onchain swaps

Some Uniswap routes begin with a signed order that a third party may fill. An unfilled or expired order can end without the user's swap transaction entering a block. A direct onchain swap instead has a transaction hash and a network receipt.

Cross-network progress

A cross-network route can complete its source action while destination delivery continues. Source success is therefore one checkpoint, not proof of final receipt. Verify the destination network, receiving address and delivered token before treating the route as closed.

Did the swap finish if the wallet balance looks unchanged?

An unchanged wallet panel does not by itself prove failure. First confirm a successful receipt and the expected token transfer to the intended address. Then switch to the network where the output arrived and enable that token's display if necessary. If the receipt failed or the transfer is absent, investigate the transaction instead of treating a display refresh as completion.

Common questions about Uniswap

Why did the network charge me when the swap failed?: An onchain failure can still incur a network fee because validators processed the transaction before its execution reverted. The intended token exchange does not settle. A pre-submit interface error is different: if no transaction reached the network, there should be no execution fee for that attempt. Use the explorer record to distinguish the two cases.
Does a successful approval mean the token swap succeeded?: No. An approval only grants a contract permission to use a specified token amount under its terms. The swap is a separate action unless the wallet batches both operations into one transaction. Check whether the activity entry and explorer record describe an approval, a batched call or the swap itself. Token output proves the exchange, while an allowance change only proves permission.
When is it reasonable to retry an expired swap?: Retry only after the original transaction or order has expired or failed and can no longer complete the swap. Request a fresh quote because pool state, route, network cost and minimum output may have changed. If an onchain transaction remains pending, submitting another ordinary swap can create a second queued transaction rather than replacing the first. Resolve the pending nonce before trying again.
Why is a replacement transaction visible instead of my original swap?: A wallet may speed up or cancel a pending EVM transaction by broadcasting another transaction with the same nonce. Only one can be included, so explorers may label the first as replaced, dropped or canceled once the competing transaction wins. Review both hashes and the shared nonce. A successful cancellation prevents the original pending call from executing, but it does not reverse a swap already included.
Where should I look when a cross-network swap shows partial progress?: Check the source network record first, then inspect the route's destination or bridging status in the app. Source-chain success may only prove that the first step executed; delivery on the destination can remain in progress. Confirm the receiving address, destination network and token movement before retrying. Repeating the whole route while an intermediate step continues could create a separate transaction.
Could token transfer rules cause every retry to fail?: Yes. A token may charge a transfer fee, change balances through rebasing or use approval behavior that the chosen router does not support. Those conditions can make the quoted output unattainable or prevent the transfer. Raising slippage does not repair every incompatibility and increases the acceptable price movement. If identical attempts revert, inspect the failure reason and token behavior before submitting another transaction.

Updated on 16 September 2026