What Are Token Approvals in Crypto: How Allowances Work and How to Revoke Them

The Quick Answer: What a Token Approval Is (and When You See It)

A token approval is an on-chain permission you grant that allows a smart contract or address to spend a specific amount of your tokens without requiring your signature for each transaction. When you try to swap USDC for ETH on Uniswap, deposit DAI into Aave, or list an NFT on OpenSea, the dapp prompts you to "approve" before the actual transaction. That approval isn't transferring your tokens—it's authorizing the contract to transfer them later on your behalf.

You'll recognize approval requests by their two-step pattern: first you sign an approval transaction that sets a spending limit, then you sign the actual swap or deposit. The approval step costs gas because it writes to the blockchain, recording your permission in the token contract's storage. Without this mechanism, you'd need to sign dozens of transactions for a single DeFi operation, making protocols like automated market makers or lending pools impossible to use efficiently.

Approvals solve a fundamental problem: smart contracts can't access your tokens directly. Unlike traditional apps where you log in and the service can debit your account, blockchain requires explicit permission for every token movement. The ERC-20 token standard defines three functions that make this work: approve, allowance, and transferFrom. Together, they let you delegate spending rights while maintaining control over your wallet.

Why Approvals Exist: How Dapps Spend Tokens on Your Behalf

Blockchains are permissionless by design—no contract can touch your tokens unless you explicitly allow it. This security model protects your assets but creates a UX challenge: complex operations like swapping tokens through multiple liquidity pools or borrowing against collateral require moving tokens in ways you can't predict in advance. If you had to manually sign every intermediate step, DeFi would be unusable.

Token approvals bridge this gap by establishing pre-authorized spending limits. When you approve Uniswap's router contract to spend 1,000 USDC, you're saying "this specific contract can transfer up to 1,000 USDC from my wallet until I revoke permission." The router doesn't take your tokens immediately—it gains the ability to call transferFrom when you later request a swap, pulling exactly the amount needed without another signature from you.

This delegation model enables the DeFi primitives you use daily. Lending protocols like Aave need approval to deposit your collateral and later liquidate it if needed. DEX aggregators need approval to route your trade across multiple AMMs. NFT marketplaces need approval to transfer your NFT when someone buys it. Each operation would require multiple manual signatures without approvals, making atomic transactions impossible and exposing you to front-running risks between partial steps.

The tradeoff is trust: you're betting the approved contract will only spend tokens as intended. A well-designed protocol like Uniswap uses audited router contracts with clear logic, but a malicious contract could drain your approved balance the moment you grant permission. This is why understanding approval mechanics isn't optional—it's foundational to staying safe onchain.

Under the Hood: ERC-20 Approve, Allowance, and transferFrom Explained

The ERC-20 standard defines token approvals through three interrelated functions that form a complete delegation system. When you grant an approval, you're interacting with the token contract itself, not the dapp requesting permission. This distinction matters: approvals are stored in the token's internal mappings, not in your wallet or the spender's contract.

The approve function is where the process starts. You call approve(spenderAddress, amount) on the token contract, which updates a nested mapping: mapping(address => mapping(address => uint256)). This stores your address (the owner), the spender's address, and the maximum amount they can transfer. The transaction requires gas because it's writing to blockchain state, typically $1-20 on Ethereum mainnet or under $0.10 on Layer 2s like Base.

The allowance function lets anyone query current permissions by calling allowance(ownerAddress, spenderAddress). This returns the remaining spendable amount—it starts at whatever you approved and decreases each time the spender uses transferFrom. Allowances are public information recorded on-chain, which is how tools like Revoke.cash can show you every approval you've granted across all tokens and dapps.

The transferFrom function is what the spender calls to actually move your tokens. When Uniswap's router executes your swap, it calls transferFrom(yourAddress, recipientAddress, swapAmount) on the token contract. The contract checks that swapAmount is less than or equal to your current allowance for that spender, transfers the tokens, then subtracts swapAmount from the allowance. If the allowance is insufficient, the transaction reverts with an error—this is why swaps sometimes fail after you've partially used an approval.

