Token approval security is the practice of controlling which smart contracts are allowed to move tokens out of your wallet, and for how much. Most decentralized applications cannot touch your tokens until you grant permission, and that permission often stays active long after the activity that needed it has ended.
Forgotten approvals are one of the quietest risks in a crypto wallet. They do not show up in your balance, yet they can let a compromised or malicious contract take funds at any time. This guide explains how approvals work, where they are abused, and how to manage them.
What an Approval Actually Grants
An approval is an on-chain record that says a specific address, called the spender, may transfer a certain amount of a certain token from your wallet. The spender is usually a smart contract, such as an exchange router or a lending protocol, that needs to pull tokens to complete an action.
Once granted, the spender does not need to ask again. It can move tokens up to the approved limit whenever its code allows, without any further signature from you. This is convenient for repeated use, because you avoid paying a fee to approve before every trade.
The same property is the risk. Your security now depends partly on the spender contract and on whoever controls it. If that contract has a bug, is upgraded maliciously, or was never honest to begin with, your approved tokens are exposed without you signing anything new.
How ERC-20 Allowances Work
On Ethereum and compatible networks, most fungible tokens follow the ERC-20 standard. It defines an approve function, which sets an allowance for a spender, and a transferFrom function, which lets that spender move tokens within the allowance.
The allowance is stored inside the token contract, not in your wallet software. That is why uninstalling a wallet app or switching devices does not remove approvals. They remain on chain until you change them, set them to zero, or the spender uses up the allowed amount.
Each token keeps its own allowance records, and each spender is tracked separately. A wallet that has used several applications may have dozens of active allowances across many tokens, most of which the owner has long forgotten about since the original transaction.
The Problem with Unlimited Approvals
Many interfaces request the maximum possible allowance, effectively unlimited, so users never have to approve the same token again. This saves fees and time, which is why it became a common default across decentralized applications.
An unlimited allowance means the spender can move your entire balance of that token, including any tokens you receive later. If the spender contract is exploited, the attacker may be able to drain every wallet that ever granted it unlimited access, not just recent users.
A limited approval for the exact amount needed caps the damage. The trade-off is an extra approval transaction the next time you use the application. For new, unaudited or rarely used contracts, that small cost is usually worth paying for the reduced exposure.
Signature-Based Permits
Newer approval methods let users grant permission by signing a message instead of sending a separate transaction. These are efficient, but because signatures cost nothing and often look harmless, they have become a favored tool for drainers.
Off-Chain Permit Signatures
Some tokens support a permit function, standardized for ERC-20 tokens as EIP-2612. The user signs a structured message stating the spender, amount and deadline, and anyone can submit it on chain to create the allowance.
Since no transaction is sent at signing time, users may not realize they have granted spending rights. A signed permit can be used later by whoever holds it.
Shared Approval Contracts
Some ecosystems use a shared approval contract. The user approves it once, and individual applications then request time-limited permissions through signed messages rather than new on-chain approvals.
This design can reduce long-lived allowances, but the initial approval to the shared contract is powerful. Every signature request routed through it deserves careful reading.
Deadlines and Nonces
Well-formed permit messages include a deadline, after which the signature is invalid, and a nonce, a counter that prevents the same signature from being reused.
A permit with a deadline far in the future, or an unexpectedly large amount, is a warning sign, especially when requested by a site you reached through a link.
NFT Collection-Wide Approvals
Non-fungible tokens, or NFTs, use their own approval functions. Standards such as ERC-721 and ERC-1155 include setApprovalForAll, which lets an operator move every token you hold in a collection, including items acquired in the future.
Marketplaces commonly request this approval so they can transfer an NFT when it sells. It is legitimate in that context, but it grants sweeping control. A malicious site asking for the same approval can transfer an entire collection in one transaction once the user signs.
Wallets usually display this request differently from token approvals, and some flag it explicitly. Treat any collection-wide approval as high-risk, confirm the operator address belongs to the marketplace you intended to use, and revoke it when you stop listing items there.
Reading an Approval Request Before Signing
Wallet prompts contain the information needed to judge an approval, but it is easy to skim past. A consistent reading routine turns the prompt into a meaningful checkpoint rather than a button to click through.
- Identify the action type: approve, permit signature, or collection-wide approval.
- Check the spender or operator address against the application’s published contract list.
- Look at the amount and edit it down to what you need if the wallet allows.
- Confirm the token being approved is the one you intended to use.
- Stop if the request appeared unexpectedly or on a site you did not navigate to directly.
Some wallets simulate the transaction and show expected balance changes. Simulation helps, but it cannot predict what a spender will do later with a granted allowance, so reading the approval itself remains essential.
How Approvals Are Abused
Approval abuse usually follows one of three patterns. A user signs an approval on a fake site that names the attacker’s contract as spender. A legitimate spender contract is later exploited through a bug. Or a project with upgradeable contracts changes its logic to misuse existing allowances.
In the first pattern, the theft can happen immediately after signing. In the other two, the risk may lie dormant for months, then materialize long after the user has forgotten the application. Old approvals to abandoned projects are particularly exposed, because nobody maintains those contracts anymore.
All three patterns share one condition: the allowance existed. Limiting amounts, revoking unused permissions, and keeping valuable holdings in a wallet that rarely approves anything remove that condition for most of your funds and reduce the damage from any single mistake.
Reviewing and Revoking Allowances
Revoking an approval means setting the allowance for a spender back to zero, or calling setApprovalForAll with a false value for NFTs. Each revoke is an on-chain transaction, so it costs a network fee, but it removes the spender’s ability to move those tokens.
- Use an approval checker built into a reputable block explorer or your wallet.
- Sort approvals by token value and revoke the largest unnecessary ones first.
- Remove approvals to applications you no longer use or do not recognize.
- Repeat the review on every network where the wallet holds assets.
Reach approval checkers through bookmarked addresses. Fake revoke tools exist, and they ask users to sign new approvals while claiming to remove old ones, which is exactly the opposite of what you intend.
What Revoking Cannot Do
Revoking stops future transfers by a spender, but it does not reverse transfers that have already happened. If an attacker has already used an allowance to move tokens, those tokens are gone, and revoking only prevents further losses from that particular permission.
Revoking also does not cancel signed permit messages that have not yet been submitted on chain. Depending on the token, invalidating a pending permit may require using its nonce or waiting for its deadline to pass. This is another reason to treat permit signatures with care.
If you suspect your private key itself is compromised, revoking approvals is not enough. An attacker with the key can sign new approvals or transfer funds directly. In that case the priority is moving remaining assets to a new wallet created on a clean device.
Approvals in Smart Contract Wallets
Smart contract wallets, which are wallets implemented as contracts rather than single keys, can add controls that ordinary wallets lack. Examples include spending limits, session keys that expire, and rules that block approvals to unknown addresses or above set amounts.
These features can contain approval risk, but they also add complexity. The wallet contract itself must be secure, and its recovery and upgrade mechanisms must be trustworthy. Misconfigured rules can give a false sense of protection while leaving important gaps open.
If you use a smart contract wallet, learn how it presents approvals and whether batched transactions can include approval steps you might overlook. Bundled actions are convenient, but they can hide an approval inside a sequence that looks like a single routine operation.
Guidance for Application Developers
Developers shape approval risk for every user of their application. Requesting only the amount needed for the current action, rather than defaulting to unlimited, reduces the damage if the application’s contracts are ever compromised.
Publishing a clear list of official contract addresses lets users verify spender addresses in wallet prompts. Interfaces should explain in plain language what each approval allows, and avoid asking for collection-wide or unlimited permissions when narrower ones would work just as well.
Upgradeable contracts that hold allowances deserve particular care. Upgrade powers should be protected by multisignature control and timelocks, so a compromised key cannot instantly turn a trusted spender into a drainer for every wallet that approved it in the past.
Making Approval Hygiene a Routine
Approval hygiene works best as a scheduled habit. Set a recurring reminder to review allowances on each network you use, and revoke anything you do not actively need. The fees for revoking are small compared with the exposure they remove.
Separate wallets by purpose. Keep long-term holdings in a wallet that never approves anything, use a second wallet for regular applications, and test unfamiliar projects with a third wallet holding only small amounts. Each approval mistake then affects only the funds in that limited wallet.
Wallet software is steadily improving at showing approvals in plain language and warning about risky spenders. Use those features, but keep reading prompts yourself. Understanding what you are signing remains the most reliable control as new approval methods continue to appear.