Token Approvals: How Allowances Drain Wallets

To let a decentralised exchange swap your tokens, you first grant it permission to move them. That grant is a separate transaction from the swap, it persists after the swap completes, and by convention it is usually for an unlimited amount. Understanding that mechanism explains most drained wallets better than any story about stolen keys.

Why the permission exists at all

Standard tokens are ledgers held in their own contracts. Your balance is a row in the token's contract, not something that lives in your wallet, and your wallet holds only the key that authorises changes to that row.

A contract that wants to move tokens on your behalf therefore has to be authorised in the token's ledger. That is the approval: a record in the token contract saying a named address may transfer up to a stated amount of your balance.

It is a sensible design for the problem it solves, and it has two properties that cause the trouble: the allowance persists until changed, and the amount is set by whoever asks.

Why unlimited became the default

Applications request unlimited approvals because the alternative costs their users money and attention. An exact-amount approval must be re-granted for every interaction, which means an extra transaction and an extra fee each time.

So the convention became: ask once, for everything, forever. It works well until the contract holding that permission turns out to be malicious, or is upgraded to something malicious, or contains a flaw someone else can use.

At that point the permission you granted is exercised. Nothing about your key was compromised; the transfer is authorised, on-chain, by you. There is no mechanism to reverse it and no party to appeal to.

The shapes an attack takes

A drainer site presents what appears to be a mint, an airdrop claim or a token migration. The transaction it asks you to sign is an approval, and the wallet's default display describes it in language most users skim past.

A compromised front end is worse because the site is legitimate. The contract addresses it points at have been swapped, and users who verify the domain — which is the advice everyone gives — are verifying the wrong thing.

An upgradeable contract that later changes behaviour is the quietest version. The approval was granted to something benign and remains granted to whatever it becomes.

Signature-based permissions add a variant worth knowing: some tokens allow an allowance to be granted by an off-chain signature rather than a transaction. Users trained to treat signing a message as harmless — because it usually is — can grant a full allowance without a transaction confirmation appearing at all.

Auditing what you have granted

Approvals are public. Every one you have granted is queryable from chain data, and several tools present them as a list with the option to revoke.

Revoking is itself a transaction, so it costs a fee, which is the friction that stops most people. The practical compromise: revoke everything on any address holding meaningful value, accept the cost, and treat it as periodic maintenance rather than a response to bad news.

The structural answer is better than the maintenance one. A separate address for interacting with applications, holding only what you are willing to lose, means an approval granted there cannot reach the address holding your position. Approvals are per-address; they do not travel.

• Audit approvals on any address holding value, and revoke anything you do not actively use.
• Keep a separate address for interacting with contracts, funded only with what a mistake could cost.
• Set exact-amount approvals where the wallet supports it, and accept the extra transaction fee as the price.
• Treat a request to sign a message with the same suspicion as a transaction, since some tokens grant allowances that way.
• Use a wallet that simulates transactions and shows the resulting balance change, which catches this class at the only moment it can be stopped.

Why this is the loss vector that matters

Key theft requires compromising a device or extracting a seed. Approval abuse requires the user to click through a screen they have clicked through many times before, and the transaction that does the damage is valid, authorised and irreversible.

That asymmetry is why wallets that put transaction simulation in front of the signature are the meaningful advance in this category, and why an audit of what you have already signed is the highest-value hour available to most self-custody holders.