A Uniswap problem often becomes more expensive when a user reacts before identifying what actually happened. A wallet signature, token approval, submitted swap and completed swap are four different events. Refreshing the page, switching networks or pressing Swap again does not reverse an earlier request and can create duplicate approvals or transactions. This guide provides a practical order for diagnosing failed swaps, pending activity, missing tokens and approval problems without exposing the wallet to fake support or recovery sites.

Last reviewed: October 13, 2026. Uniswap interfaces, wallet prompts, supported networks, routing and security warnings can change. Verify current details in the official Uniswap application and documentation. This independent guide is educational and is not financial, investment, legal or tax advice.

Quick answer: stop before retrying. Confirm the wallet account and network, find the transaction hash and check it in the correct block explorer. Determine whether you signed a message, approved a token or submitted the actual swap. If the transaction succeeded but the balance looks unchanged, verify the output token contract, selected network and hidden-token settings. Never share a recovery phrase, install remote-access software or sign a “recovery” transaction offered in a direct message.

The most important rule: diagnose before retrying

A button that appears to do nothing can describe several very different situations. The wallet request may have been rejected, the request may still be waiting in another browser window, the transaction may be pending onchain, or an approval may have completed while the swap itself was never submitted. Each state requires a different response.

Blindly repeating the same action is risky. A second request may become a harmless duplicate signature, another paid approval or a second swap that executes after the first. Begin with evidence rather than the appearance of the interface. The transaction hash and block explorer are generally more useful than a stale button or delayed wallet balance.

What happened Onchain transaction? What to do next
Wallet connection No token transfer by itself Confirm the domain, account and network before continuing.
Offchain message signature Usually no transaction hash or network fee Read the message and permissions; do not assume it is harmless.
Token approval Usually yes, with a network cost Verify the spender and allowance; return to the swap only after confirmation.
Swap transaction Yes, unless an intent-based flow uses a different signing process Check its status and output before submitting anything again.
Rejected wallet request No, if it was never broadcast Correct the cause and create one new request when ready.

Build a reliable evidence set

Before changing settings, record five facts: the public wallet address, selected network, input token contract, output token contract and transaction hash. These facts do not expose private keys. They allow you to distinguish a display problem from an onchain problem and make support conversations more precise.

A transaction hash is a unique identifier created when an onchain transaction is broadcast. Open it from the wallet activity or Uniswap activity and confirm that the explorer belongs to the intended network. The same public address may exist on several EVM-compatible networks, so an Ethereum explorer cannot explain an activity that occurred on Base, Arbitrum or another chain.

Information to collect safely

  • Public wallet address used for the attempted swap.
  • Source network and, for a crosschain route, destination network.
  • Input and output token contract addresses.
  • Transaction hash for every approval or swap that was broadcast.
  • Approximate time, displayed error and expected output.
  • A screenshot with balances, email addresses and unrelated wallet details redacted.

Understand transaction status before taking action

No transaction found

If the wallet has no activity and there is no transaction hash, the request may never have been submitted. The wallet popup may be hidden, the user may have rejected it, the site may have lost its connection or an offchain signature may be expected first. Reconnect only through the verified Uniswap interface and check the wallet notification queue.

Pending

A pending transaction has been broadcast but not confirmed. Do not assume it failed simply because the interface stopped animating. A wallet may offer Speed Up or Cancel, usually by submitting a replacement with the same nonce and a different fee. Availability and behaviour are wallet- and network-specific. Read the wallet documentation before using either control.

Successful

A successful status means the transaction executed according to the chain. Inspect the token-transfer section and balance changes instead of relying only on a green status. A successful approval changes an allowance; it does not perform the swap. A successful swap should show the relevant asset movements, although wallet displays can lag or hide the received token.

Failed or reverted

A reverted transaction did not complete the intended state change, but the network still performed work while processing it. The network fee is normally not returned. Read the failure reason where available, then compare the current quote and wallet state before trying again. Repetition without a diagnosis can produce another failed fee.

Mistake 1: confusing an approval with the swap

ERC-20 tokens normally require permission before a smart contract can transfer them for a swap. That permission is the approval. For a token that has not been approved, the first wallet request can therefore be an approval transaction rather than the swap itself.