Here's the critical security point: the spender can call transferFrom at any time while an allowance exists, even months after you granted it. If that spender is a malicious contract or gets compromised later, your approved tokens remain at risk until you explicitly revoke by calling approve(spenderAddress, 0). The token contract has no concept of "intent" or "session"—it only checks whether the math allows the transfer.

Infinite Approvals vs Spend Caps: Pros, Cons, and When to Use Each

Most dapps default to requesting "infinite approval"—technically setting the allowance to the maximum uint256 value (2^256 - 1, roughly 1.15 x 10^77). This astronomical number means the spender can transfer your entire token balance and more, functioning as unlimited permission until you revoke it. Uniswap, 1inch, and most DEXs use this pattern because it eliminates the need for repeat approvals: one transaction lets you swap that token pair forever.

The convenience is real. If you trade USDC for ETH weekly on the same DEX, infinite approval saves you gas and clicks on every subsequent trade. For power users making dozens of DeFi transactions daily, the UX improvement is significant—you're not constantly approving small amounts and paying fees. The allowance never depletes because it's effectively limitless, so the protocol can call transferFrom repeatedly without your balance ever exceeding the approval cap.

But infinite approvals concentrate risk. If the approved contract has a vulnerability discovered months later, or if the dapp's frontend gets compromised and starts serving a malicious contract address, that "unlimited" permission becomes a vector for total wallet drainage. The largest DeFi exploits often involve attackers finding ways to abuse existing approvals, either through contract bugs or by tricking users into approving malicious addresses through phishing sites.

Limited approvals let you specify an exact amount—approve only what you need for one transaction. If you're swapping 100 USDC, approve 100 USDC. After the swap, the allowance drops to zero, and the spender can no longer access your tokens. This is safer for one-off interactions with new protocols or when trying a dapp you don't fully trust. The downside is friction: each transaction requires a fresh approval, doubling your gas costs and adding an extra signing step.

When to use each approach:

Infinite approval: Protocols you use frequently (daily DEX, your main lending platform), well-audited contracts (Uniswap V3, Aave), tokens you actively trade and monitor
Limited approval: New or unaudited protocols, one-time swaps, tokens with large balances you rarely move, anytime you're unsure about the contract's safety
Hybrid strategy: Approve exact amounts for new dapps, upgrade to infinite after repeated successful use if you trust the protocol

Some tokens like Tether (USDT) have built-in safeguards that require you to set allowance to zero before approving a new non-zero amount, preventing race conditions where a malicious spender tries to spend both the old and new allowance in the same block. This forces deliberate revocation, making exploits harder but adding an extra step to normal workflow.

Where Approvals Live: Per Token, Per Spender, Per Chain

Token approvals are highly specific—they exist in exactly one token contract, for exactly one spender address, on exactly one blockchain. This precision prevents cross-contamination but creates management complexity when you interact across multiple protocols and chains.

Per token contract: Your USDC approval for Uniswap is completely separate from your DAI approval for Uniswap. Each ERC-20 token maintains its own approval mappings in its own contract storage. If you want to provide liquidity in a USDC/DAI pool, you'll sign two approval transactions: one calling approve on the USDC contract, another on the DAI contract. Both target the same spender (the liquidity pool router), but the permissions are isolated. This means revoking USDC approval has zero effect on your DAI exposure.

Per spender address: Approving USDC for Uniswap doesn't grant permission to Sushiswap or any other protocol. The token contract checks the exact spender address passed to transferFrom. This isolation is crucial for security: even if one protocol gets exploited, only tokens approved to that specific spender are at risk. Your other approvals remain safe because they reference different addresses. The tradeoff is you'll accumulate dozens of approvals across protocols, each requiring separate management.

Per blockchain: An approval on Ethereum mainnet has no relationship to an approval on Base, Arbitrum, or any other EVM chain—even for the "same" token. USDC on Ethereum is a different contract at a different address than USDC on Base. When you bridge USDC from Ethereum to Base, you're working with a new token contract that starts with zero approvals. You'll need to approve dapps on Base separately, even if you've already approved them on mainnet. This chain-specificity means your approval security posture varies by network.

