A token approval grants a smart contract permission to move specific tokens from your wallet without a fresh signature on every swap or deposit. The trade-off is that an approval lasts until it is explicitly revoked, and a single signing-blind moment can hand a malicious spender standing access to a token balance.
This article walks the contract mechanics of ERC-20 approve(), the Permit (ERC-2612) and Permit2 (Uniswap, November 2022) extensions, the drainer operations that turned approvals into the highest individual-wallet loss class of 2023-2026, the revoke workflows on Etherscan, Revoke.cash, MetaMask, and hardware wallets, and the 2026 hygiene posture that closes the loop.
What is a token approval, and why does it matter for crypto security?
A token approval is a write to an ERC-20 contract that records how many tokens a spender can move on the owner's behalf. The mechanism sits in the original ERC-20 standard and runs nearly every DeFi interaction: a DEX swap, a lending deposit, or a marketplace listing all start with an approval before transferFrom.
The contract storage layout is a nested mapping: allowance[owner][spender] = value. When the owner calls approve(spender, value), the token contract writes the value into that slot, and the spender can then call transferFrom(owner, recipient, amount) any number of times until the running total reaches the approved value (source: Ethereum.org ERC-20 token standard documentation). The OpenZeppelin reference implementation that most production tokens inherit from exposes the same semantics through _approve and treats type(uint256).max as a special infinite-allowance value the contract does not decrement on each transfer (source: OpenZeppelin ERC-20 contracts API reference). That infinite-approval pattern is the DEX-integration UX default because it lets the user swap repeatedly without re-approving, and it is also the pattern that converts a single signing mistake into a persistent loss surface.
The broader risk surface that approvals create sits inside the smart contract wallet risks framing for users on AA wallets, and on EOAs the same approval mechanic applies directly. Approvals do not move tokens at the moment of signing; they create a standing right for someone else to move tokens later, sometimes weeks or months after the user has forgotten which contracts they granted access to. That asymmetry between signing time and execution time is what makes approval hygiene a separate discipline from transaction signing, and it is the reason a wallet that looks safe today can quietly hold a half-dozen latent loss surfaces inside its allowance table.
What is the difference between approve(), Permit, and Permit2?
approve() is the original ERC-20 call that writes an allowance into the token contract storage. Permit (ERC-2612) and Permit2 (Uniswap's universal approval contract) extend the pattern to off-chain signatures, so a single signed message can grant the same allowance without a separate on-chain transaction. The three forms carry different blast-radius profiles.
A traditional approve(spender, value) call is an on-chain transaction that costs gas, leaves a visible record in the wallet's history, and writes the allowance into the token contract for any future transferFrom. ERC-2612 Permit, which has held Final status since 2022, lets a token holder authorise a spender by signing an off-chain typed-data message of the form permit(owner, spender, value, deadline, v, r, s); the spender submits the signature on-chain when they spend, which means the owner pays no gas and the approval surfaces only at execution time (source: EIP-2612 specification). Uniswap deployed the Permit2 contract in November 2022 as a universal approval router that supports two modes: AllowanceTransfer for standing allowances with optional expiry, and SignatureTransfer for single-use per-transaction signatures (source: Uniswap Permit2 documentation). Permit2 lets any integrated contract spend tokens via a one-time approval to the Permit2 contract itself, after which all subsequent allowances flow through the router.
Smart contract wallets sometimes batch the approval and the spend into a single UserOperation, which is one reason account abstraction wallets need explicit per-action review at the signing step. The defensive point across all three forms is the same: an approval (on-chain or off-chain, traditional or Permit2) authorises future movement, and the user should treat each signature request as if it were a wire transfer authorisation. Check the spender contract, check the token, check the allowance amount, and check the expiry before signing.
How do wallet drainers weaponise token approvals?
Wallet drainers are turnkey toolkits sold to phishing operators that convert a signed approval into an immediate sweep of the victim's wallet. The drainer family has been the highest-loss individual-wallet category across 2023-2026 because a single Permit2 signature on a malicious front end can authorise an unbounded allowance the drainer sweeps later.
The Inferno Drainer operation, profiled by Group-IB and tracked on the Scam Sniffer dashboard, ran an affiliate-network model where customers paid the drainer operators a share of stolen funds in exchange for the front-end kit and the spender contracts that received Permit2 signatures from victims (source: Group-IB investigation of Inferno Drainer; cross-corroborated by Scam Sniffer drainer dashboard). The typical inbound vector starts with a phishing attack (impersonated airdrop site, fake exchange landing page, or hijacked official front end) and routes the victim into a wallet-connect flow that requests a Permit2 signature for a high-value token. Pink Drainer and the historical Monkey Drainer (which shut down in March 2023 according to public reporting tracked by ZachXBT and Scam Sniffer) ran comparable models against earlier waves of users; the aggregate drainer-via-approval category has produced losses in the multi-hundred-million-dollar range across 2023-2026 per Scam Sniffer tracking.
The drainer ecosystem usually pairs the approval-phishing front end with infostealer payloads delivered through the same channel, which is the cross-reference into malware and crypto threats. The front-end manipulation step itself relies on the user landing on a malicious or hijacked page, which is why browser security for crypto and the DNS attack surface sit upstream of every drainer flow. The defensive takeaway is structural: if you sign approvals only on front ends you reached through bookmarks or hardware-confirmed addresses, the drainer pipeline cannot reach the signing step in the first place.
How do you check what approvals your wallet has granted?
You audit approvals by feeding your wallet address into a token-approval checker that reads token contract state on-chain and lists every spender with a non-zero allowance. The three primary tools are Etherscan's Token Approval Checker (Ethereum mainnet only), Revoke.cash (multi-chain UX), and MetaMask's Portfolio approvals tab (in-wallet).
Etherscan's tool at etherscan.io/tokenapprovalchecker accepts any address and renders the standing ERC-20, ERC-721, and ERC-1155 approvals with a one-click revoke button for each (source: Etherscan Token Approval Checker). The audit step itself does not require connecting a wallet; you can paste an address and read the approvals before deciding which to revoke. Revoke.cash is an open-source community tool built by Rosco Kalis that supports Ethereum mainnet alongside major Layer 2 networks (Polygon, Arbitrum, Optimism, Base) and other EVM chains, with a unified UI for cross-chain audit and revocation (source: Revoke.cash). MetaMask exposes the same audit through its Portfolio view (the Spending Caps tab), where users can review and revoke ERC-20 approvals without leaving the MetaMask UI; the Portfolio view is accessible through the wallet's main menu and shows a per-token breakdown of standing spenders.
The trade-offs between the three tools sit at the level of trust assumptions and scope. Etherscan is the most trustless option for Ethereum mainnet because the audit reads contract state directly from Etherscan's read-only block explorer; Revoke.cash adds multi-chain support and a more user-friendly UI in exchange for trusting Revoke.cash's web front end as the audit-time interface; MetaMask integrates the audit into the wallet you are already using. None of the three tools can audit approvals you signed under a different EOA, so a user with multiple wallets needs to run the audit against each address separately. A hardware wallet connected to any of the three tools can sign the resulting revoke transaction with on-device clear-signing.
How do you revoke a token approval, and what does the transaction cost?
You revoke an approval by sending an approve(spender, 0) transaction that overwrites the existing allowance to zero, which neutralises the spender's standing right to move your tokens. The cost is a standard ERC-20 storage write, typically 30-50k gas, which translates to roughly $0.50-$5 per revoke under 2024-2026 mainnet conditions.
The mechanical flow on Etherscan is to open the Token Approval Checker, connect the wallet that owns the approval, find the row for the spender you want to remove, click the revoke button, and confirm the resulting transaction in the wallet. Revoke.cash follows the same flow with multi-chain scope. MetaMask's Portfolio approvals tab exposes a comparable revoke button that routes the transaction through the same approve(spender, 0) write. In every case, the transaction has to be signed by the wallet that originally granted the approval; you cannot revoke an approval from a different address.
Gas-cost math matters because batching revocations against a wallet with twenty or thirty standing approvals can add up. A typical 35k-gas revoke at 10 gwei costs 0.00035 ETH (~$1-$2 at common ETH prices); the same revoke at 30 gwei during a busier mainnet window can cost three to five dollars. Layer 2 revocations on Arbitrum, Optimism, Base, and Polygon usually cost a fraction of a cent each, so a multi-chain hygiene pass on Revoke.cash often spends most of the budget on mainnet rows. Permit2 approvals are revoked by calling the Permit2 contract's lockdown function (which sets the allowance to zero) rather than the underlying token contract; both Etherscan and Revoke.cash expose this as the same revoke button.
Hardware wallets confirm the revoke transaction the same way they confirm any other on-chain write. Ledger Live and Trezor Suite render the calldata for clear-signing on the device, and the user presses confirm on the device itself after reading the function selector and the spender address. The crypto wallet glossary covers any term in this section that needs a reference lookup, and Ledger's clear-signing documentation explains the EIP-712 typed-data path that Permit2 signatures travel through (source: Ledger Academy EIP-712 and clear-signing).
The full revoke procedure below shows the seven-step flow on Revoke.cash, which is the most direct multi-chain revoke surface. Etherscan's Token Approval Checker and MetaMask Portfolio Spending Caps follow the same logical sequence with surface-specific UI differences.
Open a fresh browser tab (no other DApp tabs open) and navigate to revoke.cash. Do not click any "Revoke" link sent to you in DMs, email, or Discord; type the URL or use a verified bookmark. Phishing copies of revoke tools are common.
Connect the wallet that holds the approvals you want to remove. The connection is a standard wallet-connect handshake; the revoke tool reads your wallet address but cannot move funds without your per-revoke signature.
Review the approval list. Revoke.cash displays each approve() and Permit2 allowance as a row showing token, spender contract, allowance amount (often unlimited for legacy infinite approvals), and last-used date. Rows with unlimited allowance to a spender you don't recognise are the highest priority to revoke.
Filter by chain. Switch the chain selector at the top to each chain your wallet has touched (Ethereum mainnet, Arbitrum, Optimism, Base, Polygon, BSC, Avalanche, etc.). Each chain has its own approval set; an approve() on mainnet does not appear on Optimism, and vice versa.
Click "Revoke" on the row for the approval you want to remove. This builds an approve(spender, 0) transaction (or the Permit2 lockdown equivalent if the row is a Permit2 row). Your wallet popup shows the transaction with the spender address, the function selector, and the gas estimate.
Verify on the hardware-wallet device screen if you sign with hardware. Read the function name (should be approve or lockdown), the spender address (should match the row you intended to revoke), and the value (should be 0). Press confirm on the device.
Wait for the on-chain confirmation. The transaction appears on the chain's block explorer (Etherscan, Arbiscan, etc.) within a block or two. Refresh Revoke.cash to confirm the row now shows 0 allowance.
The seven-step procedure scales to any number of approvals; the only constraints are gas budget and signing patience. A first-time hygiene pass on a 2-3 year old EVM wallet typically uncovers 30-80 standing approvals across chains, of which 10-20 are infinite allowances to spenders the user has not interacted with in months.
What habits prevent approval-based drainage in the first place?
The single most consequential prevention habit is to sign approvals only on front ends you reached through bookmarks, hardware-confirmed URLs, or wallet-connect handshakes initiated from a trusted entry point. The drainer pipeline depends on the victim landing on a malicious or hijacked page; if the victim never lands there, the drainer never reaches the signing step.
Three habits compound the bookmark discipline. First, request a finite allowance instead of type(uint256).max when the wallet or DEX exposes the choice, and prefer Permit2's expiry-window mode over standing allowances for any high-value token. The Permit2 AllowanceTransfer mode lets the user set an explicit expiry, which automatically times the approval out and neutralises the long-tail exposure that a traditional approve write carries. Second, treat any unexpected approval request the way you would treat an unexpected wire transfer authorisation; if a site you do not recall navigating to is asking for a Permit2 signature on USDC or WETH, the safest move is to close the tab and reach the official site through a known-good entry point. Third, watch email security carefully because phishing email is one of the most common inbound vectors for approval-phishing campaigns, and a malicious link from a spoofed sender that lands the user on a hijacked DEX clone is the front half of the drainer pipeline.
Quarterly hygiene matters even when the bookmark discipline holds. Run the audit pass on Etherscan or Revoke.cash on a calendar reminder; revoke approvals to contracts you no longer interact with; keep an explicit list of which spenders should hold standing approvals against which tokens. The hygiene routine compounds the broader wallet risk posture from §1 and turns approval audit into a habit rather than an emergency response after a drainer hits.
How should you set up a hardened approval-hygiene posture in 2026?
A hardened approval-hygiene posture for 2026 has six layers: bookmark-only front-end navigation, finite allowances by default, Permit2 expiry windows on high-value tokens, quarterly audit-and-revoke passes, hardware-wallet clear-signing on every approval and revoke, and a withdrawal-destination check before consolidating funds back to a centralized exchange.
Set bookmarks for every DEX, lending protocol, and NFT marketplace you actually use, and reach the front end only through those bookmarks; if a search result lands you on what looks like the right site, double-check the URL before connecting the wallet. When the wallet asks for an approval amount, type a finite number that matches your immediate intent instead of accepting the infinite default, and on Permit2-supporting flows prefer the expiry-window mode. Schedule the quarterly audit-and-revoke pass on a calendar reminder, run it across all chains the wallet has touched, and budget the gas-cost math for the revoke transactions in advance. Pair the wallet with a hardware wallet that supports EIP-712 typed-data clear-signing so the device screen is the final approval surface that a hijacked front end cannot manipulate. Cross-reference upstream defences from supply-chain attacks so a compromised wallet extension or browser plugin cannot intercept the approval flow before it reaches the device.
From Blofin's operational perspective, the post-drainer cleanup pattern eventually surfaces at the centralized-exchange off-ramp regardless of which DEX or lending protocol the user originally signed the malicious approval on, and the operator-side controls that matter most are recognizing approval-spam patterns on hot wallets, applying drainer-signature heuristics to known-malicious withdrawal destinations, and corroborating peer-platform incident feeds when a compromised wallet shows up across platforms. The control framework Blofin treats as baseline for any platform that observes user funds moving across approval-mediated DeFi flows is approval-spam pattern detection on hot-wallet activity, withdrawal-destination heuristics against drainer-consolidation sweep wallets, and peer-platform incident-feed corroboration. Refresh the posture annually, after any disclosed drainer family expansion, and after any major standard change comparable to Permit2's November 2022 deployment.
Frequently asked questions
Is revoking a token approval safe, and does it cost gas?
Revoking a token approval is a standard on-chain write to the token contract that sets the spender's allowance to zero; it is one of the safest transactions you can sign because it can only reduce the spender's permissions and never grant new ones. The transaction costs a normal ERC-20 storage write, typically 30-50 thousand gas, which translates to approximately $0.50-$5 per revoke on Ethereum mainnet at common 2024-2026 base fees and ETH prices. Layer 2 revocations on Arbitrum, Optimism, Base, and Polygon usually cost a fraction of a cent each. The transaction has to be signed by the wallet that originally granted the approval, so you cannot revoke an approval from a different address.
What is the difference between approve(0) and a Permit2 lockdown?
approve(spender, 0) is the traditional revocation pattern that writes a zero allowance into the underlying ERC-20 token contract, neutralising a standing approval the user previously granted through approve(spender, value). Permit2 lockdown is the equivalent operation for approvals routed through the Permit2 contract: instead of writing to the ERC-20, the user calls Permit2.lockdown(...) which sets the Permit2-mediated allowance to zero. Both Etherscan's Token Approval Checker and Revoke.cash expose lockdown as the same revoke button when the underlying approval is a Permit2 one, and the gas cost is comparable.
How did the Inferno Drainer steal so much through token approvals?
The Inferno Drainer operation ran an affiliate-network model where the operators sold a turnkey drainer kit to phishing customers in exchange for a share of stolen funds; the customer ran an impersonated airdrop site, a fake exchange landing page, or a hijacked official front end that routed victims into wallet-connect flows requesting Permit2 signatures for high-value tokens. Per Group-IB's January 2024 takedown report and Scam Sniffer's dashboard, the cumulative theft attributed to Inferno Drainer was approximately $80 million across November 2022 to November 2023, with the broader drainer-via-approval category producing aggregate losses in the multi-hundred-million-dollar range across 2023-2026.
Should I use Revoke.cash or Etherscan's Token Approval Checker?
Use Etherscan's Token Approval Checker when you want the most trustless on-chain audit for Ethereum mainnet because it reads contract state directly from the block explorer; the audit step does not require connecting a wallet, only the revoke step does. Use Revoke.cash when you want multi-chain audit and revocation across mainnet, Polygon, Arbitrum, Optimism, Base, and other EVM chains in a single UI; Revoke.cash is open-source (built by Rosco Kalis) and widely used, with the trade-off that you trust the Revoke.cash front end as the audit-time interface. MetaMask's Portfolio approvals tab covers the in-wallet path and is convenient when you are already operating inside MetaMask.
How often should I review and revoke standing token approvals?
A quarterly review is the practical floor for an active DeFi user; users who interact only occasionally can usually run an annual review without meaningful additional risk, while users who interact daily with new protocols should consider monthly. The review should cover every chain the wallet has touched, every spender with a non-zero allowance, and explicit decisions on which spenders to keep and which to revoke. After any drainer-incident news that targets a protocol you have interacted with, run the review immediately rather than waiting for the next scheduled pass.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Ethereum Foundation's ERC-20 token standard documentation, the EIP-2612 Permit specification on eips.ethereum.org, Uniswap Labs documentation on the Permit2 contract, the Etherscan Token Approval Checker, Revoke.cash documentation, OpenZeppelin's ERC-20 contracts API reference, Group-IB's investigation of the Inferno Drainer operation, the Scam Sniffer drainer dashboard, and Ledger Academy's EIP-712 clear-signing reference. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.