How to Revoke Token Approvals and Why You Should

What a token approval actually is

When you swap a token on Uniswap, lend ETH on Aave, or bridge USDC across chains, you do not actually hand your tokens to the protocol. You sign a small on-chain message that says: "smart contract X is allowed to pull up to N of token Y from my wallet." That signed permission is called an ERC-20 approval, and it lives on-chain forever unless you, or the contract itself, cancel it.

The reason approvals exist is technical. ERC-20 tokens are dumb bearer-style assets: they have no concept of "Alice lending Bob 100 USDC." They only understand balances and allowances. To let a third-party contract, like a DEX router or a lending pool, move your tokens for you, that contract has to be granted an allowance, which is set with two functions: approve and increaseAllowance.

Most protocols ask for the maximum possible value, the largest 256-bit unsigned integer (2^256 minus 1), because it spares them from asking you to sign a fresh approval every single time you interact. From a UX perspective, infinite approvals are convenient. From a security perspective, they create a permission you may forget you ever granted.

Why infinite approvals are dangerous

An infinite approval is not "infinite risk" on its own. It is only as dangerous as the contract holding the allowance. If the protocol you approved is well-audited, time-tested, and still operated by the same team, the approval is roughly as safe as the protocol itself. The danger shows up in three specific situations, and they are common enough to take seriously.

First, protocols get hacked. A smart contract can be exploited through a logic bug, a price oracle manipulation, or a governance attack. If the attacker can call transferFrom against a list of approved users, an infinite approval turns a protocol bug into a direct drain of your tokens. This is not hypothetical: a number of well-known DeFi incidents over the past several years included token-draining paths that piggybacked on standing allowances.

Second, projects get abandoned, then re-deployed by someone else under the same name or at the same address. Once a team walks away from a contract, the bytecode sitting at that address is just code. If a new owner or upgrade mechanism lets an attacker become the admin, your old approval now points at a hostile entity.

Third, and this is the one most users underestimate, wallet drainer kits actively filter for wallets with leftover approvals. When you sign a malicious signature on a phishing site, the kit does not just steal the one token on the page; it loops through every active allowance your wallet has ever granted and pulls each one. The damage from a single phishing click scales with how much old surface area you have. Fewer open approvals means a smaller blast radius.

Which approvals are actually safe to keep

Not every approval is a ticking bomb, and chasing zero approvals is both impractical and pointless. The goal is to shrink your attack surface, not to nuke your wallet's ability to function. A reasonable rule of thumb has three tiers.

Keep approvals to contracts you actively use, that are run by reputable teams, that have been audited, and that have not been recently exploited. If you still use Aave or Uniswap weekly, the approval those front-ends manage is part of how the system works. Revoking it just means re-signing next time you transact, which costs gas and a small amount of attention.

Reduce infinite approvals on contracts you use rarely. Modern wallets such as Rabby, Frame, and the updated MetaMask flow default to a finite allowance based on the transaction amount. If a contract you touched once still has an infinite approval from two years ago, drop it to zero or to a small finite amount.

Revoke approvals to anything you do not recognize, anything that shows a name you have never heard of, and especially anything where the contract is unverified on Etherscan. Unverified contracts with active allowances are the single most common pattern that drainer kits exploit.

How to find every approval your wallet has granted

There are two tools worth trusting for this job, and they cover almost every EVM chain in active use. The first is Revoke.cash, an open-source dApp built specifically for allowance management. You connect your wallet, it scans the chain, and it lists every contract that currently has a non-zero allowance over your tokens, grouped by token. Each row shows the spender, the current allowance, and a direct link to the on-chain revoke transaction.

The second is the Etherscan token approval checker, available on Etherscan for Ethereum and on the equivalent block explorers for chains like BNB Chain, Polygon, Arbitrum, Optimism, and Base. You paste your wallet address, hit the approval tab, and you see the same data with a slightly more technical interface. Etherscan is useful as a cross-check because Revoke.cash occasionally misses allowances on newer or less common tokens.