After the approval confirms, the user usually needs to return to the interface and authorize the actual swap. If the expected output token never appears, check whether the activity contains only an approval. Uniswap’s official missing-token guidance identifies this as one of the first possibilities to inspect.

Approval Swap
Grants a specified spender permission over a token amount. Attempts to exchange the input token for the output token.
May require a network fee. Normally requires a network fee or follows the displayed order mechanism.
Does not guarantee that a later swap will succeed. Uses current liquidity, route and execution conditions.
Can remain active after disconnecting the wallet from a site. Is a separate operation with its own status and transaction details.

Mistake 2: approving repeatedly without checking the existing allowance

If an approval prompt keeps returning, do not keep paying automatically. First check whether the previous approval confirmed, whether the wallet is using the same account and network, and whether the allowance covers the planned amount. An approval on Ethereum does not create an allowance on another network.

Some tokens use non-standard approval behaviour. Uniswap’s approval troubleshooting documentation explains that an existing allowance may need to be revoked before a new one can be set. It also suggests checking whether the proposed swap is slightly larger than the approved amount. The correct response is a deliberate allowance review, not an endless approval loop.

Exact, balanced and unlimited allowances

An exact allowance limits access to the intended amount but can require a new paid approval for another transaction. A larger or unlimited allowance can reduce repeated approval costs, but it increases the amount potentially exposed if the approved contract or a related signing flow is abused. There is no single setting appropriate for every wallet. Match the allowance to usage frequency, contract trust and the value held in that address.

Mistake 3: treating Permit2 as one ordinary approval

Permit2 is an approval system created by Uniswap Labs and used by compatible applications. According to Uniswap, its flow can involve two layers. First, the user makes an onchain approval for the token to the Permit2 contract. Second, a signature authorizes a particular protocol to use the token under defined conditions.

The second request may not require a network fee, but that does not make it meaningless. A malicious signature can abuse an existing Permit2 approval. Always verify the website, requested token, amount, spender and time conditions. Never sign a message merely because a site calls it “verification” or says it proves wallet ownership.

Before signing an approval request

  • Confirm that the browser is on the official domain.
  • Check which wallet account and network are active.
  • Read the token, spender, amount and expiry where the wallet displays them.
  • Reject unexpected requests that appeared from a message, advertisement or airdrop.
  • Use a separate low-value wallet when exploring unfamiliar applications.

Mistake 4: disconnecting a site and assuming permissions are revoked

Disconnecting a wallet removes the current interface connection. It does not erase an onchain allowance. A token approval remains recorded by the network until it expires under its own rules, is consumed where applicable or is changed or revoked through another onchain transaction.

To revoke an approval, use an approval checker linked from the appropriate verified block explorer or another carefully verified tool. Confirm the network and spender before signing. Revocation itself requires a network cost, and the token will need a new approval if it is used again later.

Mistake 5: retrying while an earlier transaction is pending

Transactions from an EVM account are ordered with nonces. A later transaction may wait behind an earlier pending transaction even when its own fee looks reasonable. Submitting more swaps does not necessarily bypass the queue; it can create several operations that become valid when the blockage clears.

Open the wallet activity and explorer. If a transaction is pending, use only the replacement controls supported by that wallet, or wait for the network outcome. Never follow a stranger’s instruction to enter a recovery phrase, reset the wallet or paste a private key into a “nonce repair” website.

Speed Up and Cancel are replacement attempts

A Speed Up request normally resubmits the intended operation with the same nonce and a more competitive fee. A Cancel request commonly sends a replacement transaction to the user’s own address. Neither is a universal guarantee. The original or replacement transaction that the network accepts first determines the result, and fees can still be paid.

Mistake 6: assuming a refreshed screen cancelled the swap

Once a valid transaction is broadcast, closing a tab, refreshing the page or disconnecting a wallet does not remove it from the network. The interface is a view and transaction-construction tool; it is not an undo button for confirmed blockchain activity.

When a screen looks frozen, open wallet activity in a separate trusted window before touching the swap button again. If a hash exists, track that hash. If it confirms, inspect the output. If it reverts, diagnose the reason and obtain a new quote before creating one replacement attempt.

Mistake 7: using the wrong wallet account

Browser wallets can expose several accounts. Mobile and desktop sessions may also connect different addresses. A quote can remain on screen while the wallet changes accounts, causing an unexpected balance, missing approval or rejected transaction.

