Uniswap Swap Status Checks Before the Next Action

Quoted, Submitted, and Settled States

A swap can be at the quote stage, have a wallet-authorized request awaiting execution, or have a transaction settled by the network.

A quote estimates the route and output under current conditions. It does not reserve liquidity, lock a price, or prove that the wallet can complete every prerequisite. The wallet may next request a token approval, a permit signature, an order signature, or confirmation of an onchain swap. Reading that request matters because approval and execution create different evidence.

A submitted onchain swap normally has a transaction hash. The hash may lead to a pending record, a successful receipt, or a failed receipt. A pending record means the network has not settled the call. A failed receipt means execution reverted. Success means the call did not revert, although the receipt still needs to match the intended swap rather than an approval or unrelated action.

UniswapX adds another possible middle state. Its signed order can wait for a third-party filler, so an unfilled order does not necessarily produce a user-broadcast swap hash. The route shown by the interface therefore determines which evidence should exist. Compare like with like before deciding that an attempt disappeared.

How Do You Know Whether a Swap Finished?

A completed swap has a successful record on the correct network plus balance changes that match the intended token pair and the limits accepted in the signed request.

The transaction hash connects wallet activity to the network record. Confirm the sending account, network, receipt status, called contract, and token transfers. A successful transaction receipt shows that the network executed the submitted call without reverting. It does not, by itself, prove that the call was the intended swap or that a wallet displays every resulting token.

Balance evidence completes the check. Compare the input spent and output received with the receipt and transfer records, allowing for the minimum output accepted in the signed request. A wallet label can lag or omit a token, while the onchain balance already reflects settlement. If the hash points only to an approval, the exchange has not happened.

Waiting Without Creating a Duplicate Swap

A pending transaction calls for waiting when the explorer shows that the original hash remains live and its conditions are unresolved. Until the network confirms, rejects, or replaces it, the wallet interface cannot establish the final result by itself.

Submitting an identical swap while the first one remains pending can create two executable requests. If both reach the network as valid transactions, both may settle. A newly displayed quote does not amend the request already signed. That earlier request keeps its encoded limits and deadline, even while the interface shows different market conditions.

View image file

On account-based EVM networks, transactions from one address use nonces to establish order. A later nonce may wait behind an earlier pending transaction. Some wallets can cancel or replace the earlier request by submitting a competing transaction with the same nonce and a higher network fee, but support and rules vary. Check the explorer after any replacement because the original and replacement compete for settlement.

Retrying After Rejection or Reversion

A retry becomes appropriate only after the prior attempt can no longer execute or the interface never submitted it.

Rejecting a wallet prompt leaves no network transaction for that rejected request. A failed simulation can also stop the process before broadcast. In either case, there should be no swap hash to wait on. A broadcast EVM transaction that later reverts is different: the swap state changes roll back, but the network may still charge for processing the failed call.

Start the retry with a fresh quote. Recheck the account, network, input balance, token contracts, approval state, expected output, and network cost before signing. The failed attempt may have revealed a specific cause, such as an expired deadline, insufficient native token for gas, an inadequate allowance, changed output, or incompatible token behavior. Fix that cause rather than repeating the same request.

Repeated simulation warnings or matching reverts mark a stopping point. More attempts do not correct transfer restrictions, unsupported token mechanics, missing liquidity, or a broken approval path. Preserve the transaction hashes and error details, then identify the failing prerequisite before authorizing another onchain call.

Adjusting Size, Slippage, and Deadline

Swap adjustments change different constraints, so the observed failure should determine which setting, if any, deserves revision.

Reducing the input amount can lower price impact when available liquidity is shallow. For routes that expose it, slippage tolerance defines how far execution may move from the quoted output before the transaction reverts. This setting does not apply to UniswapX swaps. A wider tolerance may increase the chance of execution, but it also accepts a worse result. It cannot make a restricted token transferable or repair a nonstandard approval.

For an onchain swap that encodes one, a deadline limits how long the request may remain executable before it reverts. A shorter deadline reduces the period of exposure to changing conditions, while an overly short deadline may expire before inclusion. Network fee settings can affect how quickly the network includes a transaction; they do not change pool liquidity. Adjust one cause at a time, then review a newly calculated quote.

Reconciling a Successful Receipt With the Wallet

Balance reconciliation explains a successful receipt that appears inconsistent with the token list, activity label, or expected output.

Begin with the wallet address and network recorded by the successful transaction. Then compare the token contract addresses, transfer records, and balances on that network. The same symbol can represent different contracts, and some wallets hide unfamiliar or small balances. Adding the verified token contract to the display can reveal a balance that already exists onchain.

A successful approval is not a successful swap. It changes spending permission without exchanging the input token. Likewise, a missing fiat estimate or chart does not establish that the token balance is absent. The receipt and contract balance answer the ownership question; portfolio pricing is a separate display function.

Crosschain routes require separate source and destination checks. A completed source transaction may precede destination delivery, and the output belongs on the destination network. Follow the route status and destination balance before retrying any stage. Repeating the source action can create an additional transfer rather than complete the first one.

A Decision Checklist Before the Next Action

Match the current record to one of these states before signing another request.

• No transaction hash or order record: confirm whether the wallet submitted anything before creating another request.
• Pending onchain hash: wait, or use a supported cancellation or replacement only after checking its nonce and status.
• Failed or expired attempt: obtain a fresh quote and correct the recorded cause before retrying.
• Successful receipt with missing output: reconcile the account, network, token contract, transfers, and balance.
• Repeated warning without a clear fix: stop and identify the approval, liquidity, token, or routing constraint.

Create another swap only after the prior request has succeeded, failed, expired, been canceled, or been replaced, or after confirming that nothing was submitted. A successful swap moves to balance reconciliation, while a failed or expired attempt moves to a fresh quote. An unexplained warning ends the attempt until its cause is known, because wider settings cannot repair every failure.