Written September 6, 2026. A failed swap on a DEX, a bot or a terminal almost always has one of six causes, and five of them can be read off the error or the token page before you spend more gas. This page walks the causes in the order to check them, tells you which fix each one actually needs, and names the one mistake that turns a failed swap into a lost balance: raising slippage until it goes through.
Quick answer: Read the error first. "Insufficient output" or a slippage message means the price moved more than you allowed; re-quote, and only raise slippage if the pool is genuinely volatile. "Insufficient funds" or a gas error means you lack the chain's native token for gas, not the token you are swapping. A transfer or approval error on a token you already hold usually means the contract blocks or taxes sells, and no setting fixes that. If the same swap fails twice for a reason you cannot name, stop; every retry burns gas.
A swap that reverts still costs gas. Uniswap's own support pages on unsellable tokens make the point that repeated attempts simply consume more network fees, and on a chain where gas is cheap the temptation is to press the button ten times. Ten failures on a token whose contract will never let you sell is ten fees for nothing. Two failures is the number at which you stop and diagnose.
Check these in order
| What you see | What it means | The fix |
|---|---|---|
| "Insufficient output amount", "slippage exceeded", "price impact too high" | Between your quote and execution, the price moved by more than your slippage tolerance. Common in the first minutes of a launch and in thin pools. | Re-quote and try once more. If it fails again, the pool is moving faster than your tolerance; decide whether you want the worse price, and set slippage to that number deliberately, not to "whatever makes it go through". |
| "Insufficient funds for gas", "intrinsic gas too low", the button greyed out | You do not hold enough of the chain's native token (ETH on Robinhood Chain and other EVM layer-2s, SOL on Solana) to pay the fee. Holding USDC or the token you want to sell does not help. | Bridge or swap a small amount into the native token. Keep a reserve; on Robinhood Chain a few dollars covers many swaps. |
| "Transaction expected to fail", "execution reverted", a warning before you even sign | The wallet simulated the transaction and it reverted. On a sell, this is the honeypot signature: the contract blocks transfers, caps sells, or taxes them beyond what the router allows. | Do not sign. Check the contract on the explorer and the token card for sell tax, max-transaction limits and blacklists. If the contract will not let you sell, no setting will. |
| Approval succeeded, swap never happened | On EVM chains a first swap of a token is two transactions: approve the router to spend it, then swap. Only the first went through. | Check the explorer for the second transaction before doing anything. If it is missing, run the swap again; if it reverted, read its error. |
| "Deadline exceeded", stuck as pending for a long time | The transaction sat in the mempool past the swap's deadline, usually because the gas price you offered was below what the network was clearing. | Let it expire or speed it up from the wallet, then retry with the current gas price. Do not submit a second copy while the first is pending or you may get both. |
| Wrong token, wrong chain, "token not found" | The address you pasted is on a different chain from the one your wallet is set to, or it is a copy of the ticker you meant. | Switch the wallet to the chain the pair page shows, and compare the first and last four characters of the contract address with the pair page. Tickers repeat; addresses do not. |
What slippage is, and why raising it is not a fix
Slippage tolerance is the worst price you have told the router you will accept, expressed as a percentage below the quote. It is not a fee; if the price does not move, you pay nothing for it. It fails a swap when the pool moves against you by more than that percentage between quote and execution, which is the router protecting you from a fill you did not agree to.
Raising it therefore does one thing: it lets the swap fill at a worse price. Setting 20% to "make it go through" on a thin pool is agreeing to pay up to 20% more than the chart showed. On a memecoin launch that is routinely the difference between a trade and a donation, and it is also how sandwich bots profit: a high tolerance is an invitation to move the price into it. The right move is to re-quote, look at the price impact of your size on the pair page, and either accept a specific worse price or reduce size. The round-trip cost calculator shows what a given tolerance does to your break-even if it fills at the limit.
"I can buy but I cannot sell"
This is not a settings problem, and it is the case where the retry trap costs the most. A contract can allow buys and block sells by design: a transfer function that reverts for everyone but the deployer, a sell tax above what routers permit, a maximum transaction size set so low that any real sale fails, or a blacklist added after launch. Uniswap's support pages describe exactly this class of token and warn that continued attempts only burn fees.
What to do: open the contract on the explorer and read the token card in your bot or terminal. Look for sell tax, max-transaction or max-wallet limits, whether the contract is renounced, and whether it can be paused or blacklisted. Try a tiny sell, a few dollars, once. If that fails on a contract with any of those features, the position is what it is, and the useful lesson is the one in the meme coin research checklist: sell a small slice on any new token before sizing up, because a working exit today is the only evidence there is.
After a failed swap: the approval you left behind
If the approval transaction succeeded and the swap did not, the router still holds an allowance to spend that token from your wallet. That is harmless for a reputable router and dangerous for a contract you clicked on in a hurry. MetaMask's own support page is explicit that disconnecting a site "will not revoke any token approvals that you have in place with that dapp, meaning that even if you disconnect the dapp, it may still be able to access and move your tokens". Disconnecting and revoking are two different actions. Review approvals in the wallet's token settings or an allowance tool, and revoke the ones for contracts you do not recognise.
The same failures inside a bot or terminal
BasedBot, Axiom and their peers wrap the same router calls, so the causes are the same; the messages are shorter. "Insufficient gas" is the native-token problem. A swap that "failed" with no detail is usually a revert; the bot's token card will show the tax or restriction that caused it. A bridge that "completed" but left the balance unchanged is the wrong active chain, not a lost transfer. The BasedBot guide and the Axiom guide each have a troubleshooting table for their own messages, and the transfer-not-arrived page covers the case where the money, not the swap, is the problem.
Before you press retry
- Read the error text. It names the cause more often than not.
- Native token balance on the right chain for gas.
- Contract address matches the pair page, on the same chain.
- Re-quote; compare the new price to the old one before touching slippage.
- On a sell failure, check tax, limits and blacklist on the contract before anything else.
- Two failures for a reason you cannot name means stop, not try harder.
- Revoke the approval if the swap is not going to happen.
Join the Discussion