Compare the beginning and end of the connected public address in the Uniswap interface with the intended wallet. Do this again in the confirmation prompt. If funds appear missing, search the explorer for each address you control rather than importing seed phrases into additional websites.

Mistake 8: using the wrong network

A token ticker is not a network identifier. USDC, ETH and other familiar labels can appear on several networks, while bridged and native variants may use different contracts. A balance held on Base cannot pay an Ethereum transaction, and an Ethereum approval does not authorize a Base contract.

Check the network in three places: the wallet, the Uniswap swap screen and the block explorer opened from the transaction. For a normal same-chain swap, all three should describe the same network. A crosschain swap deliberately uses two networks and must be diagnosed through its combined route rather than treated as an ordinary swap.

Keep the correct native token for network costs

Owning the token you want to sell is not enough. The wallet also needs the network’s required gas asset unless the specific flow clearly states another mechanism. Do not swap or transfer the entire gas balance if another approval, swap, cancellation or withdrawal will still be required.

Mistake 9: assuming a missing wallet balance means the swap failed

A wallet interface can hide an asset, fail to add a new token automatically or display a delayed balance. First check the swap transaction and token transfers on the correct explorer. If the swap succeeded, compare the received contract address with a verified official source, then use the wallet’s documented import or unhide function.

Never copy a contract from an unsolicited message. Attackers create tokens with the same name and ticker as established assets. The contract address, network and token details must all match. If the explorer shows only an approval, return to the official swap interface because the exchange itself was not completed.

Symptom Likely check Do not do this
Input balance unchanged Was only an approval confirmed? Assume the output token was lost.
Input decreased, output not visible Inspect token transfers, network and hidden assets. Import a contract from a direct message.
Balance appears on explorer but not wallet Add the verified contract or contact the wallet provider. Enter the seed phrase into a balance-recovery site.
Token appears unexpectedly Treat it as possible spam and research without interacting. Visit a URL embedded in its name or description.

Mistake 10: relying on a token name instead of its contract

Permissionless networks allow anyone to create a token. A familiar name, logo or ticker is not proof of identity or endorsement. Compare the contract with the project’s verified channels and the relevant explorer. Also confirm the network: a legitimate contract on one chain does not validate a similarly named contract elsewhere.

Uniswap may show token warnings for malicious, impersonator, spam, honeypot or high-fee indicators. Treat a warning as a reason to stop and investigate, not as an obstacle to dismiss. The absence of a warning is not a guarantee that a token is safe, valuable or sellable.

Mistake 11: repeatedly trying to sell an unsellable token

Some malicious tokens allow purchases but restrict sales through contract logic, extreme sell fees, allowlists or blocklists. These are often called honeypots. Repeated failed transactions can consume network fees without moving the token.

Stop when the interface predicts failure, displays a 100% sell-fee or honeypot warning, or repeated attempts revert for the same unfamiliar asset. Research the exact contract without connecting the wallet to unknown scanners. Do not approve a “token recovery” contract. If the wallet may be compromised, prioritize protecting unaffected assets using a carefully planned response.

Mistake 12: interacting with unexpected airdrops

Spam tokens and NFTs may include a website in their name or description. The displayed asset is designed to lead the user to a malicious claim or swap page. Receiving it does not mean the sender can automatically control the wallet, but signing the requested approval or transaction can create that access.

Do not visit embedded links, attempt to claim a reward or approve a contract simply to remove the asset. Hide it using the wallet’s display controls where appropriate. A legitimate support agent will not ask you to send the token somewhere or validate the wallet with a secret phrase.

Mistake 13: increasing slippage to solve every failure

Slippage is an execution boundary, not a universal repair tool. A swap can fail because of an expired deadline, insufficient gas balance, changed liquidity, token mechanics, allowance, wallet connection or network mismatch. Raising slippage may permit a worse trade without addressing the real cause.

Compare the new quote, price impact and minimum received. If the token is thinly traded, reducing the amount or not trading may be safer than accepting a large deviation. Detailed execution planning, MEV and limit-order choices belong to the separate advanced Uniswap guide; the troubleshooting rule is simply not to weaken a protection before understanding the error.

Mistake 14: ignoring price impact and token-specific fees

Price impact describes how the proposed order affects available pool pricing. It differs from slippage, which concerns movement between quote and execution. A small pool can produce severe price impact even when the transaction is technically valid.

