How to Revoke Token Approvals and Stop Drainers

To revoke a token approval, open an approval checker for the network the tokens sit on, find the spender contract, and send a transaction that sets its allowance back to zero (for NFTs, one that switches the operator approval off). That transaction costs gas. Revoking stops future pulls only: it cannot reverse tokens a drainer has already moved, and it does nothing if your seed phrase is exposed.

Most "my wallet got drained" stories on Ethereum and the chains that copy its token standards are not cases of someone cracking a private key. They are cases of the wallet owner granting permission, usually without realising it, and a contract later using that permission exactly as the standard allows. This guide explains the permission system from the standards themselves (EIP-20, EIP-2612, ERC-721, ERC-1155 and Uniswap's Permit2), shows how drainers turn each kind of permission into a theft, and then lays out what revoking can and cannot repair.

Why a Token Needs Your Permission at All

A plain token transfer is something you do yourself: your wallet signs a transaction calling transfer on the token contract, and the tokens move. But a lot of on-chain activity needs a contract, not you, to move your tokens. A decentralized exchange has to pull the token you are selling. A lending market has to pull the collateral you deposit. A marketplace has to move the NFT you listed when a buyer shows up, possibly weeks later, while you are asleep.

The ERC-20 standard (EIP-20, finalized and created in November 2015) solves this with a two-step design. First you call approve, naming a spender address and an amount. The standard describes it as allowing the spender "to withdraw from your account multiple times, up to the value amount", and if you call approve again for the same spender, the new value overwrites the old one. Second, the spender calls transferFrom whenever it wants to move tokens out of your balance, and the token contract checks the remaining allowance before letting it through. A third function, allowance(owner, spender), returns how much the spender is still permitted to take. Every successful approve must emit an Approval event, which is what approval checkers read to build their lists. A different wallet risk, lookalike addresses planted in your history, is covered in address poisoning explained.

Three properties of this design matter for safety:

The permission lives in the token contract, not in your wallet app. Disconnecting a site in your wallet's "connected sites" list does not touch it. The allowance stays recorded on-chain under your address until it is used up or changed.

It does not expire by default. The ERC-20 allowance has no time field. The ethereum.org revoke guide says it bluntly: permissions have no expiration date and can be used years after they were granted.

The spender acts without asking you again. Once the allowance exists, every transferFrom inside the limit goes through with no further signature from you. That is the convenience, and it is also the risk.

If you want the background on what a wallet actually controls (keys and signatures rather than coins sitting "inside" an app), the plain-English wallet primer covers it, and it makes the rest of this guide easier to follow.

Unlimited Approvals: Convenience With a Long Tail

Most decentralized apps do not ask for the exact amount of your trade. They ask for the maximum value a uint256 number can hold, which is roughly 1.16 followed by 77 zeros. OpenZeppelin's widely used ERC-20 implementation documents what that number means in practice: if the approved value is the maximum uint256, the allowance is not reduced when transferFrom runs, which it calls "semantically equivalent to an infinite approval."

Why do projects default to it? The ethereum.org guide gives the honest answer: an unlimited allowance means you approve once and pay one approval fee, instead of paying again before every trade. The cost is that the permission covers your whole balance of that token, today and any amount you receive later, for as long as it stays in place. Ethereum.org's own security page is direct about the trade-off: "do not allow unlimited spend limits. An unlimited spend could enable the smart contract to drain your wallet."

An unlimited approval to an honest, well-audited contract is mainly a dormant risk. It becomes a live one in three situations:

1.The contract has a bug or upgrade path that an attacker exploits, so a hacked contract can pull from every wallet that approved it. This is the scenario Etherscan's approval tool has in mind when it labels a figure "value at risk" and describes it as "what is vulnerable if the contracts were hacked."

2.The spender was never honest in the first place: a phishing site asked for the approval, and the "contract" is a drainer.

3.You forgot the approval exists. It was granted to a protocol you used once in a busy month, the protocol was later abandoned or compromised, and the permission was still sitting there.

Bridges carry a related concentration risk, since one contract often holds many users' deposits; the guide to how bridge hacks happen shows how a single contract failure becomes a mass loss, and old approvals to bridge contracts are part of the same exposure.

Three Ways to Hand Over Spending Power

The original approve transaction is visible and costs gas, which at least gives you a moment of friction. Newer mechanisms move the permission into an off-chain signature, which is cheaper and smoother, and also much easier to misread.

EIP-2612 permit: an approval you sign instead of send

EIP-2612 (created April 2020, now final) adds a permit function to ERC-20 tokens that support it. Instead of sending an approve transaction yourself, you sign a structured message containing the owner, spender, value, a nonce and a deadline. Anyone can then submit that signature to the token contract; the standard says explicitly that "the caller of the permit function can be any address." When it is submitted and the conditions check out (the deadline has not passed, the nonce matches, the signature is valid), the contract sets the allowance exactly as if you had called approve, increments your nonce and emits an Approval event.

Two details from the specification matter for safety. The deadline is chosen by whoever constructs the message, and the standard notes that setting it to the maximum value produces a permit that effectively never expires. And because signing costs nothing and needs no gas, a phishing page can collect a permit signature from a wallet that holds no ETH at all, then submit it later with the attacker paying the fee.

Permit2: one approval to a router, then signatures for everything else

Uniswap's Permit2 contract changes the pattern again. Uniswap's developer documentation describes it as a unification of two modules, AllowanceTransfer and SignatureTransfer. You make one ordinary ERC-20 approval per token to the Permit2 contract itself, often for the maximum amount, and from then on individual apps get permission by asking you for a signature that Permit2 checks.

AllowanceTransfer stores a standing permission inside Permit2: an amount, an expiration timestamp and a nonce for each owner, token and spender. Uniswap's documentation notes that these allowances "carry their own expiration after which the permission is invalid", which is an improvement over plain ERC-20 allowances. The interface also includes a lockdown function that, in its own words, enables "a lockdown of the sender's Permit2 identity by batch revoking approvals", and an invalidateNonces function that cancels outstanding signatures for a token and spender pair.

SignatureTransfer authorises a single transfer per signature. Each nonce can be spent once, signatures carry a deadline, and no allowance lingers afterwards.

The safety implication cuts both ways. Permit2's expirations and one-time transfers shrink the window for abuse. But because the big unlimited approval now points at Permit2, a phishing site does not need you to approve anything on-chain. It only needs one signature granting a Permit2 allowance or transfer to its own address, and it can then move tokens through the approval you made for legitimate use.

NFT operator approvals: setApprovalForAll

For NFTs, ERC-721 (created January 2018) offers two kinds of approval. approve(address, tokenId) authorises one address to move one specific token. setApprovalForAll(operator, true) enables, in the standard's wording, "a third party ('operator') to manage all of" your assets in that collection, and the standard requires that multiple operators per owner be allowed. ERC-1155 (created June 2018), the multi-token standard, has only the operator form at its core; its text suggests a separate scoped-approval interface for anyone who wants to approve a subset of tokens.

So a single "set approval for all" on a collection is the NFT equivalent of an unlimited ERC-20 approval: every token you hold in that contract, and every one you receive later, can be moved by the operator.

The permission types side by side

This table summarises what each mechanism creates and how to undo it. It is built from the standards and the Permit2 interface cited in the sources.

Mechanism	How you grant it	What the spender gets	Does it expire?	How to cancel it
ERC-20 approve	On-chain transaction (costs gas)	Pull up to the amount, repeatedly	No	New approve to the same spender with value 0 (costs gas)
ERC-20 unlimited approve	On-chain transaction, max uint256	Pull any amount, now or later	No	Same as above
EIP-2612 permit	Off-chain signature (free to sign)	Becomes a normal allowance once someone submits it	Signature has a deadline; the resulting allowance does not	Before use: submit a transaction that consumes the nonce. After use: approve to 0
Permit2 AllowanceTransfer	Off-chain signature, after a one-time approval to Permit2	Pull up to the amount until the expiration	Yes, per allowance	Permit2 approve or lockdown; invalidateNonces for unused signatures
Permit2 SignatureTransfer	Off-chain signature	One transfer, one time	Signature deadline	Invalidate the unordered nonce before it is used
ERC-721 approve (single token)	On-chain transaction	Move that one NFT	No	Approve the zero address for that token
ERC-721 / ERC-1155 setApprovalForAll	On-chain transaction	Move every token in the collection	No	setApprovalForAll(operator, false)

How Wallet Drainers Turn Permission Into Theft

A "drainer" is not a single piece of malware on your computer. It is usually a phishing site connected to a script that reads your wallet's balances, picks the most valuable tokens, and asks for whichever permission it needs to take them. The site then calls transferFrom (or the NFT equivalent) from an address the attacker controls. Because the standards say the spender may move tokens up to the allowance, the token contract treats the theft as an ordinary authorised transfer.

The routes in are familiar from general phishing. The FTC's consumer guidance on phishing describes messages that claim a problem with your account and push you to click a link to fix it, and it points out that real companies will not send a link asking you to update payment details. Crypto versions swap "your account" for "your wallet", "your airdrop" or "your mint allocation":

Fake claim pages. A message or social post announces an airdrop or refund. The claim button triggers an approval or a permit signature for your most valuable token. Ethereum.org's security page describes the related airdrop scam, where a project sends an asset to your wallet and the website for "claiming" or "selling" it is what compromises you.

Lookalike domains and search ads. The site copies a real app pixel for pixel. Ethereum.org's advice is to always check you are on the right domain, especially after clicking a link.

"Verify your wallet" or "sync" prompts. These ask for a signature framed as a login. Sometimes it is a real login message. Sometimes it is a permit.

Hijacked accounts. A trusted project's social account or Discord is taken over and posts the drainer link, so the source looks legitimate.

The crucial point is that an off-chain signature can be every bit as dangerous as a transaction. If a site asks you to sign typed data whose fields include a spender, a value and a deadline, you are being asked to approve spending, whatever the button says. The broader behavioural tells that come before any of this (urgency, guaranteed returns, unsolicited contact) are listed in the site's FTC-based scam red flags checklist.

Reading a Signature Request Before You Sign

EIP-712, the typed-data standard that permits and Permit2 rely on, exists precisely because, as its own motivation section says, signed messages used to be "an opaque hex string displayed to the user with little context." With typed data, your wallet can show labelled fields. That only helps if you read them. Use this checklist on every signature or approval prompt that is not a plain send:

1.What type of request is it? A transaction (costs gas, appears on-chain immediately) or a signature (free, may be used later by someone else)? Treat both as permissions until you know otherwise.

2.What is the domain or contract? For a permit, the domain names the token contract. For Permit2, the verifying contract is Permit2. If you did not intend to give anything access to that token, stop.

3.Who is the spender or operator? This is the address that gets power over your tokens. On a legitimate swap it is usually the app's router or Permit2-aware contract. On a drainer it is often a fresh address or an unverified contract. Paste it into a block explorer before signing; an address with no history, an unverified contract or a name that does not match the app is a reason to walk away.

4.What is the amount? An enormous number (often shown as "unlimited" or a long string of digits) on a site where you meant to spend a small amount is a mismatch.

5.What is the deadline or expiration? Days or years away on a one-off action is another mismatch.

6.Does the function name match what you are doing? setApprovalForAll on a page that says it is checking your eligibility for an airdrop is not a coincidence.

7.Did you start this? A prompt that appears when you were not trying to do anything is a red flag on its own. Close the tab.

8.Is the request asking for your seed phrase? Then it is a scam, every time. Ethereum.org puts it simply: "No legitimate service, support agent, or website will ever ask you for these."

Some wallets let you edit the amount of an approval before confirming. Where that option exists, setting the approval to the amount you actually need for this action is the main practical defence ethereum.org recommends.

How to Find and Revoke Approvals, Step by Step

The ethereum.org guide to revoking token access lists several tools: Etherscan and Blockscout cover Ethereum only, and others cover multiple networks. They all read the same on-chain data (Approval and ApprovalForAll events plus current allowances) and offer to build the revoke transaction for you. The procedure is the same everywhere:

1.Use a tool you reached yourself. Type the explorer's address or use a bookmark. Fake "revoke" sites are an established phishing lure, because a person who suspects a drain is exactly the person who will connect a wallet in a hurry.

2.Pick the right network. Approvals are per chain. An approval on a layer 2 network does not appear when you check Ethereum mainnet, and the ethereum.org guide notes that tools only show contracts on the network you have selected. If you use several chains, check each one; the explainer on layer 1 and layer 2 networks explains why each rollup keeps its own state.

3.Review the list. Etherscan's approval checker, for example, separates ERC-20, ERC-721 and ERC-1155 approvals into tabs and shows the spender, the asset and the allowance for each. Look for unlimited allowances, spenders you do not recognise, and protocols you no longer use.

4.Revoke. Select the approvals and confirm. For an ERC-20 token, the tool sends approve(spender, 0). For an NFT collection, it sends setApprovalForAll(operator, false). Your wallet shows the gas fee before you confirm.

5.Check the result. After the transaction confirms, refresh or reconnect and make sure the approval is gone. Ethereum.org suggests waiting a few minutes before checking.

Ethereum.org's FAQ answers a worry many people have: revoking access does not end staking, pooling or lending positions, and your rewards are unaffected. It also points out the cost of caution: if you revoke everything, you will have to approve again the next time you use those apps.

Is revoking worth the gas?

Each revoke is a separate on-chain transaction, and ethereum.org is clear that you have to pay the fee for the cancellation to succeed. The fee is the gas the transaction uses multiplied by the gas price at the time, and your wallet estimates both. A simple way to decide is to compare the fee with what the approval could cost you.

As an illustration with hypothetical inputs only: say a revoke used 45,000 gas units at a gas price of 2 gwei. The fee would be 45,000 × 2 gwei = 90,000 gwei, or 0.00009 ETH. If the approval in question gives an unknown contract unlimited access to a token balance worth far more than that, revoking is cheap insurance. If it is a capped approval of a few dollars' worth of a token to a protocol you still use daily, the fee may exceed the risk. Bitcoin prices block space differently (the Bitcoin fee and mempool explainer walks through fee rates per virtual byte), but the principle carries over: the network charges for the space your transaction uses, not for the value it protects.

What Revoking Cannot Fix

Revoking is a lock on a door. It is no help once the room has been emptied, or when the thief has your keys. This table maps common situations to what a revoke achieves.

Situation	Does revoking help?	What to do instead or as well
Old unlimited approval to a protocol you no longer use, nothing stolen	Yes, it removes the exposure	Revoke and move on
Drainer already pulled tokens via an approval	It stops further pulls of that token by that spender; it does not return anything	Revoke immediately, then document and report
Drainer has an approval but has not used it yet	Yes, if your revoke confirms first	Revoke at once; consider moving the remaining tokens to a fresh wallet
You signed an EIP-2612 permit that has not been submitted	Only by consuming the nonce first (for example by submitting a transaction that uses it)	Treat the token as exposed; moving the balance to a new address removes what the permit can take
You signed a permit and it was already submitted	Yes, the result is a normal allowance, so approve to 0	Revoke, then check balances
You signed a Permit2 allowance or transfer	Permit2's own approve, lockdown or invalidateNonces can cancel it; revoking the Permit2 approval for that token cuts off all Permit2 access	Use a tool that reads Permit2 allowances, or revoke the token's approval to Permit2
setApprovalForAll granted to a drainer	Yes, set it to false	Do it before listing or receiving more NFTs in that collection
Seed phrase or private key exposed	No. The attacker can sign anything you can, including new approvals	Create a new wallet with a new seed and move everything that remains
Funds sent directly to a scammer's address	No, there is no approval involved	Report it; see the reporting guidance below

The seed-phrase row is the one people most often get wrong. If you typed your recovery phrase into a website, gave it to "support", or stored it somewhere that was compromised, revoking approvals is pointless: the attacker can simply create new ones, or send tokens directly. The seed phrase recovery and backup checklist covers setting up a replacement wallet properly. A race also matters here. Moving assets out of an exposed wallet requires gas, and draining scripts often watch for incoming ETH, so prepare the new wallet first and move the most valuable assets first. If you are not sure whether the draining transactions came from your key or from an approval, work out the cause first with this triage tree.

Edge Cases and Common Mistakes

Disconnecting instead of revoking. Removing a site from your wallet's connected list stops the site from seeing your address through the wallet. It does not remove any allowance. Ethereum.org's FAQ is explicit that a disconnected project can still use tokens you approved.

Checking only one network. The same address exists on Ethereum and on every EVM network, but approvals are recorded separately on each. A clean list on mainnet says nothing about a layer 2 where you also bridged funds.

Forgetting the Permit2 layer. If you made a legitimate unlimited approval to Permit2 and later signed a malicious Permit2 message, the spender in the token's own allowance list is Permit2, not the attacker. A checker that only shows ERC-20 allowances will show a reasonable-looking entry. Revoking the token's approval to Permit2 cuts the attacker off, at the cost of re-approving later for apps that use it.

Overlooking a signed but unsubmitted permit. Because the attacker can hold a permit until just before its deadline, a wallet can look clean for days and then lose a token without any new action by its owner. If you remember signing something odd, assume the token is exposed until you have consumed the nonce or moved the balance.

Revoking through a fake revoke site. The rush after a loss is when people make the next mistake. Open the tool from a typed address or bookmark, and read the revoke transaction just as carefully as any other prompt; it should be an approve with a value of 0 or a setApprovalForAll with false.

Assuming tokens that arrived later are safe. An allowance is a permission over a balance, not over specific coins. Tokens you receive after granting an unlimited approval are covered by it.

Changing an allowance from one non-zero value to another. The EIP-20 text and OpenZeppelin's documentation both describe a race condition: a spender who sees you changing an allowance can try to use the old amount and the new amount. Their suggested pattern is to set the allowance to 0 before setting a new value.

Treating stablecoins as different. Dollar-pegged tokens use the same ERC-20 approval machinery, so an unlimited approval on a stablecoin exposes your whole stablecoin balance in the same way. The comparison of stablecoin designs explains how those tokens are built, and their freeze controls do not protect you from an approval you granted.

Wallets on exchanges. Approvals apply to self-custody addresses you control. Balances held in a custodial exchange account do not use your approvals at all. If you recently moved coins off an exchange, the guide to withdrawing to your own wallet safely covers the steps before any of this applies.

A Routine That Keeps Exposure Small

Approvals are not inherently bad; they are how decentralized apps work. The aim is to keep them small, few and deliberate.

Separate wallets by job. A long-term holding address that never connects to apps has no approvals to abuse. A smaller "hot" address handles day-to-day app use.

Prefer limited amounts. Where the wallet or app allows, approve what the action needs. Accept an extra approval fee next time as the price of a smaller blast radius.

Review on a schedule. Check each network you use, perhaps monthly or after any burst of activity, and revoke what you no longer need.

Read every signature. Apply the checklist above; a typed-data prompt with a spender, an amount and a deadline is an approval.

Never enter a seed phrase into a website. No approval check, airdrop claim or support ticket requires it.

If tokens have already left your wallet, revoking limits the damage but the next steps are documentation and reporting, and the period right after a loss is when fake recovery offers arrive. Read why paid "crypto recovery" services are usually a second theft before answering any message that promises to get funds back, and use the step-by-step guide to reporting a crypto scam to build the evidence pack with transaction hashes and spender addresses. This page belongs to the site's self-custody and security hub, which collects the related wallet guides.

Your next step: open the approval checker for the network you use most, from a bookmarked address, and compare its list against the protocols you actually used this year; any unlimited approval you cannot explain is the first one to revoke. Once the list is clean, the seed backup and recovery checklist covers the one risk an approval audit cannot touch: someone else holding a copy of your recovery phrase.

Frequently Asked Questions

Does revoking token access also end my staking, pooling or lending positions?

No. Revoking removes a contract's permission to pull more of your tokens from your wallet. Positions you already opened, and the rewards they earn, are unaffected, according to ethereum.org's revoke guide. You may need to approve again before adding to a position or using the app next time.

Is disconnecting my wallet from a site the same as removing its permission to use my funds?

No. Disconnecting only stops the site from talking to your wallet. The allowance is stored in the token contract on-chain, so the spender can still call transferFrom until you revoke it with a transaction.

When does a token approval expire?

A standard ERC-20 allowance or an NFT operator approval never expires on its own. It stays valid until it is used up or you change it. Permit signatures carry a deadline, and Permit2 allowances have their own expiration, but the classic approve has no time limit.

Why do apps ask for an unlimited token allowance?

It lets you approve once and pay a single approval fee rather than paying before every trade. The trade-off is that the spender can move your whole balance of that token, including tokens you receive later, so a bug or a malicious spender can take everything rather than one trade's worth.

Does it cost money to revoke a token approval?

Yes. A revoke is an on-chain transaction, so you pay the network fee for gas used multiplied by the gas price, which your wallet estimates before you confirm. Checking your approvals in an explorer is free; only the revoke itself costs gas.

Can a signature drain my wallet even if I never sent a transaction?

Yes. An EIP-2612 permit or a Permit2 message is an off-chain signature that sets up spending rights, and anyone can submit it to the chain later and pay the fee. That is why a signature request listing a spender, an amount and a deadline deserves the same scrutiny as an approval transaction.

If my wallet was drained, will revoking get my tokens back?

No. Revoking stops future transfers by that spender; it cannot reverse transfers that already happened. If your seed phrase was exposed, revoking does not help at all, because the attacker can create new approvals, so the remaining assets need to move to a new wallet with a new seed.

Sources

EIP-20: Token Standard - approve, allowance, transferFrom and the Approval event; overwrite behaviour; the set-to-zero-first interface recommendation; status and November 2015 creation date. Checked October 22, 2026.

EIP-2612: Permit Extension for EIP-20 Signed Approvals - permit parameters, nonce and deadline rules, "the caller of the permit function can be any address", the never-expiring deadline note, security considerations. Checked October 22, 2026.

EIP-712: Typed structured data hashing and signing - the motivation that signed messages were an opaque hex string with little context. Checked October 22, 2026.

ERC-721: Non-Fungible Token Standard - single-token approve, setApprovalForAll operator definition, multiple operators per owner. Checked October 22, 2026.

ERC-1155: Multi Token Standard - operator-only approval in the core standard and the scoped-approval suggestion. Checked October 22, 2026.

Uniswap developer docs: Permit2 overview - AllowanceTransfer and SignatureTransfer, expirations, one-time nonces, the one-time approval to Permit2 per token. Checked October 22, 2026.

Uniswap Permit2 source: IAllowanceTransfer interface - approve with amount and expiration, lockdown, invalidateNonces. Checked October 22, 2026.

OpenZeppelin Contracts ERC-20 API - max-uint256 allowance not decreased on transferFrom ("semantically equivalent to an infinite approval"); permits can be front-run; allowance race condition. Checked October 22, 2026.

Etherscan Token Approval Checker - ERC-20, ERC-721 and ERC-1155 tabs, "value at risk" wording, Revoke Selected flow. Checked October 22, 2026 (the info.etherscan.com help article returned HTTP 403, so the tool page itself was read).

ethereum.org: How to revoke smart contract access to your crypto funds - revoke steps, per-network tools, the fee requirement, and the FAQ questions used on this page. Checked October 22, 2026.

ethereum.org: Ethereum security and scam prevention - unlimited spend limit warning, read-before-signing advice, airdrop scams, domain checks, seed phrase rule. Checked October 22, 2026.

FTC: How To Recognize and Avoid Phishing Scams - phishing patterns and reporting routes. Checked October 22, 2026.

CryptosEyes publishes general educational research, not investment, legal or security consulting advice, and does not endorse any wallet, app or revoke tool. Tool names appear only as references to their documentation. If you believe a wallet is compromised right now, stop signing anything, and if the seed phrase may be exposed, move what remains to a newly created wallet before doing anything else.