Token approvals and why they drain wallets

A token approval is a permission you grant, from your own wallet, that lets a smart contract move a specific token on your behalf. It is a normal and necessary part of using decentralised applications — and it is also one of the most common ways wallets get drained. The danger is not the mechanism itself but how easily people approve more than they realise.

If you have ever swapped a token on a decentralised exchange, you have used an approval. Understanding what you are actually signing turns a hidden risk into a manageable one.

Why approvals exist at all

Most tokens on Ethereum and similar chains follow a standard called ERC-20. Under that standard, a token contract keeps its own ledger of balances. When you want an application — say a decentralised exchange — to swap your tokens, that application’s contract needs permission to move tokens out of your wallet. Rather than you sending tokens first and hoping, the standard provides an approve function: you authorise a named contract (the “spender”) to move up to a certain amount.

This two-step design (approve, then the app spends) is what makes composable DeFi possible. The problem is entirely in the details of that approval: which contract, and for how much.

The “unlimited approval” trap

To save you from re-approving before every transaction, many apps request an unlimited approval by default — permission to move essentially your entire balance of that token, indefinitely. It is convenient. It is also a standing liability.

Once granted, that permission persists on-chain until you revoke it. If the approved contract is malicious, or becomes compromised later, it can move the full approved amount at any time without another prompt from you. Many “drainer” thefts are simply an unlimited approval granted on a phishing page and then exercised minutes or months later. See how crypto phishing attacks work for the full flow.

Two related signatures are worth naming:

• setApprovalForAll — the NFT equivalent, which can grant a contract control over an entire collection in your wallet.
• Permit and Permit2 — “gasless” approvals granted by signing a message rather than sending a transaction. They feel harmless because there is no gas fee, but a signed Permit can authorise spending just as powerfully.

How a drain actually happens

Described purely so you can recognise it, the sequence is consistent and does not require anyone to steal your keys:

• You reach a lure or lookalike site and connect your wallet.
• The site prompts an approve, setApprovalForAll, or Permit for a token you hold, often for an unlimited amount.
• You confirm, believing it is a required step to “claim,” “swap,” or “verify.”
• The spender contract now has standing permission. It calls transferFrom and moves your tokens to the attacker. The transaction is valid because you authorised it.

There is no bug to blame. The chain did what your signature told it to. That is why the only reliable defence is to read and limit approvals before signing.

A concrete example: swapping a token

To ground the idea, walk through an ordinary, legitimate swap. You hold a token and want to exchange it on a decentralised exchange. Behind the friendly interface, two things happen. First, you sign an approve that authorises the exchange’s router contract to move that token — this is the permission step. Second, you sign the actual swap, and the router calls transferFrom to pull the approved token and send you the other one.

Everything about that is normal. The risk lives entirely in the first step’s details. If the app defaulted to an unlimited approval, the router keeps standing permission over your whole balance long after the swap is done. If you had instead set the allowance to just the amount you were swapping, the permission is effectively spent and there is nothing left to exploit later. Same swap, very different residual exposure — decided by one field most people never look at.

The same pattern lives on other chains. The approve-then-spend model is not unique to Ethereum. Most chains that support ERC-20-style tokens and smart contracts use the same model, so the same caution travels with you across networks. A few practical notes:

• Each chain is separate. An approval you granted on one network does not exist on another, and neither does a revocation, so you must review approvals per chain.
• Newer approval systems batch permissions. Some ecosystems use a shared approval contract to reduce repeated prompts; convenient, but it means one grant can cover interactions across many apps, so understand what you are enabling.
• NFT approvals use setApprovalForAll, which is all-or-nothing for a collection — a particularly powerful permission to grant carelessly.

Reading an approval before you sign

Every wallet shows approval details, though sometimes you must expand them. Before confirming, check:

• What action is it? An approve, setApprovalForAll, or Permit means you are granting spending power, not just moving funds.
• Who is the spender? Is it the contract you actually intend to use? Confirm the address against the project’s official source. Our guide to verifying a contract address shows how.
• How much? If your wallet lets you set a custom amount, approve only what this transaction needs rather than an unlimited allowance.
• Did you initiate this? An approval prompt you did not expect is a red flag, full stop.

Auditing and revoking existing approvals

Approvals you granted in the past are still live. It is good hygiene to review them periodically and revoke ones you no longer need. You can inspect approvals with block-explorer tools such as Etherscan’s token-approval checker, and revoke them from your own wallet.

• Review regularly. Especially after using a new or unfamiliar app.
• Revoke unused permissions. Revoking is itself an on-chain transaction, so it costs a small gas fee, but it closes the door.
• Prioritise unlimited approvals on tokens with real value.
• After any suspected phishing, revoke immediately and move remaining funds to a fresh wallet, since a granted approval outlives the moment you signed it.

One caution about revoking under pressure: if you believe an approval is actively being exploited, moving your at-risk assets to a safe wallet usually matters more than revoking first, because a revocation is itself a transaction that can be outrun by an attacker who is already draining. Get the valuable tokens out of reach, then revoke. And remember that revoking removes only future permission — it never reverses transfers that have already been confirmed on-chain.

Habits that prevent approval drains. A few routines close most of the gap:

• Prefer limited over unlimited approvals whenever your wallet allows it.
• Keep long-term holdings in a wallet you never connect to dApps, so there is nothing to approve.
• Use a hardware wallet so approvals must be confirmed on a separate screen; see hardware versus software wallets.
• Be as cautious with gasless Permit signatures as with on-chain approvals.

Bottom line

Token approvals are a legitimate feature that lets apps move your tokens with your permission — but an approval you do not understand is a standing invitation. The two questions that matter are always the same: which contract am I trusting, and for how much? Grant the minimum, verify the spender, revoke what you no longer use, and treat an unexpected approval prompt as hostile. Do that and the mechanism that drains careless wallets simply protects yours.