Token Approvals: The Quiet Way Wallets Get Drained

When a wallet is emptied on Ethereum or another EVM chain, the private key has usually not been stolen. Something more ordinary happened: the owner granted a contract permission to move their tokens, and that permission was still valid weeks or years later when someone decided to use it.

Understanding approvals is the difference between using decentralised applications safely and using them hopefully. The mechanism is simple, the default settings are dangerous, and the fix takes ten minutes.

What an approval actually is

Token standards on EVM chains do not let a contract take your tokens directly. Instead, you call the token's approve function, naming a spender contract and an amount. From then on, that contract may transfer up to that amount from your wallet, at any time, without asking again.

This is what makes trading on a decentralised exchange possible: the router needs permission to move the token you are selling. The problem is not the mechanism, it is the amount and the duration. Many interfaces request an effectively unlimited allowance, because it saves the user a transaction on every subsequent trade — and that allowance does not expire.

Why this is the attacker's favourite tool

An approval signature often costs no gas, produces no visible change in your balance, and looks identical to the confirmations you approve routinely. A malicious site does not need to steal anything at the moment you interact with it. It needs one signature, and patience.

The drain then happens at a time of the attacker's choosing — frequently long after you have forgotten the site existed, which is why victims so often report that they "did not do anything" that day. They did not. They did something months earlier.

Permit signatures: the version with no transaction at all

Newer token standards support gasless approvals, where you sign a structured message rather than send a transaction. The user experience is better and the risk profile is worse: there is no pending transaction to inspect, no gas prompt to give you pause, and the signature can grant a spender the same powers.

Treat any request to sign a message you cannot read as equivalent to handing over the tokens it names. A wallet that decodes these into plain language before signing is doing the single most valuable safety job available — the capability we weight most heavily in our self-custody wallet table.

How to audit what you have already granted

Every approval you have ever made is public, because it was an on-chain transaction. Several tools list them per address and let you revoke in one click, and most block explorers include an approval checker.

• Go through every address you use, not just the main one — the forgotten wallet is where old approvals accumulate.
• Revoke anything you no longer use, and anything granted to a site you cannot identify.
• Reduce unlimited allowances on contracts you do use to an amount you would be comfortable losing.
• Repeat quarterly. Approvals accumulate silently and there is no notification when one is used.

Revoking costs a small amount of gas per token per contract, which is why people put it off. Price that against the balance the approval covers and it is the cheapest insurance available on-chain.

The structural fix: separate addresses

Auditing helps. Architecture helps more. Keep long-term holdings in an address that has never interacted with a decentralised application, and do all on-chain activity from a separate wallet holding only what you are actively using.

Then an approval mistake costs you the contents of the spending wallet rather than your savings. This is the same split described in our crypto security guide, and it is the single most effective change most people can make.

If you think you already signed something bad

Speed matters more than diagnosis. Move any remaining balance to a fresh wallet first, before working out what happened — an approval you have not identified is still live while you investigate, and attackers frequently drain in stages rather than all at once.

Then revoke every approval on the compromised address, including tokens you no longer hold, because an allowance persists for future deposits. Treat that address as burned for anything valuable: if the key itself was exposed rather than just an approval, revocation does nothing at all, and there is no way to tell the two apart from the outside.

Finally, reconstruct the sequence from the block explorer. Every approval and transfer is public and timestamped, which usually makes the entry point obvious — and knowing which site it was tells you what else you may have connected with the same wallet.

What good practice looks like

• Use a wallet that simulates transactions and shows resulting balance changes before you sign.
• Edit unlimited approvals down to the amount you are actually trading, where the interface allows it.
• Sign from a hardware device for anything meaningful, and read the decoded details on its screen.
• Keep savings in an address that never connects to anything, as covered in custodial vs non-custodial wallets.
• Run a revocation pass every quarter, across every address.

None of this makes decentralised applications risk-free. It moves the worst case from "everything I own" to "what was in the hot wallet", which is the distinction that decides whether a bad signature is an annoyance or a catastrophe.

One last point worth internalising: an approval is not a payment and produces no immediate change you can see, so there is no moment where your balance visibly drops and prompts you to investigate. The absence of feedback is precisely what lets a hostile allowance sit undisturbed for a year. Assume nothing will alert you, and put the quarterly audit in a calendar where you will actually see it.