This three-dimensional specificity (token × spender × chain) explains why experienced users accumulate hundreds of active approvals over time. Each new token-dapp-chain combination adds another entry. Tools like Revoke.cash aggregate these across chains, but you'll still need to submit separate revocation transactions on each network, each costing gas. On Ethereum mainnet, auditing and revoking 20 approvals might cost $100-200 in total. On Base or other Layer 2s, the same cleanup costs under $2, making frequent approval hygiene finally practical for everyday users.

Real Risks and Failure Modes: Phishing, Malicious Contracts, and Stale Approvals

Token approvals open three major attack vectors that account for over 70% of DeFi exploits: malicious spenders, compromised frontends, and forgotten permissions. Understanding these failure modes helps you recognize threats before signing.

Phishing contracts are the most common threat. Attackers create fake versions of popular dapps with identical UIs but substitute the legitimate contract address for one they control. When you approve tokens to their malicious contract, they immediately drain your balance using transferFrom. The transaction looks normal in your wallet—you're calling approve on a real token contract—but the spender address is wrong. Always verify contract addresses match official documentation before approving, and bookmark authentic dapp URLs to avoid look-alike domains.

Compromised frontends are more insidious because the dapp itself was legitimate when you first approved it. If attackers inject code into a protocol's website after you've granted infinite approval, they can prompt you to interact with a new malicious contract or modify transaction parameters to drain approved tokens. Your existing approvals don't automatically become dangerous, but the compromised UI can trick you into signing additional transactions that exploit them. This is why regular approval audits matter—revoke permissions to dapps you no longer actively use, reducing your exposure if they get hacked later.

Stale approvals accumulate naturally as you experiment with new protocols or stop using old ones. That DEX you tried once in 2023 still has permission to spend your tokens in 2026. If that protocol's contract has an undiscovered vulnerability or gets upgraded unsafely, your dormant approval becomes a liability. Many users discover they have 50+ active approvals across tokens they forgot they owned, creating a sprawling attack surface. The solution is periodic hygiene: audit and revoke unused approvals quarterly, especially for tokens with significant balances.

Race condition exploits target the approve function itself. If you have an existing allowance of 100 tokens and call approve to change it to 50, a malicious spender watching the mempool could call transferFrom for the original 100 tokens, then after your transaction confirms, immediately call transferFrom again for the new 50 tokens—stealing 150 total. This is why some tokens like USDT force you to set allowance to zero before approving a new non-zero amount, preventing the double-spend window.

Wallet drainers use signature phishing to get approvals without obvious approval transactions. They present a message that looks like "Sign in to Opensea" but actually contains an encoded EIP-2612 permit signature (covered next section) that grants token spending rights. Because permits don't require a transaction, victims don't see the usual MetaMask approval screen with token amounts. By the time they realize something's wrong, multiple tokens have been drained via the signed permit. This attack specifically exploits user confusion about what signatures can authorize.

The common thread: approvals persist indefinitely until explicitly revoked. Unlike sessions that expire, an approval granted today remains valid years later unless you take action. This makes them powerful for user experience but dangerous for security if you lose track of what you've authorized.

How to Check Your Approvals: Block Explorers and Trusted Revocation Tools

Finding your active approvals requires querying each token contract's allowance mapping for your wallet address across all spenders and chains—a task impossible to do manually. Two classes of tools make this practical: block explorers with approval tabs and specialized revocation services.

Block explorers like Etherscan or Basescan offer approval viewers if you know where to look. Navigate to a specific token contract address (not your wallet), click the "Read Contract" tab, and use the allowance function to check one spender at a time. This works but requires knowing which tokens you've approved and which spenders to check—impractical for auditing your full approval surface. Some explorers added approval tabs that list all approvals for an address, but coverage varies by chain and requires switching networks individually.

