What this tutorial says in five lines
- An approval is a standing permission. It survives closing the browser, restarting and forgetting.
- A drainer needs one signature, not a payment — which is why "I never sent anything" is true.
- An unlimited allowance to an unrecognised contract is the single most dangerous thing you can sign.
- Approvals are per-chain. Revoking on mainnet does nothing for your L2 balances.
- Revoke monthly, and use a burner wallet for anything unfamiliar.
Why this matters
Every explanation of this theft has to start by dismantling the sentence victims most often say: "I never sent anything." That sentence is correct, and it is the whole point. An approval does not move your money; it grants a contract the right to move your money, permanently, at a time of its choosing. This tutorial explains the permission model, the request shapes that should stop you, and the monthly habit that keeps your exposure at zero.
The permission model, in plain terms
When you approve a token, you are not paying anything and not transferring anything. You are adding a row to the token contract’s own records that says this address may move up to this amount of my balance. That row persists until it is revoked.
Nothing about it expires. There is no session, no login and no connection to close. This is why disconnecting a site from your wallet is a different control from revoking an approval: disconnecting changes what the site can ask for, revoking changes what the contract can already do.
The wallet popup tells you what you are signing. It does not tell you whether the contract on the other side deserves it. Those are different questions, and only one of them is answered on screen.
The four request shapes that should stop you
Almost all approval losses come from four request shapes. If you see any of these and you did not deliberately come to a specific protocol to do exactly this, decline and close the tab.
The tell in every case is the same: the request is open-ended in a way that has no legitimate purpose for a routine action.
| Request shape | What it grants | Legitimate version looks like |
|---|---|---|
| Unlimited allowance to an unknown contract | Permanent permission to move that token, entirely | A specific amount, to a contract you verified |
| Blank or "max" amount field | An open-ended transfer authorisation | An exact figure matching the trade you are making |
| Permit / signature with no transaction | A gasless authorisation that can be executed later by the other party | A clear, dated, limited permit from a named protocol |
| Message signing on a site that should only swap | Possibly an authorisation in disguise | A swap request that shows amounts and routes |
| "Migrate", "validate", "sync" or "restore" screen | Anything at all — these do not exist as legitimate flows | Nothing. There is no legitimate version. |
Where the loss lands, and in what order
The order in which a drainer empties an account is not random. Kits are configured to take native coin first because it pays for fees, then stablecoins because they carry predictable value, then everything else. Recognising the sequence tells you which mechanism was used.
This chart shows the reported share of losses by asset class, which is also the order of exposure you should address when you audit your own wallet.
Reported approval-exploit losses by asset class, in the order taken
Relative share of approval-exploit loss attributed to each asset class
Reading: Native coin first is not a preference — it is a dependency. Without native coin the kit cannot pay fees for the remaining transfers, which is also why holding a small reserve elsewhere is not as silly as it sounds.
The monthly revoke habit
This is the single highest-value routine in crypto hygiene, and it takes about five minutes. Approvals do not expire, so anything you granted a year ago is still live unless you removed it.
Do it on every chain you have used. Approvals are recorded per-chain, so a mainnet revoke leaves your L2 and sidechain balances exactly as exposed as before.
- 01Open a token-approval checker for your address and list every active approval across all supported chains.
- 02Revoke every approval you cannot name the owner of. You do not need certainty that it is malicious; if you cannot explain it, remove it.
- 03Revoke unlimited allowances even on services you recognise. A legitimate service will simply ask again next time you use it.
- 04Disconnect unused sites inside the wallet interface as well — it is a separate control from revoking.
- 05Repeat monthly, and again after any period of trying new protocols.
Revoking costs only network fees and can only reduce your exposure. There is no scenario in which a dormant approval you do not need is working in your favour.
Architecture: stop the blast radius before it happens
Prevention here is an account-structure decision, not a vigilance decision. Vigilance fails eventually; structure does not.
The arrangement below is what most people arrive at after a loss, and it is worth adopting before one.
- 01Keep a hot wallet holding pocket change for new or unfamiliar sites. Assume it will eventually be drained, and make that survivable.
- 02Keep a cold or hardware-held wallet for anything you would be upset to lose. Never connect it to a site you have not verified.
- 03Never reuse an address that has ever been approved to an unknown contract, even after revoking.
- 04Keep a small native-coin reserve in a separate wallet, so that being drained of fees does not strand your remaining assets.
- 05Treat any unsolicited token or NFT as reconnaissance. Do not interact with its contract, and do not attempt to sell it.
If an approval was already used
The order here matters, and the first step is not the one people expect.
- 01Revoke every remaining approval immediately, on every chain. Anything still in the wallet under an active approval can be taken at any time, including while you read this.
- 02Move remaining assets to a new address generated from a new seed phrase on a clean device — native coin first, for fees.
- 03Copy the transfer hashes and the malicious contract address as text, not screenshots. Those are the identifiers every report needs.
- 04Record the approval transaction itself as well as the theft transaction. The approval is the evidence of how it happened.
- 05Abandon the old address permanently, and do not treat a zero balance as safety.
- 06Report the malicious site and contract to the platform hosting it and to a block explorer if it is tagged.
A wallet is not a place you keep money. It is a set of permissions attached to a key. Managing the permissions is the actual security practice.
The visual summary
Everything above, reduced to the four stages that matter for this topic. If you only look at one thing on this page, look at this.
Where this fits in the pattern
Before contact
Nothing has happened yet. This is when every tutorial here is most useful and costs you nothing but reading.
During the approach
The script is running. The verification tests in this tutorial are designed to be run here, neutrally, without confrontation.
At the money request
The decisive moment. Any request for funds, fees, taxes or unlock deposits is the end of the script, not a stage of it.
After a loss
Prevention is over; evidence work begins. Preserve, report, and never pay a second fee to recover the first.
Common questions
See what an address has authorised
The tracer reads the public ledger for outgoing flows, contract interactions and hop destinations, and exports a dated record you can attach to a report.
Primary sources and further reading
- FTC — Cryptocurrency Scams consumer.ftc.gov
- Chainalysis — Token Approvals and Wallet Drainers www.chainalysis.com
External links open in a new tab so you can verify the underlying material yourself. TrueMoneyTalk is not affiliated with these organisations.
Prevention only works if it reaches people before the contact does.
Disclaimer: this tutorial is general information, not legal, financial or recovery advice, and is not a substitute for advice from a licensed professional in your jurisdiction. Individual outcomes vary and are never guaranteed.