Checking and Revoking Token Approvals: The Complete Guide

What a token approval actually is

On a chain like Ethereum, tokens such as USDT and USDC are each their own contract keeping its own ledger. When you want to swap USDT for ETH on a DEX like Uniswap, you hit a wall — Uniswap's contract can't just pull USDT out of your account, because it doesn't have permission to.

So the ERC-20 standard splits the action in two. First you call the token contract's approve(spender, amount), which tells the USDT contract "I allow this Uniswap address to move up to this much USDT from my account." Then, when Uniswap runs the swap, it calls transferFrom to pull the tokens. The first step is the approval; the second is the actual spend.

This mechanism is what makes the whole of DeFi work — DEX swaps, lending deposits, bridging tokens across chains, nearly all of it involves an approve somewhere underneath. The trouble lives in two places: the amount of the approval and its lifespan. Nobody forces you to think about either, and the wallet default usually makes the laziest, most dangerous choice on your behalf.

Why unlimited approvals are the biggest back door

When most dApps pop up an approve request, the amount they pre-fill isn't "the small amount you're swapping right now" — it's the maximum value of a uint256, which is effectively unlimited. The reasoning is practical: approve an unlimited amount once and you never have to sign another approve for that token, so the UX stays smooth. The price is that you've handed the spender contract control over your entire balance of that token, plus anything you ever send in later.

The bigger problem is the lifespan — the approval never expires on its own. An unlimited approval you gave some protocol three years ago for a single swap is still live today. The day that contract gets compromised, or if it was a phishing contract waiting all along, the attacker just calls transferFrom once and your balance of that token is gone in a single move — no private key needed, no extra signature needed, because you already signed it long ago.

What scammers are really after: your approvals

Once you understand the approval mechanism, a huge category of wallet scams suddenly makes sense: they're not after your private key, they're tricking you into signing an approval or an equivalent signature. It's also why "I never told anyone my seed phrase, so how did I lose funds?" happens — you didn't leak the seed, you just signed the wrong approval once. We've broken down several real cases on this site, and the bait is always this same approval step:

• A fake airdrop that lures you into signing a setApprovalForAll phishing trap — an NFT "approve all" switch that, once signed, hands an entire collection over to the attacker.
• A page dressed up as a legit DEX hiding an EIP-2612 Permit fake swap — you think you're signing a routine swap, but you're actually signing an off-chain approval.
• A Blur bid permit trap bolted onto an NFT marketplace's offer flow — a harmless-looking "listing signature" that quietly walks off with an approval.
• A Permit2 fake signature impersonating Uniswap — aimed squarely at the Permit2 mechanism we cover below.

What these cases share is the moment of signing: the popup is either incomprehensible hex, or it's been carefully wrapped to look like a "normal action." Defending against them isn't just "don't click random things" — it's understanding what you're approving, and clearing out the approvals you no longer need afterward. We covered the first half — how to turn on signature decoding — in MetaMask Security Settings for Daily Use; the checking and revoking is what this guide is about.

Step one · finding your existing approvals

You can't list your approvals from memory — for anyone who's been active a year or two, the list is usually frighteningly long. The good news is that approvals are public on-chain data, so anyone can look them up. Three kinds of tools come up most often:

Block-explorer approval checkers

On Ethereum you use Etherscan; on BNB Chain, BscScan. Both ship a built-in Token Approval Checker (the address looks like etherscan.io/tokenapprovalchecker). Paste in your address and it lists every ERC-20 / ERC-721 approval that address has issued: who the spender is, how much the allowance is, which token it's for. Unlimited approvals get flagged as Unlimited, so they're easy to spot at a glance.

This is the most authoritative source — the data comes straight from the chain itself. The catch is that it's per-chain: Etherscan only sees Ethereum mainnet, so your approvals on Arbitrum, Optimism, or Base have to be checked on their respective explorers. Walk every chain you've used individually; don't check mainnet and assume you're clean.

Aggregators like revoke.cash

revoke.cash is the most widely used third-party tool in this space, pulling approvals across multiple chains into one interface: connect your wallet or paste an address and it pulls your full set of approvals across chains, sorted by amount and last-used date, flagging unlimited allowances and ones you haven't touched in ages. You can even fire off the revocation right there, without jumping back to an explorer to call the contract by hand.

The wallet's built-in approval manager

Plenty of wallets now ship their own approval panel. MetaMask, in versions after 11.x, lets you see some approvals from a token's detail view or the security menu and revoke them directly; several mobile wallets tucked a similar entry under "Settings / Security." The built-in tools win on not having to leave the wallet, but they often cover fewer chains and tokens than the dedicated ones. My own routine is to glance at the built-in panel day to day, and cross-check with an explorer plus revoke.cash during a periodic deep clean.

Step two · how to revoke

First, get this straight: revoking is also an on-chain transaction, and it costs gas. It isn't a setting you toggle on a website — it's a real transaction sent to the chain that rewrites the allowance recorded in the token contract. So before you revoke, make sure the wallet holds a little of the chain's native coin (ETH, BNB, and so on) to cover the fee. Using revoke.cash as the example — the flow is much the same across tools:

1. Connect your wallet, and confirm the network shown in the top-right is the chain whose approvals you want to clean. To clear several chains, switch networks and handle each one in turn.
2. Pick the spenders to revoke from the list. Prioritise three kinds: anything with an Unlimited allowance, anything last used a very long time ago, and any contract whose name you don't even recognise.
3. Click Revoke, and the wallet pops up a transaction request. This is where you sign — read what it's about to do before you sign. A normal revoke sets the allowance to 0, or flips setApprovalForAll back to false.
4. Pay gas and wait for confirmation. Once the transaction lands on-chain, that approval is dead.