Revoke.cash is the gold standard for approval management. Connect your wallet, select a chain, and it displays every token approval you've granted with the current allowance amount, spender contract name, and last activity date. The interface groups approvals by token, showing which protocols have access to each asset. For each approval, you can click "Revoke" to generate a transaction that sets allowance to zero. Revoke.cash is open-source and widely trusted by the community, having facilitated over 1 million revocations. It supports 100+ EVM chains including Ethereum, Base, Arbitrum, Polygon, and Optimism.

Etherscan's Token Approvals tab (under "More" dropdown on your address page) shows approvals specific to Ethereum mainnet. It lists each token, approved spender, and allowance value, with direct links to revoke. This is simpler than Revoke.cash for Ethereum-only users but doesn't aggregate cross-chain or provide as much context about spender reputations. Basescan offers similar functionality for Base network approvals.

How to audit systematically:

Start with your most-used chains: Check Ethereum mainnet first (highest fees, highest value), then Base or your primary L2 (where you interact most), then secondary chains
Sort by token value: Focus on stablecoins and high-cap tokens first (USDC, USDT, ETH, major holdings), then review smaller balances
Identify unfamiliar spenders: If you see an approval to a contract address you don't recognize, search it on Etherscan to find the associated protocol. Revoke anything unrecognizable
Check last activity dates: Approvals you granted 6+ months ago to protocols you no longer use are prime candidates for revocation
Review allowance amounts: Infinite approvals (shown as max uint256 or "Unlimited") warrant extra scrutiny compared to specific amounts that may have already been fully spent

Red flags that warrant immediate revocation:

Approvals to contracts that don't show up in Etherscan's verified contracts list
Protocols you've never heard of or don't remember interacting with
Infinite approvals on tokens with balances over $1,000
Any approval granted through a link you clicked in Discord/Telegram/email
Spender addresses flagged as "suspicious" by block explorer labels

Run this audit quarterly at minimum, or monthly if you actively use new DeFi protocols. Set calendar reminders—most wallet drains succeed because users forget about approvals they granted years earlier to protocols that since became compromised or were malicious from the start.

How to Revoke Approvals Safely: Step-by-Step, Costs, and What Changes After

Revoking an approval means calling the same approve function you used originally, but setting the allowance to zero: approve(spenderAddress, 0). This updates the token contract's mapping to prevent any future transferFrom calls from that spender. The process requires a transaction with gas, just like the original approval.

Step-by-step revocation process:

Visit Revoke.cash or your block explorer of choice and connect your wallet to the correct network
Find the approval you want to revoke by searching for the token or filtering by spender protocol
Click "Revoke" or "Set Allowance to 0"—this generates a transaction calling approve(spenderAddress, 0) on the token contract
Review the transaction in your wallet—verify you're calling approve on the correct token contract with amount = 0 and the intended spender address
Confirm and pay gas—on Ethereum mainnet expect $5-20 per revocation, on Base/Arbitrum typically $0.01-0.10, on Polygon often under $0.01
Wait for confirmation—once the transaction settles, the spender can no longer transfer your tokens

What changes after revocation:

The spender's allowance for your address in that token contract becomes 0
Any attempt by the spender to call transferFrom will fail with "insufficient allowance" error
Your token balance remains unchanged—revocation doesn't move tokens, it just removes permission
You still own the same amount of tokens in the same wallet
The approval slot in the contract's mapping still exists (you can't "delete" it), but it's set to zero

What doesn't change:

Other approvals (different tokens, different spenders, different chains) remain active
Revocation is not retroactive—if the spender already called transferFrom before you revoked, those transfers are final
You can re-approve the same spender later with a new approve call

Cost optimization strategies:

Network	Typical Revoke Cost	When to Batch
Ethereum	$5-$20	Revoke 5+ at once
Base	$0.01-$0.10	Revoke individually
Arbitrum/Optimism	$0.10-$0.50	Revoke individually
Polygon	< $0.01	Revoke liberally

