What a token approval is
ERC-20 tokens do not move themselves. The token lives as a balance inside its own contract, and that contract only lets an address move tokens it has been told to trust. So before a swap contract can pull your USDC or LINK into a trade, you have to sign a separate transaction that says, in effect, this router is allowed to move up to this amount of this token for me.
That authorization is the approval. It is a real transaction, so it costs gas of its own, and it is distinct from the swap itself. A single swap of an ERC-20 you've never traded from a given wallet therefore involves two steps: approve first, then swap.
Why the step exists at all
The two-step model is a safety boundary. Instead of every contract having open access to every token in your wallet, you grant access deliberately, per token, per spender. It's the reason a malicious contract can't silently drain a token you never approved it to touch, and it's why reviewing what you approve matters.
Why an approval fails
Approvals fail for a short list of reasons, and most of them clear on a retry once you know what to look for.
- Not enough native gas to pay for the approval transaction itself, since the approval is its own on-chain action.
- The approved amount was smaller than the swap needs, so the router isn't cleared to move the full trade size.
- The approval transaction was submitted but never confirmed, for example it was dropped or stuck at too low a fee.
- A stale or partial approval from an earlier attempt is in the way, and some tokens require the old allowance to be reset before a new one is set.
- Wallet or network hiccups: a rejected signature, a chain switch mid-flow, or a nonce conflict from a pending transaction.
The fix, step by step
Work through it in order. First, confirm you hold a little of the network's native token for gas, because the approval cannot be signed without it. Second, approve the token for at least the amount you intend to swap, and wait for that approval to confirm on-chain before you start the swap. Rushing the swap before the approval settles is a common cause of a second failure.
If a stale approval is the blocker, reset it. Many wallets and allowance tools let you set the allowance back to zero and then approve fresh, which satisfies tokens that refuse a direct increase from a non-zero value. Once a clean approval confirms, the swap should proceed on the next attempt without further prompts.
Allowance hygiene and revoking
An approval doesn't expire on its own. If you approved an unlimited amount to a contract once, that standing allowance sits there until you change it. That's convenient for a router you use often and a liability for one you don't, since anything with a live allowance can move that token if it's ever compromised.
Good practice is to keep only the allowances you actively use and revoke the rest. Allowance-management tools and most modern wallets show what each of your tokens is approved to, and let you set any of them back to zero. Revoking is itself a transaction that costs gas, so batch it into a cleanup rather than doing it constantly.
- Approve amounts you're comfortable with, and treat unlimited approvals as a deliberate choice, not a default.
- Review standing allowances periodically and revoke ones you no longer need.
- A fresh, exact-size approval before a one-off swap is the most conservative option.
Native assets skip this entirely
Approvals apply to tokens, not to the network's own coin. A swap that starts from ETH on Ethereum, or from BNB on BNB Chain, needs no approval, because the network already knows how to move its native asset. That's why a swap from ETH goes straight through while a swap from USDC asks you to approve first.
So if you keep hitting approval steps, it's a sign you're swapping from a token rather than a native coin. That's expected behavior, not a bug, and the two-step flow is the token model working as intended.