A wallet drainer is not usually malware. It is a request you approve. The script behind it asks your wallet to grant permission, or to sign an order, and then uses that permission to move the assets out — often within seconds, without ever touching your seed phrase.
That distinction matters because it changes the defence. A leaked phrase means the wallet is gone and every address derived from it is compromised. A wallet drainer only gets what you authorised, which means the damage is bounded by what you signed and can sometimes be undone by revoking it.
- Drainers ask for permission, not words. The prompt is an approval or a signature; anyone asking for your seed phrase is running a different, cruder attack.
- Unlimited approvals are standing authority. A single grant can let a contract move that token balance for as long as it exists.
- Revocation is possible but costs a transaction. Approvals can be set back to zero; the fee depends on the chain and current conditions.
- Signatures have value. A permit or a signed order can be executed by whoever holds it, even though nothing was broadcast when you clicked.
How a wallet drainer gets paid
It exploits a permission that exists for legitimate reasons. Every mechanism below has a normal use, which is exactly why the prompts look familiar.
Token approvals
An approval tells a token contract that a particular address may move up to a stated amount of your balance. Marketplaces and routers need this to settle trades. Set the amount to the maximum and the spender can move that token at any time, without further prompts.
For NFTs the equivalent is a blanket operator approval: one signature authorises an address to transfer every token in a collection. It is efficient for a marketplace and devastating when the operator is hostile.
Permits and signed orders
Newer token standards allow an approval to be expressed as a signature instead of a transaction. The signature is free to produce and can be submitted later by anyone holding it. Marketplace orders work the same way: signing an order authorises a trade at the stated terms, and the counterparty does not need your participation to complete it.
This is why “it was only a signature” is not a defence. A signature that grants authority is authority, with the added problem that it may sit unused for weeks before someone submits it.
The sweep for gas
Moving a token costs a fee, and a drained wallet often has no native coin left to pay it. Drainer contracts typically take the native balance too, or watch for incoming funds and move them at once. Sending gas to a compromised address to rescue tokens usually fails; the deposit is swept before your transaction lands.
Requests that hand over authority
The five request types below cover most incidents. The tell is always in the detail, never in the button label.
| Request | What it grants | Warning sign | Revocable |
|---|---|---|---|
| Token approval, limited | Spending rights up to an amount | Amount does not match the trade | Yes, set to zero |
| Token approval, unlimited | The entire balance of that token | Maximum value, no obvious reason | Yes |
| NFT operator approval | Transfer of a whole collection | Asked for by a site you just met | Yes |
| Permit signature | Spending rights, granted off-chain | Deadline far in the future | Only by spending or revoking after execution |
| Signed order | A fillable trade at fixed terms | Price of zero or no expiry | Not directly; depends on the contract |
The pattern is the same in all five: authority broader than the task. A swap needs an allowance for the amount swapped; a mint needs an approval for the mint price. When the requested authority dwarfs the action, the difference is the attacker’s margin.
Warning signs worth acting on
None of these is proof on its own, and several appear in legitimate flows. Two or more together is a reason to close the tab.
- You arrived from a link in a direct message, a comment, an advert, or a search result rather than a bookmark.
- The site promises a claim, refund, migration or airdrop you were not expecting, and imposes a deadline measured in minutes.
- The approval asks for the maximum amount on a token you hold a large balance of.
- The prompt describes the action in one vague line, or shows raw calldata you cannot read.
- The domain differs from the official one by a character, a hyphen, or a different top-level domain.
- Your wallet warns that the site is not on a known list, or that the contract is unverified, and you click through anyway.
- A “revoke” page asks you to connect and sign before it will show your approvals. Revocation tools do not need a signature to read allowances.
A drainer never needs your seed phrase. It needs one click, and it will spend more effort making that click feel routine than it spends on any other part of the operation.
How to revoke an approval
Revoking means writing a new value into the token contract. It is an ordinary transaction, and it costs a fee, so do it deliberately rather than in a panic.
- Stop using the affected address for anything new. Do not send it more funds while you work out what is outstanding.
- Review current allowances using an approval dashboard, or by reading the token contract directly if you prefer not to trust a third-party interface.
- Identify the spender, the token and the remaining allowance. Prioritise unlimited approvals and anything granted to an address you do not recognise.
- Revoke by setting the allowance to zero, which costs one transaction per approval. Batch where a tool supports it on chains with cheap fees.
- Confirm each revocation on a block explorer. A submitted transaction is not a completed one.
- For collections, revoke the operator approval rather than individual token approvals, since one operator grant covers the whole set.
- If the address was compromised rather than merely over-approved — for example a signature you cannot revoke — create a fresh account and move what remains.
Budget the effort. Where fees are low, clearing a dozen approvals is cheap and can be done in one sitting. On a congested network each revocation is a separate transaction, which is an argument for reviewing approvals before an incident rather than during one.
Reducing what a drainer could take
Assume one click will eventually happen, and design around it. Keep a small hot wallet for interacting with new sites and a separate account for holdings, so an approval granted from the first cannot reach the second. Review allowances on a schedule rather than only after bad news. Prefer limited approvals to unlimited ones even when the interface nudges toward the maximum, and treat every signature prompt as a decision about authority rather than a formality.
None of this requires predicting which site will be hostile. It requires keeping the amount of authority you hand out small enough that a single mistake is survivable.
0 comments
No comments yet — ask a question and we will answer it here.