On high-fee networks like Ethereum, you might accumulate 10-20 revocations and execute them during off-peak hours (weekends, late nights UTC) when gas prices dip. Tools like Revoke.cash don't support native transaction batching, but you could use a smart contract wallet with multicall to bundle multiple approve(spender, 0) calls into one transaction—though this adds complexity most users don't need.

Common failure scenarios:

"Transaction failed: token contract not verified"—you're interacting with a scam token; ignore and don't pay gas to revoke
"Out of gas error"—your gas limit was too low; retry with 1.5x the estimated gas
"Revoke button doesn't appear"—allowance may already be zero from prior revocation or full spending; check on-chain to confirm
"Can't find my approval"—you might be on the wrong chain; switch networks in your wallet

After revoking, test that the change took effect by checking allowance(yourAddress, spenderAddress) in the token contract's "Read Contract" interface—it should return 0. If you later want to use that dapp again, you'll need to approve it fresh, which is the point: you're deliberately choosing when to grant permission rather than leaving it open indefinitely.

Special Cases: Gasless Approvals, NFTs, and Complex Spenders

Three variations on standard ERC-20 approvals handle specific use cases with different security tradeoffs: signature-based permits, NFT approvals, and delegated spender contracts.

EIP-2612 Permit: Gasless Approval Via Signatures

EIP-2612 introduced the permit function that lets you approve via off-chain signature instead of a transaction. Instead of calling approve and paying gas, you sign a typed data message containing the spender address, amount, deadline, and nonce. The spender then submits your signature along with their transferFrom call, and the token contract verifies your signature and updates the allowance in the same transaction that moves tokens.

Benefits are clear: one transaction instead of two, no gas cost for the approval step, and better UX for first-time users who don't need to understand approvals at all. Protocols like 1inch heavily use permit for gasless swaps. The signature effectively says "I pre-approve X tokens for spender Y, valid until timestamp Z," with the smart contract enforcing these terms.

Security considerations differ from standard approvals. Permit signatures can be phished more easily because users get desensitized to signing "login" messages and may not scrutinize the structured data fields. A malicious site can present what looks like an authentication popup but is actually a permit signature granting token access. Additionally, signatures have deadlines but no "revoke" mechanism—once signed, the permit remains valid until the deadline unless you use it or the spender never submits it. Some implementations allow deadline = max uint256 (infinite), which is riskier than standard approvals since you can't revoke before the spender uses it.

Best practices for permit signatures:

Always read the decoded signature data in your wallet—verify token address, spender, amount, and deadline
Use short deadlines (1 hour) for untested protocols
Treat "sign to approve" with same suspicion as "approve transaction"
Prefer permit-supporting dapps for one-off swaps, standard approvals for repeated use

NFT Approvals: setApprovalForAll and Single-Token Approve

NFTs follow ERC-721 or ERC-1155 standards with different approval mechanics than fungible tokens. The most powerful (and dangerous) is setApprovalForAll(operator, true), which grants an operator address permission to transfer every NFT you own in that collection—not just one specific token, and not limited by amount. OpenSea and other marketplaces request this to enable listing any NFT from your collection without per-item approvals.

This creates systemic risk: if the marketplace contract or frontend gets compromised, attackers can drain your entire NFT collection with one transferFrom call per token. Unlike ERC-20 unlimited approvals that still respect token balances, setApprovalForAll is truly unlimited across all current and future tokens you receive in that collection. The convenience is worth it for collections you actively trade, but toxic for valuable 1/1s or blue-chip holdings you rarely list.

ERC-721 also supports single-token approval via approve(operator, tokenId), which limits permission to one specific NFT. This is safer for valuable pieces but requires separate approval for each listing, making it impractical for sellers managing dozens of items. Most marketplaces default to setApprovalForAll for this reason.

Managing NFT approvals:

Use setApprovalForAll only for collections you list frequently on trusted marketplaces
Revoke via setApprovalForAll(operator, false) when you finish selling
For high-value 1/1s, use dedicated vaults (smart contract wallets) and only approve when actively listing
Check NFT approvals separately from ERC-20s—Revoke.cash handles both, but block explorers may hide NFT approvals in different tabs