Be clear on the two kinds of approval and how each is revoked. An ERC-20 approval (USDT, USDC, and the like) is an amount, so revoking means setting the amount to 0 — though you can also leave it at a small, sufficient amount instead of going all the way to zero. ERC-721 / ERC-1155 (NFTs) usually rely on setApprovalForAll, which is a switch: all-on or all-off, with no "dial it down" middle ground. Revoking means flipping that boolean back to false.

What's special about Permit and Permit2

The approve above is an on-chain approval — it's a transaction in its own right, recorded in your history, so it's findable. But Permit (EIP-2612) and Uniswap's Permit2, which have become popular in recent years, are off-chain signed approvals, and that makes auditing trickier.

Permit was designed to save gas: instead of sending a separate approve transaction, you sign an approval message off-chain and submit that signature alongside the action, merging the approval and the use into one step. The downside is that this signature doesn't necessarily leave a standalone approve record on-chain, so you might see nothing in your transaction history about what you approved. Scammers exploit exactly this, dressing a malicious approval up as one harmless signature.

Permit2 is Uniswap's unified approval contract. The logic: you make one on-chain approve (often unlimited) to the single Permit2 contract, and from then on every app that uses Permit2 requests an allowance from it via off-chain signature, with Permit2 moving your tokens on their behalf. This centralises approval management in one place, but it also means the Permit2 contract itself holds a big permission over your tokens.

The way to audit Permit2:

• First, check which ERC-20 approves you've granted to the Permit2 contract address itself — those are on-chain records, findable on an explorer or revoke.cash.
• Then check the allowances Permit2 has granted internally: tools like revoke.cash can already read Permit2's internal approval relationships, showing which apps it has sub-delegated to, for how much, and when they expire.
• Permit2's sub-approvals can carry an expiry, but plenty of defaults are still set very long. Go in periodically and clear out the sub-approvals you no longer use, along with overly long expiries.

Best practice · keeping the exposure minimal

Checking and revoking are after-the-fact fixes; what really saves you grief is not spreading your exposure so wide in the first place. A few rules I always keep:

• Revoke when you're done. Try a new protocol or do a one-off mint, then revoke the approval as soon as you're finished — close the door the moment the trade is done.
• Don't grant unlimited. If the approve popup lets you edit the amount, give only what this transaction needs. Most major wallets and dApps now support a custom amount.
• Audit regularly. Set yourself a rhythm — say, sweep across chains with revoke.cash every quarter and clear the unlimited, the long-unused, and the unrecognised.
• Keep large funds in a separate wallet that never connects to dApps. This is the most effective physical isolation: park your main assets on an address that connects to nothing, and use another, small-balance "front-line" address for day-to-day interaction — if the front line gets phished, the main stash is untouched. For layering across addresses, see the complete wallet guide.
• Read it before you sign. The last line of every defence is the three seconds before you sign — understanding the spender and the amount beats any tool.

Cost and a few common myths

There are a few misconceptions about revoking worth clearing up, so you don't panic or relax for the wrong reasons.

Myth one: revoking is free. Wrong — it's an on-chain transaction and you pay gas. So there's no need to revoke every approval in your history. Prioritise the unlimited ones, the ones you no longer use, and the ones of unknown origin; a small allowance to a trusted protocol you use often can stay, sparing you the gas of re-approving repeatedly.

Myth two: having an approval = already being robbed. Wrong. An approval only means the spender could move your tokens; it doesn't mean they have been. Turning up a pile of unlimited approvals isn't cause to scare yourself — sort by risk and start revoking from the most dangerous. Something actually goes wrong only if that contract is malicious or compromised.

Myth three: revoke once and you're done forever. Wrong. A revoke only applies to that one grant — next time you use the same protocol it'll ask you to approve again, which is normal; just grant a sufficient amount as needed. Revoking isn't "blocking," it's "taking back this one key."

Myth four: switch wallet apps and the old approvals are gone. Wrong. An approval is bound to the address, not to whichever app you open it with. As long as the old address still holds tokens, those approvals are still live and still a risk — you have to connect in and revoke. If the old address is fully emptied and no longer in use, you can leave it, but the safer move is to retire it and never send any assets to it again.

Which brings us to an angle you can't dodge: all this checking, revoking, and auditing hassle is, at root, the cost of self-custody — you manage your own keys, so you manage your own approvals. If part of your assets is just there to hold long-term, with no plan for frequent on-chain interaction, then keeping it on a centralised exchange like Binance means approvals simply don't exist: the platform custodies it for you, and you won't lose funds to one wrong approval (the trade-off is trusting the platform itself). Self-custody and custody each have their trade-offs, and splitting funds by purpose is the realistic call — something we also unpack in cold wallet vs hot wallet.

One last thing

Token approvals are the plumbing underneath DeFi — used well, they make everything smooth; neglected, they become an unlocked door on your wallet. This guide really comes down to three things: know what an approval is, check what you've granted on a regular basis, and revoke the excess and the dangerous. Plus one habit running through all of it — read what you're approving before you sign.

Take ten minutes today and sweep your everyday address with revoke.cash. Odds are you'll turn up a few unlimited approvals you'd long forgotten — revoke them, and you may have just blocked a future loss you'll never even know about.

Interfaces and tools change fast. If anything in this guide doesn't match what you see, tell us — we log it on the corrections page. Approval disasters usually come with a tricked signature, so it's worth reading MetaMask Security Settings alongside this: that one covers "how to read it before you sign," and this one covers "how to take it back after" — two defences, one before and one after.