Some tokens also change balances during transfers or charge buy and sell fees. These mechanics can make quotes unreliable or cause transactions to revert. A warning about high fees or expected failure should trigger research into the token contract, not a sequence of larger slippage settings.

Mistake 15: assuming every failed transaction is a Uniswap outage

A transaction passes through several layers: browser or app, wallet, RPC provider, blockchain network, token contract, router and liquidity pools. A problem in one layer can look like an interface failure. Determine where the process stopped.

  1. If no wallet prompt appeared, check the wallet connection, pending notification and browser state.
  2. If the wallet rejected simulation or estimation, read the reason before broadcasting.
  3. If a hash exists, move the investigation to the correct explorer.
  4. If the approval succeeded, determine whether the actual swap was submitted.
  5. If the swap reverted, review liquidity, allowance, token behaviour, deadline and gas conditions.
  6. If it succeeded, investigate network selection and token display rather than retrying.

Mistake 16: clearing or reinstalling the wallet too early

Clearing the Uniswap site cache or reconnecting the wallet can resolve an interface session problem, but deleting a wallet extension or resetting a device is much more serious. Do not remove wallet data until the recovery method has been verified offline and you understand which accounts it restores.

No troubleshooting article or support agent can recover a lost self-custody secret. Never test a recovery phrase on a website. If the wallet itself needs repair, follow the wallet provider’s official instructions and confirm backups before changing the installation.

Mistake 17: treating a crosschain route like one same-chain swap

A crosschain swap includes source and destination networks and can contain several coordinated steps. The source transaction may confirm while destination fulfillment is still processing. Switching the wallet to the destination chain and checking the expected output contract is therefore essential.

Use Uniswap’s combined activity details and any official route explorer offered there. If the interface presents a retry for a failed intermediate step, do not automatically restart the entire route. The separate Uniswap crosschain guide covers supported networks, Across and delivery troubleshooting in detail.

Mistake 18: accepting help from an impersonator

Users who publicly ask about a failed transaction often receive immediate direct messages from fake support accounts. The scammer may offer a validation page, remote-access session, QR code, special RPC, recovery contract or refund address. These are not legitimate troubleshooting requirements.

Uniswap’s official scam guidance says support will not ask for a recovery phrase, private key, password, remote access or a transfer of funds. Start from the official Help Center rather than a link sent in a reply. Public transaction hashes can be shared carefully; wallet secrets cannot.

Stop immediately if someone asks you to

  • Reveal or type a seed phrase, private key or wallet password.
  • Install screen-sharing or remote-control software.
  • Send funds to “synchronize,” “unlock” or “verify” the wallet.
  • Sign a message unrelated to the transaction being investigated.
  • Use an unknown bridge, approval checker or recovery website.
  • Continue the conversation only through Telegram, WhatsApp or a direct message.

A practical Uniswap troubleshooting workflow

Step 1: stop new requests

Do not press Swap, Approve or Sign again until you know whether an earlier request exists. Close unsolicited support conversations but keep the official wallet and explorer available.

Step 2: verify the environment

Confirm the official Uniswap domain, connected public address and selected network. Compare the input and output token contracts. If any fact differs from the intended trade, stop and document it.

Step 3: classify the last action

Was it a wallet connection, message signature, token approval, swap transaction or crosschain action? Look at wallet activity and transaction data rather than relying on memory or the button label alone.

Step 4: find every transaction hash

Open each hash in the correct network explorer. Put approvals and swaps in chronological order. A successful approval followed by no swap has a different solution from a confirmed swap with a hidden output token.

Step 5: read the onchain outcome

For pending activity, consider only wallet-supported replacement controls. For a revert, note the reason and compare current conditions. For success, inspect token transfers and balances. Do not create another swap until the first outcome is clear.

Step 6: correct one cause at a time

Switch to the correct account or network, restore sufficient gas balance, resolve an allowance issue or import the verified output token. Changing slippage, gas, network and amount simultaneously removes the evidence needed to know which correction mattered.

Step 7: review permissions after the incident

If an unfamiliar site or signature was involved, inspect token approvals on every relevant network. Revoke permissions that are no longer needed using verified tools, understanding that revocation costs gas. Consider moving unaffected assets to a new wallet if secret material was exposed.