Whichever tool you use, the workflow is the same. Read each spender. If you do not recognize it, mark it for revocation. If you do recognize it, decide whether you still need it and whether you want to leave it infinite. Note that revoking is a write transaction: it costs gas, so do it in batches on a low-fee time rather than one at a time during peak hours.

How to revoke token approvals step by step

Here is the practical workflow that experienced DeFi users actually follow. It assumes you are using a self-custody wallet such as Rabby, MetaMask, Frame, or Ledger Live and that you have a small amount of ETH on the chain you are cleaning up, enough to cover gas.

Open Revoke.cash in your browser. Connect the wallet you want to audit. The site will default to Ethereum mainnet; if your approvals are on another EVM chain such as Arbitrum, Polygon, or BNB Chain, switch the network selector at the top of the page. The site will then pull every token you hold and every active allowance in one pass.

Read through the list. For each spender you do not recognize, or any spender you no longer want to trust with a standing allowance, click the revoke button next to it. Your wallet will pop up a transaction request that sets the allowance to zero. Confirm it and pay the gas fee.

For approvals you want to keep but want to shrink, Revoke.cash lets you set a custom value rather than zero. A common pattern is to set the allowance to the exact amount needed for the next transaction, which modern wallets can fill in for you automatically. After your revoke transactions confirm, refresh the page and confirm that the allowance now reads zero or the new finite value.

Repeat for any other chains where you have done meaningful DeFi activity. Many users are shocked to find approvals on chains they used once for an airdrop and forgot about. Each chain needs its own pass, since allowances are not cross-chain by default.

How to set finite approvals going forward

The single best habit you can build after cleaning up your wallet is to stop signing infinite approvals in the first place. The defense is built into most modern wallet UIs, but you have to notice it.

When a dApp asks for an allowance, look at the value. If the default is the maximum 256-bit number, your wallet is offering the legacy infinite path. If the default is the exact amount of the swap or the deposit, your wallet is offering a finite approval. Rabby and Frame both default to finite for known contracts. MetaMask has shifted toward finite defaults in its newer versions, though older flows still expose the legacy option.

If a contract demands an infinite approval and offers no finite option, treat that as a yellow flag. Some contracts genuinely need a standing allowance, such as DEX aggregators that route through multiple pools, but most do not. When in doubt, approve the exact amount for the transaction you are about to do, and revoke or shrink the allowance as soon as the action completes.

Another practical habit is to use a separate "hot" wallet for high-risk activities such as airdrop farming, testnet interactions, and signing unfamiliar dApps, and a separate "cold" wallet for long-term holdings and large DeFi positions. The hot wallet takes the phishing clicks; the cold wallet only interacts with audited, well-known protocols. Even if a drainer kit sweeps your hot wallet, your main stack is on a wallet with a much smaller approval footprint.

What this looks like when something goes wrong

It is worth being concrete about what a drain looks like in practice, because the fear of "my approvals will be exploited" is sometimes treated as abstract. Imagine you signed an infinite approval for USDT to a small DEX router eighteen months ago. The DEX shut down, the team moved on, and the contract address was later taken over by a different deployer.

Six months after that, you visit a familiar-looking site, click what you think is a routine approval, and you actually sign a malicious permit or off-chain authorization. The drainer kit sees that your wallet still has an infinite allowance to that router. In a single transaction, it calls transferFrom and pulls your entire USDT balance. The transaction is valid, the allowance was real, and there is no rollback.

Now imagine the same wallet, but you revoked the USDT allowance to that router six months earlier and replaced it with a zero. The drainer kit scans your wallet, finds nothing to pull for that token, and moves on. The cost of the original revoke was a few cents of gas; the cost of not revoking was your full USDT balance. The math is not subtle.

How to follow approval risk the smart way

Approval hygiene is one of the few areas of crypto security where the user actually has direct control, but it is easy to forget once your wallet is "working." Zippfeed tracks token-approval-related news, including protocol exploits, drainer kit campaigns, and wallet security updates, with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can spot new attack patterns before they reach your inbox instead of after they reach your wallet.