Approval Exploits: The Attack Most People Never Heard Of

This attack produces a distinctive response from victims: they are certain they were hacked, because nothing they did explains the loss.

They were not hacked. Weeks earlier, they signed something.

How token approvals work

To let a contract move your tokens, you grant it an allowance. This is a separate transaction, signed by you, recorded on-chain.

Two properties make it dangerous.

Many interfaces request an unlimited allowance by default. Rather than approving the exact amount for this trade, they request permission for the entire balance, now and in future. This is a convenience: it means you never approve again.

Allowances do not expire. An approval granted in 2023 is live today, and will be live in 2030, unless you revoke it.

The attack, in order

1. The victim connects a wallet to a site. It looks like a mint, an airdrop claim, a game, or a legitimate protocol.
2. The site requests an approval. The wallet shows a permission request, which looks routine because it is routine.
3. The victim signs. Nothing happens. There is nothing to notice.
4. Time passes. Days, weeks, occasionally months.
5. The contract moves the tokens.

The delay is deliberate. An immediate drain links the theft to the site, and the victim warns others. A delayed drain arrives with no visible cause, and the victim reports being hacked.

Why it is hard to see coming

The signature request is genuinely ambiguous. A legitimate exchange contract and a malicious one request identical-looking permissions. The difference is in the contract address, which most wallets display as a truncated string that means nothing to the reader.

Some wallets now simulate transactions and warn about unlimited approvals. This helps considerably and is not universal.

The variants

Permit signatures. A gasless approval that does not appear as an on-chain transaction at all. The victim signs a message rather than a transaction, which feels less consequential and is not.

Address poisoning combined with approval. The attacker seeds your transaction history with an address resembling one you use, hoping you copy it later.

Compromised legitimate front ends. The contract is real and the site has been taken over. This is the hardest case, because none of the usual warning signs are present.

What actually protects you

Approve exact amounts where the interface allows it. Slightly less convenient, dramatically smaller exposure.

Audit your approvals periodically. Every major explorer has a token approval checker. Sort by value at risk and revoke anything you do not currently use.

Use a separate wallet for interacting with anything new. A wallet holding a small balance, used for experiments, with long-term holdings in a wallet that has never connected to a site at all. This single practice removes most of the exposure.

Read the contract address, not the site name. Compare it against the project’s official documentation.

Treat a permit signature with the same seriousness as a transaction. It carries the same consequence.

What to do if you have already signed something

Revoke immediately, through a block explorer’s approval tool. Revocation is itself a transaction and costs a network fee.

If tokens have already moved, they are gone. Revoking prevents further losses from the same approval, which is worth doing even after a loss, because these contracts are patient.

Then move remaining assets to a fresh wallet. An address whose approvals have been exploited should be considered compromised for planning purposes, even though the private key itself was never exposed.

The broader lesson

The most expensive category of crypto loss no longer requires stealing anything from you. It requires persuading you to sign something, once, for a reason that seemed fine at the time.

That is a different threat model from the one most security advice addresses, and a separate wallet for experiments defends against it better than any amount of vigilance.