Routers, Aggregators, and Vault Contracts as Spenders

Many protocols use proxy patterns where you approve a router contract that doesn't hold logic, delegating to implementation contracts via delegatecall. Uniswap V3's router, for example, is a thin interface that calls pool contracts. You approve the router address, and it can execute swaps across any pool, but the router itself can't upgrade or change behavior without deploying new contracts (which would require new approvals).

DEX aggregators like 1inch and Matcha use a different pattern: you approve their aggregator contract, which then routes your trade across multiple DEXs to find the best price. Your approval to the aggregator gives it wide latitude to interact with any liquidity source it wants, but you're trusting the aggregator's logic to optimize your trade rather than steal tokens. Audits and track records matter enormously here—established aggregators have financial incentive to protect their reputation.

Vault contracts for yield optimization (Yearn, Beefy) require approval to deposit your tokens, then the vault uses those tokens to farm across multiple protocols. You're essentially giving the vault smart contract full control over your deposited balance, trusting its strategy logic. Some vaults have timelocks or governance delays for upgrades, reducing rug-pull risks, but you need to research each protocol's security model before approving.

Key principle: The more intermediary layers between your approval and actual token use, the more contracts you're trusting. Direct protocol approvals (Uniswap pool, Aave lending market) have narrower risk than aggregators (1inch) or vaults (Yearn), which themselves approve other protocols on your behalf. This doesn't make them unsafe—just requires proportional due diligence.

Approvals on Layer 2s: Faster, Cheaper Revokes and Cross-Chain Gotchas

Layer 2 networks like Base, Arbitrum, and Optimism inherit Ethereum's ERC-20 approval mechanics identically—the same approve, allowance, and transferFrom functions work the same way. The critical difference is cost: revocation transactions that cost $10-20 on mainnet cost under $0.10 on Base, making approval hygiene practical for users who previously couldn't afford regular audits.

Base-specific considerations:

Base processes blocks every 2 seconds compared to Ethereum's 12, so approval transactions confirm faster—typically under 30 seconds versus 1-3 minutes on mainnet. Revoke.cash shows this practically: connecting to Base returns results instantly because querying recent state is cheaper. When you revoke an approval on Base, the transaction settles in seconds and costs pennies, removing the "should I wait for cheaper gas?" calculation that plagues Ethereum cleanup.

Base's low fees enable stricter approval hygiene:

Revoke after single-use interactions with new protocols
Use limited approvals instead of infinite for moderate-frequency trades (weekly vs. daily)
Audit and clean approvals monthly instead of quarterly
Experiment with new DeFi primitives without worrying about accumulated approval costs

Base-native protocols like Aerodrome (the largest Base DEX by TVL) work identically to Ethereum DEXs for approvals—you approve tokens to the Aerodrome router before swapping or providing liquidity. The router address differs from Ethereum DEXs, and approvals don't transfer between chains, but the security principles remain: verify the contract address, consider limited approvals for first use, and revoke if you stop trading there.

Cross-chain approval pitfalls:

The biggest gotcha is assuming approvals work across chains. If you approved USDC to Uniswap on Ethereum, then bridged USDC to Base and tried to swap on Uniswap there, you'd hit an "insufficient allowance" error. This confuses users who think "I already approved Uniswap," but the Base USDC contract at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 is completely separate from Ethereum USDC at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. Different contract = different approval mapping = you need to approve again on Base.

This per-chain approval requirement multiplies your attack surface as you use more L2s. If you trade on Ethereum, Base, Arbitrum, and Optimism, you'll have separate approvals for each network—same protocols, different chains. Revoking on Ethereum doesn't affect Base approvals. Tools like Revoke.cash handle this by letting you switch networks, but you'll submit separate revocation transactions on each chain (though each costs under $0.10 on L2s).

Bridging and approvals:

When you bridge tokens between chains using a bridge contract, the bridge needs approval on the source chain to lock or burn your tokens. This creates another spender to audit: bridge contracts on each network you use. The wrapped version on the destination chain is a new token contract with zero approvals initially. This means:

