Token Approvals Explained: What You're Really Signing Before a Swap

There's a moment that confuses almost everyone on their first ERC-20 swap: the wallet pops up twice. You confirm something called an approval, wait for it to land, then confirm again to actually trade. It reads like a bug, or a toll. It's neither. It's the token contract asking whether you really want to let a piece of software move your money.

That first signature is a token approval, and it is the most under-read transaction in crypto. It's also the one most likely to cause damage months later, long after the swap it was created for has been forgotten.

An approval edits the token, not the app

ERC-20 tokens don't sit inside your wallet the way people picture. Your balance is a row in the token contract's own ledger, and your address is the key to that row. When a router needs to move those tokens on your behalf, it can't simply reach in and take them — it has to appear in a second ledger, the allowance, which records how much of your balance a specific address is permitted to move.

So approve(spender, amount) is a write to the token contract, not to the app you're using. You are editing USDC's records to say: this address may move up to this much of my balance, from now until I say otherwise. The swap transaction then spends against that allowance.

This is also why native assets skip the step. ETH on Ethereum, BNB on BNB Chain, POL on Polygon — those move with the transaction itself rather than through a ledger entry, so there's nothing to permit in advance. If you've ever wondered why ETH → USDC is one signature and USDC → ETH is two, that's the entire answer.

Unlimited approvals: convenience with a very long tail

Most interfaces offer, and many quietly default to, an unlimited allowance — usually the largest number a uint256 can hold. The pitch is reasonable: approve once, and never pay approval gas for that token and that router again.

The cost is that the permission never expires and never shrinks. You are not really deciding whether you trust a contract today; you're deciding whether you'll still trust it in eighteen months, after an upgrade you didn't read about, with a balance you haven't got yet. Almost every large approval-related loss has this shape — the allowance was granted for one small trade and was still sitting there, wide open, when something went wrong much later.

The alternative is approving only what the trade needs. That costs an approval transaction every time, which on Ethereum mainnet is a real expense worth weighing. On an L2 it's rounding error — a good argument for being stricter about approvals on cheap chains than most people bother to be. If you're curious why the same transaction costs so differently across networks, that's the gas story.

Permit and Permit2: permissions that expire

The approval model dates to 2015 and it shows. Two newer patterns fix the worst of it. EIP-2612 permit lets you sign an offchain message instead of sending a transaction; the permission is carried inside the swap itself and consumed with it. Permit2 generalizes the idea to tokens that don't implement permit natively, and adds something the original standard never had: an expiry.

That second part matters more than the gas saving. A permission with a deadline is a permission that cleans itself up. If a flow offers you a signature instead of a transaction, it's usually one of these — which also means the signature request is doing real work, so read it rather than reflex-clicking it.

Auditing what you've already handed out

If you've been swapping for a year or two across a few chains, you almost certainly have dozens of live allowances, and a handful of them are unlimited grants to contracts you can no longer name. Cleaning that up takes about twenty minutes.

1. 1Pull the list. Block explorers have approval checkers — Etherscan for Ethereum, and the equivalents on each chain you've used. Tools like revoke.cash cover many chains in one view, which saves a lot of tab juggling.
2. 2Sort by what's actually at risk. An allowance only matters up to the balance you hold. An unlimited approval on a token you own four dollars of is not the emergency; a large allowance on your main stablecoin is.
3. 3Kill anything you can't identify. Protocols you tried once, a mint from a chain you haven't opened since last cycle, anything you don't remember granting. There is no downside to revoking — if you use the app again, it will simply ask you to approve again.
4. 4Revoke by setting the allowance to zero. That's a transaction, so it costs gas, once per token-and-spender pair. Batch the cleanup on a quiet day rather than mid-swap.

The failure mode that actually drains wallets

People picture approval risk as "the protocol got hacked." That happens. The more common version is duller and far more preventable: you followed a link, a site asked for an approval, and you signed it without reading who the spender was.

Approval phishing doesn't need your seed phrase and doesn't look dramatic. The prompt is the same call you make on every legitimate swap, which is exactly what makes it work. The only things separating the two are whether you navigated to the site yourself and which address you're about to empower.

• Go to apps directly. Bookmarks, not search ads, not links from a DM about an airdrop.
• Read the spender. Your wallet shows the address requesting the allowance. If you weren't expecting to approve anything, that's the moment to stop.
• Be suspicious of approvals for tokens you weren't trading. A site asking for permission over an asset that has nothing to do with what you're doing is the loudest signal you'll ever get.
• Split your wallets. A hot wallet with a working balance that does the daily swapping, and a wallet that has never signed an approval in its life. This one habit outperforms every other item on the list.

An approval is not part of a trade. It's a permission that outlives the trade — and it will still be there long after you've forgotten why you granted it.

What we do about it, and what's still on you

When you swap on SwapRoute, the approval you're asked for is scoped to the amount of the trade you're making rather than to infinity, and if your existing allowance already covers the trade, you won't be asked at all — you'll just sign the swap. That's a deliberate default: the marginal gas cost of an exact approval is small, and standing permissions are the part of this that ages badly.

What we can't do is audit the allowances you granted elsewhere. That part is genuinely yours, and it's the highest-leverage twenty minutes of maintenance in self-custody. Do it once, put a reminder six months out, and the whole category of risk mostly stops being one.