TrustDex › Guides › Approvals & revoking
Token approvals: how wallets get drained and how to revoke
The most common wallet drain doesn't crack your keys. It uses a permission you granted with one click on the wrong website — sometimes without a single transaction appearing in your history.
Every time you swap, stake, or list an NFT, your wallet asks you to sign something first — and buried in that routine is the mechanic behind a huge share of crypto theft. An approval is a standing permission: it authorizes a contract to move a token out of your wallet on its own, later, without asking again. DeFi cannot work without it, which is exactly why attackers imitate it. This guide covers what the permission really grants, the ways it's abused — including the signature-only variants that leave no trace in your transaction history — and the routine that keeps old grants from becoming future losses.
Vet the token before you grant anything
Scan an address first — a hostile token plus a careless approval is the worst combination.
What you're actually granting
On EVM chains, calling approve(spender, amount) writes an allowance into the token's ledger: this spender may pull up to this amount from my address, any time, in any number of transfers, until the allowance is spent or overwritten. The permission attaches to your address, not your current balance — top up the token next month and the old allowance covers the new coins too. Solana's analog is the SPL delegate: a token account can name one delegate with a spending cap. Same shape, one practical difference — everyday Solana swaps generally don't require standing delegates, so an unexpected delegate on your account deserves immediate suspicion rather than a shrug.
Unlimited approvals: convenience with a long tail
Apps overwhelmingly request the maximum possible allowance — effectively infinite — so you never pay gas for a second approval on that token. The cost of that convenience is concentration of risk: your exposure is no longer "what I'm trading today" but "everything I'll ever hold of this token, for as long as the allowance stands." Three failure modes follow. The approved contract gets exploited, and the attacker inherits every open allowance pointed at it. The approved contract was malicious from the start, and the request was the attack. Or the allowance simply outlives your memory — granted in some forgotten farm two years ago, still valid, still a door. Approving only what the transaction needs costs a little more gas and caps all three.
Anatomy of a drainer operation
Modern drainers are packaged kits rented out to whoever can drive traffic, and the traffic side is where the variety lives: fake airdrop claims, spoofed project sites at lookalike domains, compromised Discord announcements, "verify your wallet" DMs, poisoned search ads. The on-chain side barely varies. The site enumerates what your address holds, ranks it by value, and generates a signing request for the most valuable target — a token approval, an NFT operator grant like setApprovalForAll, or on Solana often just a transaction that transfers assets straight out. You sign what the site's interface describes as a claim or a login; the kit's backend uses the permission within seconds, sweeps, and forwards proceeds through mixers. There's no hacking anywhere in the chain — every step runs on a signature you provided.
The signature is the event. Everything downstream of a signed approval or permit is unstoppable plumbing. Your entire practical defense happens in the seconds where the wallet shows you a request and you decide. Slowing down at that moment is the whole game.
Permit and Permit2: drained without an approve transaction
Signature phishing removes even the on-chain approve step. Tokens implementing Permit accept a signed off-chain message as allowance authorization — the message itself, once submitted by anyone, sets the allowance. Permit2 generalizes this: approve the Permit2 contract once, and thereafter signed messages govern which apps can pull which tokens. Both are genuine UX improvements used by legitimate apps every day, and both are a gift to phishers: a malicious site asks for a "harmless" signature — no gas, no transaction, framed as verification — and receives a valid permit. The attacker submits it on-chain from their wallet, pays the gas themselves, and drains. Your own history shows nothing but the assets leaving. The tell is structure: a permit signature contains a token, a spender, an amount, and a deadline. Any site asking you to sign something with those fields when you aren't deliberately setting up a token allowance is asking for your money.
Reading a request before you sign it
Wallets have gotten better at decoding what's in front of you — use what they show. On a transaction, check the function being called and the spender receiving power: is it the verified router you meant to use, or a fresh unverified contract? Does the amount match your trade, or is it the max value? On a message signature, be most alert when the content is readable and structured — typed data naming tokens, spenders, amounts, deadlines, or Solana instructions transferring assets or changing account authorities. And treat context as evidence: a swap needing an approval is normal; a mint page needing setApprovalForAll over your existing NFTs, or a "claim" needing a permit over your stablecoins, is a mugging wearing a UI.
| Request | Legitimate when… | Drain pattern |
|---|---|---|
| approve / delegate | Known app, spender verified, sane amount | Unverified spender, max amount |
| setApprovalForAll | Listing on a marketplace you chose | Requested by a mint or claim page |
| Permit / Permit2 message | You're intentionally authorizing a spend | Framed as login or "verification" |
| Solana transaction | Simulation shows expected balance changes | Transfers out or reassigns authority |
Revoking: what it fixes and what it can't
Revocation is the cleanup half of hygiene. Allowance checkers — explorer token-approval tabs and dedicated revoke tools on EVM, delegate views on Solana — list every standing grant attached to your address; clearing one is a small transaction setting it back to zero. Schedule it after any interaction with a site you've soured on, after news of an exploit in a protocol you've touched, and periodically regardless.
Be equally clear on the limits. Revoking is not recovery: transfers already executed are final, so a drained wallet stays drained. It doesn't help against a leaked seed phrase — that attacker is you as far as the chain is concerned, and only moving everything to a fresh wallet helps. And a revocation only lands if it's confirmed before the attacker spends the allowance, a race you should assume you'll lose if the phish already happened. Revoke to shrink tomorrow's attack surface, not to undo yesterday.
Hygiene that makes approvals survivable
The durable fix is architectural. Split your funds: a hot wallet holding only what you're actively trading does the risky signing, while long-term holdings sit in a wallet — ideally hardware-backed — that never touches a new dApp. Then any single bad signature has a bounded blast radius. Within the hot wallet, prefer exact-amount approvals, let permits carry short deadlines, and clear grants you no longer use. Use a burner wallet for mints and airdrop claims, the two highest-phish categories. None of this requires vigilance to be perfect — that's the point. Hygiene is what saves you on the day your attention fails.
Scan first, sign second
TrustDex checks the token; swaps stay non-custodial, with your keys on your device.
Frequently asked
Can a token approval drain coins I get in the future?
Yes, for the token it covers. An allowance is a standing permission against your address, not against your balance at signing time. If you granted an unlimited allowance on a token, anything you later acquire of that token is spendable by the approved contract until you revoke. Approvals on one token never extend to other tokens, though drainer sites typically collect approvals on several at once.
How can a wallet be emptied without any approval transaction on-chain?
Through signature phishing. Tokens supporting Permit — and infrastructure like Permit2 — accept an off-chain signed message as authorization. A malicious site asks for what looks like a harmless login or verification signature; the attacker then submits your signature on-chain themselves, setting the allowance and sweeping in one go. Your history shows no approve transaction because the attacker paid for and sent it.
Does revoking an approval return tokens that were already taken?
No. Revocation only removes the standing permission going forward — transfers already executed are final. That's why revoking is maintenance rather than remedy: it shuts doors that haven't been used yet, and it does nothing about a compromised seed phrase, which requires abandoning the wallet entirely.
Do approvals work the same way on Solana?
The equivalent is the SPL delegate: each token account can name one delegate approved to transfer up to a set amount. Routine Solana swaps usually don't need a standing delegate, so finding an unfamiliar one on your account is more anomalous than an EVM allowance and worth revoking immediately. Drainers on Solana also favor a blunter move — a transaction that directly transfers assets out or reassigns account ownership — so inspecting what a transaction does before signing matters just as much.
Should I revoke every approval I have?
You don't have to, and re-approving costs gas — the practical approach is triage. Revoke first anything granted to unverified or unfamiliar contracts, anything unlimited on tokens you hold in size, and everything on wallets that touched a suspicious site. Approvals to major, audited contracts you use weekly are lower priority, though clearing what you no longer use is cheap insurance.