Approve tokens to bridge contract on Chain A (e.g., Ethereum)
Bridge executes, minting wrapped version on Chain B (e.g., Base)
Approve wrapped tokens to dapps on Chain B
If bridging back, approve wrapped tokens to bridge on Chain B
Result: 2-4 separate approvals for a round-trip journey

L2 security benefits:

Beyond cost, Base and other L2s inherit Ethereum's security properties for approvals—no chain-specific vulnerabilities in the approval mechanism itself. The EVM is identical, so wallet drainer attacks, phishing, and malicious contracts work the same way. However, faster block times on Base mean malicious contracts can drain approvals slightly faster once triggered (seconds instead of minutes), making immediate revocation even more important if you suspect compromise.

The practical takeaway: use L2s as your primary DeFi environment to enable affordable approval hygiene, but remember each chain requires independent approval management. Budget $1-5 per quarter to audit and clean all your L2 approvals, a 95% reduction from Ethereum's $50-200 cleanup costs that makes security finally accessible.

Best Practices: A Simple Approval Hygiene Checklist for Everyday Users

Token approval security boils down to three habits: verify before you approve, audit what you've approved, and revoke what you don't need. This checklist operationalizes those principles without requiring smart contract expertise.

Before Approving:

Action	Why It Matters	How to Do It
Verify contract address	Phishing sites use fake addresses	Compare dapp's request to official docs or Etherscan's verified contracts
Check approval amount	Infinite approvals concentrate risk	Read the pop-up: "Unlimited" or huge numbers = infinite; consider limiting
Use bookmarks only	Typosquatting domains trick you	Never click Discord/Telegram links; manually type or use saved bookmarks
Research new protocols	Unaudited contracts may be malicious	Search "[protocol name] audit" and "exploit" before first approval

Quarterly Audit Routine:

Set calendar reminder (first weekend of quarter)
Visit Revoke.cash and connect wallet
Check Ethereum mainnet first: Sort by token value descending
Revoke anything meeting these criteria:
- Spender address you don't recognize (search on Etherscan to identify)
- Protocols you haven't used in 3+ months
- Tokens with balance >$1,000 and infinite approval
- Any approval granted before your last audit (=stale)
Repeat for Base, Arbitrum, and other active chains
Budget time and fees: 30 minutes and $10-30 total (mostly Ethereum mainnet)

Daily Transaction Hygiene:

After trying a new protocol once, decide: frequent use (keep approval) or one-off (revoke immediately)
Use permit-enabled dapps for one-time swaps to avoid creating new approvals
If a protocol asks for approval but you didn't initiate the action, reject and investigate
Review your "Pending" transactions in wallet for unexpected approval requests

Warning Signs That Demand Immediate Action:

You see transactions you didn't authorize in your wallet history → Disconnect wallet, revoke all approvals, move funds to new wallet
A dapp you've used gets reported for exploits → Revoke your approvals to that protocol across all chains
You approved something via a Discord link → Assume compromise, revoke immediately
Your token balance decreased without your action → Revoked too late, but revoke remaining approvals to prevent further drainage

Secure-by-Default Settings:

If your wallet supports it:

Enable "Transaction Simulation" to preview token movements before signing
Set default approval amounts to "Exact" instead of "Unlimited"
Use hardware wallet for approvals to high-value tokens
Consider a dedicated "DeFi wallet" separate from your cold storage, approving only from the DeFi wallet so a compromise doesn't affect your main holdings

This routine costs $10-30 per quarter and 30 minutes of attention—cheap insurance against wallet drainers that steal millions annually from users who granted approvals and forgot about them. The discipline matters more than the specific tools: pick Revoke.cash or Etherscan, choose a schedule you'll actually follow, and build the habit of treating approvals as temporary permissions that require active renewal.

FAQs and Troubleshooting: Common Questions and Fixes

Q: My swap transaction failed with "insufficient allowance" but I already approved this token. What happened?