Symptom-to-action reference

Symptom First check Safe next action
No wallet popup Wallet notification queue, connection and network Reconnect on the official interface or follow official wallet troubleshooting.
Approval keeps appearing Previous status, allowance, account and non-standard token behaviour Check allowance; revoke and reapprove only when justified.
Swap button appears again Wallet activity and transaction hash Determine whether the earlier request was broadcast before retrying.
Transaction remains pending Nonce and explorer fee status Wait or use the wallet’s documented Speed Up or Cancel control.
Transaction failed Error, allowance, gas, deadline, liquidity and token mechanics Correct the identified cause and obtain a fresh quote.
Token not visible Explorer transfers, selected network and hidden-token list Import only the verified contract through the wallet’s official flow.
Cannot sell an unfamiliar token Warnings, sell fee and exact contract Stop repeated attempts and investigate without signing anything.
Crosschain output delayed Combined route status and destination network Follow the offered intermediate-step retry rather than duplicating the route.

Pre-retry checklist

  • I am using the official Uniswap interface and intended wallet account.
  • The wallet, swap and explorer refer to the correct network.
  • I know whether the previous action was a signature, approval or swap.
  • I checked every existing transaction hash and its final status.
  • No earlier transaction is waiting behind a pending nonce.
  • The input and output token contract addresses are verified.
  • The wallet has enough native asset for the required network cost.
  • I understand the current quote, minimum received and price impact.
  • I have not widened slippage merely to bypass an unexplained error.
  • I am not interacting with an unexpected airdrop or warning-labelled token.
  • No one assisting me has requested secrets, remote access or a transfer.
  • I will submit only one new request and record its transaction hash.

Frequently asked questions

Why did I pay a network fee when my Uniswap swap failed?

The blockchain used computation to process the transaction before it reverted. The intended swap state change did not complete, but the network work was still performed, so the fee is generally not returned.

Why did I approve a token but receive nothing?

An approval only grants permission. Return to the verified interface after it confirms and review the actual swap request. Check activity to ensure you are not approving repeatedly instead of submitting the exchange.

Why is Uniswap asking me to approve the same token again?

The earlier approval may belong to another account, network or spender; the allowance may be too small; or the token may require an existing approval to be revoked before a new one. Inspect the confirmed allowance before authorizing another transaction.

Does disconnecting Uniswap revoke token access?

No. Disconnecting ends the interface connection but does not change an onchain allowance. Revocation is a separate onchain action and requires the appropriate network fee.

Can I cancel a pending Uniswap transaction?

Some wallets support a replacement transaction using the same nonce. A Cancel request is not guaranteed and may cost a network fee. Use the wallet’s official control and documentation rather than a third-party repair site.

Why are received tokens missing from my wallet?

You may have completed only an approval, selected the wrong network, received a token the wallet hides or need to import the verified contract. Use the correct explorer to confirm what happened before making another trade.

Should I increase slippage after a failed swap?

Not automatically. First identify whether the problem was slippage, gas balance, deadline, allowance, liquidity, token behaviour or network selection. A higher setting can permit a worse execution without fixing the cause.

Can Uniswap support recover a failed or mistaken transaction?

Confirmed blockchain transactions are generally irreversible, and support cannot take control of a self-custody wallet. Legitimate support can help explain an interface or transaction, but it does not need your seed phrase, private key, remote access or a payment to unlock funds.

Is a token safe if Uniswap does not show a warning?

No. Warnings are useful signals but are not exhaustive guarantees. Verify the contract, issuer, liquidity and token mechanics independently and avoid trading an asset you do not understand.

Final thoughts

The safest response to a Uniswap problem is methodical: stop, identify the account and network, classify the request, inspect the transaction hash and correct one known cause. Most damaging follow-up mistakes happen when a user confuses an approval with a swap, retries a pending transaction, imports an unverified token or trusts a stranger offering urgent recovery.

Keep enough native token for network costs, review allowances periodically and preserve a small record of important transaction hashes. Self-custody gives the wallet owner authority to act, but it also makes careful verification the most dependable troubleshooting tool.

Official Uniswap references

The following official Uniswap resources explain the transaction, approval and security behaviours used in this guide. Interface labels and supported features can change, so consult the current page when investigating a live problem.

Open Uniswap ↗Official website