A token approval is a permission you grant to a smart contract, allowing it to spend a specified amount of a specific token from your wallet. In practical terms, when you use a decentralised exchange to swap tokens, or deposit into a yield farming protocol, or interact with any DeFi application, the protocol needs your permission to move tokens out of your wallet on your behalf. This permission is granted through a token approval transaction. Understanding what approvals are, why they are necessary, and how they can be exploited is foundational knowledge for any DeFi user.
Why Token Approvals Exist
The ERC-20 token standard used by most Ethereum-based tokens includes an approval mechanism by design. When you interact with a smart contract that needs to transfer your tokens, the contract cannot simply take them without your permission: it must first be authorised to do so. This authorisation is the approval transaction. Technically, an approval records an allowance: the token contract stores a mapping of which spender addresses are authorised to spend how much of your token balance. The DeFi protocol then calls the transferFrom function on the token contract, which checks the allowance and proceeds only if sufficient allowance exists. This architecture separates the permission step from the action step, giving users a theoretical point of control.
Unlimited vs Exact Approvals
When a DeFi interface asks you to approve token spending, you are often presented with a default of unlimited approval: permission for the smart contract to spend any amount of that token, forever. This is technically expressed as the maximum possible integer value (2^256 – 1). Unlimited approvals are convenient because they prevent you from needing to repeat the approval transaction each time you interact with the same protocol. However, they carry significant risk: if the protocol is exploited or behaves maliciously in the future, it can drain your entire token balance, not just the amount you intended to transact. Exact approvals limit the risk to the specific amount you are transacting, but require a new approval transaction for each subsequent interaction, incurring additional gas fees.
Best practice is to approve exact amounts whenever the DeFi interface allows it. When only unlimited approval is available, restrict your use to well-audited, long-established protocols with strong security track records. Newer or unaudited protocols should be treated with significantly more caution, especially when unlimited approvals are involved.
How Approvals Are Exploited
Token approvals are exploited in several ways. A malicious DeFi protocol can include hidden logic that uses your approval to drain your tokens immediately or at a future date. An otherwise legitimate protocol may be hacked, and the attacker uses the existing approvals to drain wallets. Phishing websites replicate legitimate DeFi interfaces and trick users into signing approval transactions to malicious contracts. Rug pulls may include a backdoor that allows the developers to use token approvals granted to the contract. In all these cases, the approval itself is the mechanism of theft. Active approval management, as covered in our guide on how to revoke smart contract approvals, is the direct defence against this category of attack.
Approvals vs Signatures
It is important to distinguish between approval transactions and signatures. An approval transaction is an on-chain transaction that modifies the allowance record in the token contract: it costs gas and is visible on the blockchain. A signature (such as a Permit2 or EIP-712 signature) is an off-chain cryptographic signature that can authorise token spending without an explicit on-chain approval transaction. Permit2, developed by Uniswap, is a standardised system that allows users to grant time-limited, amount-limited approvals via signature rather than a dedicated approval transaction, reducing gas costs. However, signing malicious Permit2 requests is just as dangerous as signing a malicious approval transaction. Always inspect signatures carefully before signing, as their contents are not always displayed clearly by wallet interfaces.
Checking Your Active Approvals
You can view all active token approvals for your Ethereum wallet or EVM wallet using tools such as Revoke.cash, Etherscan’s Token Approvals tab, or DeBank. These tools display each active approval by token, spender contract address, and approved amount. Regularly reviewing this list and removing unnecessary approvals is a basic but highly effective security measure. For a full walkthrough of the revocation process, see our guide on revoking smart contract approvals.
Approvals on Automated Market Makers
The most common context where you encounter token approvals is on automated market makers (AMMs) such as Uniswap, Curve, and their equivalents on other chains. To swap Token A for Token B, you must first approve the AMM’s router contract to spend your Token A. Similarly, when providing liquidity through yield farming or staking vs farming protocols, the protocol’s contract needs approval to deposit your tokens into the liquidity pool. On lending and borrowing protocols like Aave and Compound, you approve the lending contract to access your supplied tokens. Every DeFi interaction involves an approval at some point.
Solana Token Approvals
The Solana blockchain uses a different token standard (SPL tokens) with a different approval mechanism. Solana uses delegate authorities rather than unlimited allowances, and the approval model is structured around token accounts rather than contract allowances. Despite these technical differences, the practical risk is similar: granting spending permissions to smart contracts on Solana should be done thoughtfully, and token account delegates should be reviewed and revoked when no longer needed. The Phantom Wallet interface is beginning to incorporate approval management for Solana users.
Approval Management as a Security Habit
Treating approval management as a regular security habit, not a one-time cleanup, is the right approach. After every DeFi interaction, ask yourself: does this protocol still need permission to access my tokens? If not, revoke the approval. Set a monthly reminder to review your approval list on all active chains. Use exact amounts rather than unlimited approvals wherever possible. When in doubt about whether a DeFi protocol is trustworthy, interact with it through a secondary wallet holding only the minimum tokens needed for that interaction. This practice of self-custody awareness and active security management is what separates DeFi users who avoid costly incidents from those who do not.
Unlimited Versus Exact Approvals
Nearly every approval prompt hides a choice, and the default is almost always the riskier of the two.
An exact approval authorises a contract to move a specific quantity of a token. Once spent, the permission is used up. An unlimited approval authorises the contract to move that token from your wallet in any quantity, at any time in the future, until you revoke it. Both look identical in the interface, and the second is the standard default because it avoids a fresh approval on every subsequent trade.
The convenience is real. So is the exposure. An unlimited approval is a standing authority that outlives your interest in the application, and its risk is not fixed at the moment you grant it: it grows with your balance. Approving unlimited USDC to a protocol when you hold 200 dollars AUD leaves that same authority in place when you later hold 50,000 dollars AUD.
The exposure also transfers. You are not only trusting the contract as it is audited today, but every future upgrade, every admin key, and every party who might come to control it. Protocols get exploited long after launch, and an unlimited approval granted two years earlier is what turns someone else’s exploit into your loss. Unlimited token approvals covers the mechanics in more detail.
The sensible default is exact approvals for anything holding real value, and unlimited approvals only for contracts you use constantly and revisit regularly. Where an interface does not offer the choice, that itself is worth noticing.
Auditing What You Have Already Signed
Most wallets carry approvals their owner has entirely forgotten, granted to applications tried once and never opened again. They are still live.
Approvals are recorded on chain, so the list is public and checkable. Each entry shows the token, the contract holding the permission, and the amount authorised. Working through it, three categories are worth removing on sight: contracts you no longer use, unlimited approvals on tokens you hold in quantity, and anything you do not recognise at all.
Revoking is an on-chain transaction, so it costs a network fee, and there is a real trade-off on an expensive chain when the balance at risk is small. That trade-off disappears on an Ethereum Layer 2, where the cost is negligible. Our guide to revoking smart contract approvals covers the process step by step.
Two habits make this manageable rather than a project. Review approvals on a schedule you actually keep, quarterly for most people, and revoke immediately after any interaction with a contract you later have doubts about rather than waiting for the review. If a protocol you used is reported as exploited, revoking is the first action, ahead of reading about it.
Where a wallet has interacted with a great many contracts, the cleanest option is often to stop trying to clean it. Move the assets to a fresh wallet and retire the old one, which removes every outstanding approval at once because approvals attach to an address rather than to a seed phrase.
Approval Phishing: The Signature That Looks Routine
The most effective attacks on self-custody wallets do not steal a seed phrase. They persuade the owner to approve something, and the owner does it themselves.
The pattern is consistent. A page presents a reason to sign: claiming an airdrop, connecting to a mint, verifying a wallet, migrating to a new contract version, or unlocking a token that mysteriously appeared in your wallet. The prompt looks like the dozens of legitimate prompts you have approved before, because structurally it is the same prompt. What differs is what it authorises.
Signature requests worth stopping on include any approval on a token you hold in size, anything granting permission rather than transferring a stated amount, and off-chain signatures whose content you cannot read in plain language. That last category is how a wallet can be drained without any obvious approval at all, and wallet drainers covers how those work.
Urgency is the tell that survives every variation. Deadlines, limited allocations, warnings that your wallet is at risk unless you act now, and support accounts that appear unprompted after you post about a problem. Legitimate protocols do not need you to sign within the next ten minutes.
Two defences work reliably. Reach applications through your own bookmarks rather than through links in messages, search ads, or replies, because a convincing fake front end is inexpensive to build and impossible to distinguish visually. And keep the wallet that interacts with applications separate from the wallet that holds your long-term position, so that the worst version of this costs you a working balance rather than everything.
Key Takeaways
Token approvals grant smart contracts permission to spend your tokens, which is a necessary mechanism for DeFi. Unlimited approvals are convenient but create ongoing risk: old approvals from unused protocols remain exploitable indefinitely. Approve exact amounts where possible, use well-audited protocols, and regularly review and revoke unnecessary approvals using tools like Revoke.cash. Understanding approvals is inseparable from understanding how to avoid crypto scams and the broader category of DeFi risks that active users must manage.