When you interact with DeFi protocols — swapping tokens on Uniswap, depositing into a lending protocol, buying an NFT on OpenSea — you often sign an approval transaction first. This approval grants the protocol permission to access your tokens. Most users do this once and forget about it. What they don't realize is that the approval usually doesn't expire. It persists indefinitely, until you revoke it.
Revoking an approval means removing that permission. It doesn't undo anything you've already done — it just cancels the standing authorization for a contract to move your tokens going forward.
This matters because approvals accumulate. A wallet that's been active for a year in DeFi may have dozens of active approvals to dozens of different contracts. Each one represents a potential attack surface — if a protocol gets exploited, a malicious upgrade gets passed, or a contract turns predatory, any contract with an active approval over your wallet can access those tokens.
How Token Approvals Work
Most tokens on Ethereum and EVM-compatible chains follow the ERC-20 standard. Built into this standard is an approve function. When you call approve, you're setting a specific contract as an authorized spender for a specified amount of your tokens.
Here's what actually happens: You call approve(spenderAddress, amount) on the token contract. The token contract stores this authorization on-chain. The authorized contract can then call transferFrom on your behalf — up to the approved amount, at any point in the future — until you revoke it.
The classic example is a token swap. When you want to swap Token A for Token B on Uniswap, Uniswap doesn't take custody of your tokens directly. Instead, you first approve Uniswap's router contract to spend your Token A, then the swap contract pulls the tokens itself when the trade executes. This design keeps exchange logic separate from token logic — a reasonable architectural choice. But it creates a permission layer that most users never think about again after clicking "approve."
The Problem with Infinite Approvals
Many DeFi protocols request approval for the maximum possible token amount — effectively unlimited access. This is done for user convenience: approve once, interact freely forever. You'll often see this framed as saving on gas, so you don't have to approve every single transaction. That framing isn't wrong. But it's incomplete.
An infinite approval means the protocol can move your entire balance of that token at any time, subject to whatever logic lives in its smart contract. If that contract is later exploited, the attacker may be able to drain wallets that still have active approvals — even wallets that haven't touched the protocol in months or years.
This isn't theoretical. Several major DeFi exploits have included components where attackers leveraged existing approvals in wallets that hadn't been active for some time. The victim interacted with the protocol once, approved it, then moved on — and the exposure remained.
What Revoking Does — and Doesn't Do
Revoking an approval calls the same approve function with an amount of zero. This tells the token contract to set the authorized amount to 0, which cancels the permission. The contract can no longer call transferFrom on your behalf for that token.
It costs a small amount of gas — since you're writing a transaction to the blockchain — and is otherwise straightforward. You can always re-approve the contract later if you want to use it again.
Tools built specifically for this include Revoke.cash and Etherscan's Token Approval Checker. You connect your wallet, see a list of active approvals by contract and token, and revoke the ones you no longer want. Some wallets now include built-in revocation interfaces.
A few important limits:
- It only applies to future transfers. If a contract has already moved your tokens — legitimately through a swap, or maliciously through an exploit — revoking doesn't undo that. What's moved is gone.
- It's per-token, per-contract. Each approval is specific: Contract X is approved to spend Token Y. If you want to revoke Contract X's access to Token Y and Token Z, those are two separate revocations.
- NFT approvals work differently. ERC-721 and ERC-1155 tokens have their own approval mechanisms.
setApprovalForAllis particularly broad — it grants a contract permission over every NFT in a collection you own, not just a specific one.
Where the Friction Lives
Revoking costs gas. On Ethereum mainnet, that's real money during high-fee periods. On L2s, it's often cents. This is why many people let old approvals accumulate — the cost of cleanup doesn't feel worth it at any given moment. Whether that's reasonable depends on how much you have approved and how much you trust the contracts in question.
The other friction is visibility. Most wallets historically didn't surface your active approvals anywhere obvious. You'd have to know to look. That's slowly changing — Ledger, MetaMask, and others have added transaction simulation and approval visibility features. But full approval awareness isn't yet a default part of the wallet experience for most users.
What's Changing
Account abstraction (EIP-4337) introduces new patterns — session keys, per-transaction permission scoping — that could make the infinite-approval model obsolete over time. The idea is that a contract could be granted permission only for a specific transaction or session, then the permission expires automatically. But that's largely future state. Most DeFi today still runs on the classic ERC-20 approval model, and will for the foreseeable future.
Some protocols have shifted toward requesting exact-amount approvals by default — you approve the precise quantity needed for a specific transaction rather than an unlimited amount. This is a meaningful security improvement if adopted more widely. The tradeoff is gas and friction: you need to approve each transaction separately.
What Would Confirm Better Defaults
The clearest signal: protocols and wallets standardizing on exact-amount approvals rather than infinite ones as the default. If wallet UX increasingly enforces or recommends bounded approvals, that's a structural shift in how this risk is managed. Growing mainstream coverage of approval-related exploits — where the attack vector was a forgotten, standing permission from a previous interaction — would also accelerate that shift.
What Would Change This Picture
If the approval mechanism is redesigned at the token standard level — a future ERC that builds in automatic expiration or requires explicit confirmation per use — the standing-permission model becomes less relevant. That's theoretically possible but isn't near-term for established networks. More immediately: if gas costs on L1 fall substantially, routine revocation becomes cheap enough to treat as regular hygiene rather than an occasional project.
Timing Perspective
Now: If you've been active in DeFi for any meaningful period, you likely have active approvals from protocols you've stopped using. Checking and revoking unnecessary ones is low-urgency maintenance but real risk reduction. There's no emergency — but there's no reason to delay indefinitely either.
Next: Watch for wallet interfaces to surface approval management more prominently. This is already happening at the edges and will likely become standard.
Later: The approval model itself may evolve significantly as account abstraction matures. That's a multi-year shift, not something to plan around today.
What This Doesn't Cover
This is the mechanism explanation. It doesn't tell you which specific approvals to revoke — that depends on your situation, the protocols involved, and your own risk assessment. Revoking approvals reduces attack surface; it doesn't guarantee safety. A wallet can still be compromised through phishing, signing a malicious transaction directly, or any number of other vectors.
The tokens already moved aren't recoverable through revocation. And a wallet with zero active approvals can still lose funds. Approval management is one layer of wallet security, not the complete picture.