You likely approved an amount smaller than the current swap requires, or you've used up your previous approval through earlier transactions. Check your current allowance for this spender using Revoke.cash or Etherscan's token contract interface (allowance function). If it's zero or too low, submit a new approval with the amount needed. Some wallets show "approved" status cached from before, not reflecting that allowance depleted.

Q: Do I need to re-approve after revoking?

Yes. Revocation sets allowance to zero, removing all permission. If you later want to use that dapp again, you'll need to grant a fresh approval. This is intentional design—forcing you to consciously choose when to re-authorize rather than leaving permissions open.

Q: Is infinite approval ever actually safe?

It depends on your risk tolerance and the specific protocol. Infinite approvals to battle-tested, audited contracts like Uniswap V3 or Aave V3 that you use frequently are reasonable for many users—the convenience outweighs low exploit risk. But infinite approval to a 2-week-old yield farm with unverified contracts is reckless. Consider: protocol age (1+ years safer), audit status (multiple audits better), your usage frequency (daily = infinity makes sense, monthly = don't), and token value (infinite on $100 stablecoin vs. $50k ETH requires different calculus).

Q: Can someone steal my tokens just by getting my wallet address?

No. Approvals require your signature via a transaction or permit. Knowing your address lets someone see your approvals (they're public on-chain) but can't create new ones. The danger is phishing—tricking you into signing approvals to malicious spenders, not passive theft.

Q: What happens if I approve a token and then transfer that token to a different wallet?

Approvals are tied to the owner address, not the tokens themselves. If you approved 100 USDC to Uniswap from Wallet A, then sent those 100 USDC to Wallet B, Uniswap can no longer touch them because the approval mapping is Wallet A → Uniswap → 100 USDC. Wallet B starts with zero approvals for all spenders. This is why moving tokens to a fresh wallet is a nuclear option for clearing all approvals.

Q: Why does MetaMask sometimes show unlimited approval as a huge number like "115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457"?

That's the maximum uint256 value (2^256 - 1) in base-10. Contracts use this number because it's effectively infinite—no ERC-20 has that many tokens in supply. MetaMask shows the raw number rather than "unlimited," which can cause confusion. Some wallets and dapps now detect this specific value and display "Unlimited" or "Infinite" instead for clarity.

Q: I approved a token months ago and haven't used it since. Is it still active?

Yes. Approvals persist indefinitely until you explicitly revoke them. The token contract doesn't track or expire unused allowances. That 6-month-old approval is exactly as valid as one you granted today, which is why quarterly audits are crucial.

Q: Can I set up automatic approval revocation after 30 days?

Not natively in the ERC-20 standard. Some newer token standards propose time-limited approvals, but they're not widely adopted. Third-party tools can't auto-revoke for you without holding your private keys. The best alternative is calendar reminders for manual audits. In the future, account abstraction wallets may support policy-based automatic revocation, but that's not available yet for standard EOA wallets.

Q: Do hardware wallets protect me from approval-based exploits?

Partially. Hardware wallets prevent your private key from being stolen, so you can't be directly drained. But if you sign an approval transaction to a malicious contract using your hardware wallet, you've still granted permission. Hardware wallets make you more deliberate about signing (physical button press) which helps you catch suspicious requests, but they don't prevent you from approving the wrong spender. Always verify the spender address and amount before confirming on your Ledger or Trezor.

Q: What's the difference between "revoke" and "update" on Revoke.cash?

"Revoke" sets allowance to zero, removing all permission. "Update" lets you change the allowance to a specific non-zero amount, useful if you want to reduce an infinite approval to a limited one without fully revoking. Both require transactions with gas.

Q: If a protocol gets hacked after I approved it, am I automatically at risk?

Only if the hack involves the approved contract itself or gives attackers control to call transferFrom. Many DeFi hacks target different vulnerabilities (oracle manipulation, flash loan exploits) that don't involve spending user approvals. But if the approved contract gets upgraded maliciously or attackers compromise keys controlling a proxy, then yes—your approval becomes a vector. This is why revoking approvals to protocols you no longer use limits blast radius of potential future exploits.