What ERC-20 Approval Actually Controls
An ERC-20 approval is permission for a smart contract or exchange to transfer tokens from your wallet, not an instruction to buy a token or pay a fee immediately. When you sign an approval, you normally specify a spender and an amount. The amount may be a fixed number, such as 100 USDC, or the maximum uint256 value often displayed as “Unlimited.” The transaction itself can be free apart from network gas, while the permission remains stored until it is replaced, revoked, or the token contract expires it. A spender cannot normally move more than the approved amount, but it can move any amount up to that ceiling without asking you for another signature.
Also worth reading: How Do You Safely Revoke Token Approvals in Web3 Wallets? · How Do You Check and Control Wallet Permissions Before Losing Money? · How Do PCI DSS Evidence Workflows Work for Merchants in 2026?
This distinction explains why an unlimited approval can be dangerous even when a particular payment succeeds. A decentralized exchange, bridge, payment processor, or other application may need approval to interact with your tokens, and some interfaces request unlimited permission to reduce repeated transactions. However, that permission can remain available after you have forgotten the application or stopped using it. If the approved contract is compromised, upgraded, malicious, or operated with a flawed withdrawal function, attackers may be able to transfer the approved balance or a portion of it. Approval security therefore depends on both the contract you trust and the exact allowance you grant.
Why Unlimited ERC-20 Approvals Are Risky
The largest possible allowance is a uint256 value, commonly called “unlimited,” even though it is not literally infinite. Many token contracts implement allowance behavior that subtracts the amount spent and restores the remaining allowance, so a single unlimited approval can remain usable after transfers. If the spender can be induced to call transferFrom repeatedly, the allowance may be spent later without another wallet confirmation. An allowance is not automatically a direct theft event, but it is an open payment authorization that can become valuable to an attacker.
The practical risk is often misunderstood. You do not need to approve a token before receiving it, and you do not need to approve a token simply because it appears in your wallet. Approval matters when a contract needs to pull the token from your address. A token balance alone is not normally spendable by an unrelated contract, while an active allowance is. This is why checking token allowances is more useful than checking only whether a token looks legitimate or whether a website has a familiar name.
Unlimited approval can also create a long-lived exposure. A user may approve a contract in 2026 and still have that authorization in 2028 because nothing automatically expires it. Revoking the allowance does not reverse transfers that already happened, so prompt revocation matters even more when a wallet has held the authorization for years. The safe default is to use exact allowances whenever the application supports them, revoke unused permissions, and avoid signing an approval in a message or QR code that you cannot independently inspect.
How to Review an Approval Before Signing
Before signing, identify the chain, token, spender contract, allowance, and transaction context. The network matters because a token address on Ethereum may correspond to a different or nonexistent token on another chain. The spender is usually a contract address, not the human-readable brand shown in the interface. A fraudulent interface can display a familiar name while presenting an attacker-controlled address, so copy the contract address from the application’s documentation or block explorer and compare it with the address being requested. Approval signatures can also arrive through wallet deep links or QR phishing, so the wallet preview must be treated as the authoritative description of what you are signing.
Review the allowance in the wallet preview. “Unlimited,” “Max,” or the maximum uint256 value deserves extra attention. An exact approval should cover the expected payment with a reasonable margin, such as 105 USDC for a 100 USDC payment, rather than the entire token supply. A margin can be sensible for a recurring merchant relationship, but it is less suitable for a one-time swap. Also check whether the approval is for a token transfer, a permit signature, or another token standard, because the apparent wording may conceal a different authorization.
Do not rely on a website’s green checkmark, token logo, or claim that approval is “official.” Smart-contract addresses are the stronger identity control, and a legitimate contract can still contain risky permission logic. A wallet cannot generally tell you whether a contract is honest; it can show the destination and allowance but not guarantee future behavior. For a payment app, use a known contract, verify the domain and chain, and reject requests that are larger or broader than the transaction requires.
Practical Steps for Reducing ERC-20 Exposure
The safest process is to connect through the application’s verified website, select the intended network, inspect the wallet request, and approve only the amount needed. For a one-time payment, an exact allowance is usually preferable. For recurring payments, consider whether a limited allowance can be replaced automatically before the next charge, and whether the service supports a fixed spending cap. If the application insists on unlimited approval, understand the reason and revoke the approval after the activity ends. Permission dashboards can help, but a dashboard is only useful if it identifies the chain and token correctly.
Revoke permissions from a reputable wallet or allowance-management interface, then confirm the revocation transaction in the wallet. A revocation normally costs network gas and may take time to appear in every third-party dashboard. After revoking, check the token contract or a reliable explorer to confirm that the remaining allowance is zero. Do not revoke an allowance while a legitimate transfer is still being processed, and do not assume revoking one spender revokes every other contract. Each spender has a separate allowance, so a user may have many active permissions across the same token.
QR-code phishing is a particular risk because a malicious QR code can lead to a signing site that imitates a legitimate payment interface. Never sign an approval just because a support agent, social post, or group administrator asks you to “verify” your wallet. A payment approval should be initiated by you from an independently opened website or application. If a request arrives unexpectedly, close the page, open the official service directly, and check the transaction details again. This habit is more valuable than memorizing every common scam label because phishing sites are replaced and disguised frequently.
Approval Options Compared
Approval choices have different security and convenience tradeoffs. The right option depends on whether the payment is one-time, recurring, uncertain, or connected to a smart contract. Exact approval is safest for a one-time payment, while limited recurring approval requires monitoring. Unlimited approval reduces friction but can preserve a transferable permission indefinitely. Native gas and token approval are separate costs, so revoking or replacing an approval can involve a second transaction.
| Feature | Exact ERC-20 approval | Limited recurring approval | Unlimited ERC-20 approval |
|---|---|---|---|
| Exposure | Usually limited to the signed amount | Limited but can be consumed over time | Potentially the full approved balance |
| One-time payment suitability | Best | Usually acceptable | Often excessive |
| Revocation need | After the payment, if unused | Before or after the service stops | Whenever the spender is untrusted or unused |
| User friction | May require another approval if the amount changes | May reduce repeated wallet prompts | Lowest during repeated use |
| Main risk | Incorrect amount or token | Forgotten recurring permission | Long-lived permission to a compromised contract |
| Typical cost | Network gas for approval; possibly another gas fee for revocation | Network gas for approval and later replacement | Network gas for approval and later revocation |
Common ERC-20 Approval Mistakes
A frequent mistake is confusing approval with a token transfer. A user may believe that signing a contract prevents a later transfer, when the signature actually creates the allowance. Another mistake is approving the maximum amount because a button says “Simplify” or “Pay once.” This is especially risky when the spender is a bridge, decentralized exchange, or newly launched contract, because those systems can change or expose administrative behavior after approval. A token’s price and liquidity can also change between approval and exploitation, although the direct allowance risk exists regardless of price.
Users also fail to verify the network. An ERC-20-looking token on an unfamiliar chain may be worthless or counterfeit even when its symbol matches a familiar token. Likewise, a malicious site can request a real token approval through a legitimate token contract while sending the approved funds to a malicious spender. Symbol, logo, and price are therefore weak evidence. Use the chain ID, contract address, spender address, and transaction simulation where available. A transaction that appears to be a “swap” may include several token calls, so inspect the overall action rather than one line of the interface.
Another mistake is believing that revoking an approval is a refund. Revocation only removes unused permission; it cannot reclaim tokens already transferred. Some services also retain an allowance even after an account is closed, so deleting an account is not equivalent to revoking the contract permission. Users should avoid repeatedly connecting wallets to random experiments, and they should remove old permissions from tokens they no longer recognize. The cost of a revocation is usually modest, but gas can be high on Ethereum during congestion; still, leaving a known unnecessary permission is often the more expensive decision.
When to Revoke and What It Costs
Revoke promptly after a one-time trade, abandoned application, suspected phishing exposure, or any interaction with a contract you do not understand. Immediate action is justified if you signed an approval you did not intend, connected to a suspicious site, or received a request to scan a QR code. You can revoke the affected spender first, then check the token balance and transaction history for earlier transfers. If tokens were transferred to an unknown address, revoking the allowance does not reverse those transfers; you may need to contact the relevant exchange, wallet provider, or law enforcement, although recovery is often uncertain.
Cost is primarily the network gas required for the approval, revocation, or replacement transaction. The ERC-20 approval itself may not transfer tokens, and the interface may show gas in the chain’s native currency, such as ETH on Ethereum. On a layer-2 network, gas may be substantially cheaper, but the contract and address still require the same careful review. There is no universal price: gas changes with demand, and a transaction can fail, remain pending, or become expensive if network conditions worsen. Some wallet interfaces estimate fees, but users should preserve enough native currency to revoke a permission.
Timing matters. An allowance can be exploited as soon as the approval is confirmed, so waiting for a convenient moment is not appropriate for a suspected malicious signature. For ordinary unused permissions, revocation can be scheduled after the related activity ends, but there is no benefit to keeping an allowance for an application that will not be used again. On a recurring payment, coordinate the replacement allowance with the next charge to avoid interrupting the service. Keep records of the chain, token, spender, and revocation transaction so a later review does not rely on memory.
A Simple Decision Framework for Everyday Payments
ERC-20 approval security is a trade among amount, duration, trust, and convenience. Use an exact approval for a one-time purchase, a capped allowance for a recurring payment, and unlimited approval only when the spender and contract have been independently verified and the reduction in repeated signatures is worth the broader exposure. If a service requires unlimited approval but cannot explain which contract will receive the permission, treat that as a reason not to proceed. A legitimate service should be able to identify the token, chain, spender, and expected amount before you sign.
Wallets and payment interfaces can reduce mistakes by displaying clear risk labels, showing the full contract address, distinguishing approval from transfer, and offering a one-click revocation route. Users should still maintain their own review process because wallet software generally cannot judge whether a contract will remain trustworthy. L0t’s practical rule is simple: use the least permission necessary, on the correct network, for the shortest useful period. That rule is not absolute, but it provides a defensible default when a payment app asks for more access than the transaction appears to require.
The most important post-payment habit is cleanup. After a one-time swap, check whether the allowance remains; after a subscription ends, revoke the spender; after a suspected phishing attempt, revoke the affected permission and examine the wallet history. Do not treat a token balance or a successful transaction as proof that the wallet is secure. Approval management is ongoing maintenance, just as checking a bank card’s recurring permissions is ongoing maintenance in ordinary payment workflows.