Lesson 4 — Token approvals: the silent attack surface
What a token approval actually is, how drainers exploit stale ones, and the 90-second weekly routine that closes the gap.
Token approvals are the single most common attack surface in DeFi-active wallets, and most users never look at them. An approval is permanent until revoked, scoped per token and per contract, and silently accumulates across every protocol you have ever touched. Today is about understanding what an approval is, why it matters, and the 90-second weekly routine that closes the gap.
An ERC-20 token approval is a smart-contract function call — `approve(spender, amount)` — that grants another address the right to move a specified amount of one of your tokens out of your wallet, without further confirmation. The standard was designed so DEXs and lending protocols can move tokens on your behalf when you trade or supply liquidity. The trade-off baked into the design: once an approval is set, the spender can move those tokens at any time in the future until you explicitly revoke it. ERC-721 (NFT) approvals work similarly, with a `setApprovalForAll(operator, true)` variant that grants control over your entire collection in one signature.
Wallet drainers exploit this by getting you to sign approvals you do not realise you are granting. The most common drainer flow: you click a 'free mint' or 'claim airdrop' button on a site you found via a paid Google ad or Discord DM, the site asks you to 'connect your wallet,' and the next pop-up asks you to sign a transaction that looks innocuous. What you are actually signing is `setApprovalForAll` or an `approve` with an unlimited amount. The site does nothing immediately — sometimes the drain happens hours or weeks later when a script sweeps approved accounts. Drainer-as-a-service kits packaged by criminal organisations have lowered the technical bar enough that this is now the highest-volume attack pattern in DeFi.
Equally dangerous is the EIP-2612 'Permit' signature. Permit moves approval off-chain: you sign a message rather than submit a transaction, and the spender can later submit the permit on-chain to gain approval. Because Permit signing looks like an innocuous wallet pop-up (no gas fee, no on-chain action) people sign them constantly. A malicious Permit can authorise unlimited spending from a token contract without ever showing up as an obvious 'approval transaction.' Treat any Permit message with the same scepticism as a transaction.
The defence is a weekly revoke routine that takes 90 seconds. Go to revoke.cash (bookmark it; never search for it). Connect a watch-only or read-only view of your active wallet if the tool supports it; otherwise connect normally but never sign anything during the visit unless you are deliberately revoking. Scan the list of active approvals. Revoke anything you do not currently use. Approvals you granted to a protocol you experimented with eight months ago are pure attack surface — there is no downside to revoking them; you can re-approve next time you actually use the protocol.
Transaction simulation tools are the second layer of defence. Tenderly, Pocket Universe, and Rabby (a wallet that simulates by default) all show you what a transaction will actually do — token balance changes, approvals granted, contracts called — before you sign. For unfamiliar contracts, simulating before signing closes most of the remaining gap. Make simulation a habit for any signature on a site you have not used before.
Example
In 2024 a series of high-profile drainer incidents associated with the 'Inferno Drainer' and 'MS Drainer' kits collectively drained over $80 million across thousands of victims, according to incident write-ups from on-chain analytics firms. The mechanic in nearly every case was a Permit or setApprovalForAll signature obtained through a fake airdrop page. The mitigating action — revoke.cash review and refusal to sign unfamiliar Permit messages — would have prevented the loss for every affected user with non-trivial approvals beforehand.
Common mistakes
- Treating Permit signatures as harmless because they do not cost gas. They are approvals.
- Approving the maximum (`uint256` max) when supplying liquidity, then never revoking even years later.
- Searching for 'revoke crypto approvals' on Google — fake revoke.cash clones in paid Google ads are an active scam. Bookmark the real site.
- Skipping the revoke step when you stop using a protocol. Closing a position does not revoke the approval; that requires a separate transaction.
- Signing without simulating on a contract you have not interacted with before. The wallet UI is not enough; it shows the call data, not what it will do.
Safety warning
If you suspect you may have signed a malicious approval — for instance, you connected a wallet on a site you later realised was fake — open revoke.cash from your bookmark immediately and revoke every recent approval, even if the wallet has not yet been drained. Drainer scripts often run on a delay. Speed of revocation directly determines whether you keep your funds.
Check your understanding
You used a DEX once six months ago. You no longer use it. What is the safest thing to do about the unlimited USDC approval you granted at that time?
Key terms covered
Sources & further reading
- PrimaryEIP-20: ERC-20 Token Standard
The canonical specification for `approve()` and the rest of the ERC-20 interface.
- PrimaryEIP-2612: Permit – 712-signed approvals
Specification for the off-chain signed-approval mechanism used in many drainer attacks.
- Secondaryrevoke.cash documentation
Reference for the approval surface across major chains, with up-to-date drainer write-ups.
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.