What ERC-20 Approval Security Actually Protects
An ERC-20 approval is permission for a contract, usually a decentralized exchange, lending service, merchant, or payment processor, to transfer a specified amount of a token from your wallet. It does not itself move funds, but an overly broad or unlimited approval can let the approved contract move tokens later without asking you for another transaction. The central ERC-20 security rule is therefore simple: treat every approval as a standing payment authorization, not as a harmless login click. A permission with an unlimited token amount can remain active until the contract returns it to zero, you revoke it, the token expires it if the implementation supports expiration, or the relevant contract is upgraded in a way that changes its behavior.
Also worth reading: How Do I Safely Review and Revoke ERC-20 Token Approvals in 2026? · Are Infinite Token Approvals Safe, and How Can You Protect Yourself? · What Is the Best Digital Payments Setup for Wallets, Checkout Tools, and Everyday Spending in 2026?
Approvals are different from token ownership because they can persist after a transaction appears complete. For example, approving a marketplace to spend 1,000 USDC means the marketplace can later transfer up to 1,000 USDC whenever the allowance and contract conditions permit. Approving an unlimited quantity is sometimes operationally convenient because it avoids repeated approval transactions, but it increases the potential loss if the destination contract is compromised, incorrectly implemented, or controlled by an attacker. The safest general policy is exact or reasonably bounded allowances for known, short-lived payments, with unlimited approval reserved for contracts whose code, administration, and upgrade controls you have independently evaluated. “Unlimited” usually means the maximum representable token amount, not an infinite amount in every mathematical sense.
How an ERC-20 Allowance Becomes a Spending Risk
Most non-native ERC-20 tokens follow the familiar approve(owner, amount) model. A decentralized application calls that function, often producing an onchain transaction that grants the application an allowance. The application can then call transferFrom to pull tokens from your wallet. If the allowance is exact, the application should be able to spend only that amount under the usual token rules, although unusual token implementations can behave differently. If the allowance is unlimited, a future call may spend any balance held by your wallet at the time of the call, subject to the contract’s own controls.
The important distinction is between approving a trusted contract and sending tokens directly to it. Sending a token confirms the transfer to that address, while approval gives a contract authority that can be exercised later. A merchant or exchange that requests approval is asking for spending authority, not merely recording your intended payment. This matters because many scams imitate ordinary checkout interfaces, request access to widely used assets such as USDT or USDC, and then wait for a transfer after the user believes the interaction is finished. A specific warning published by Cyfirma described “Unlimited USDT Approval Exploitation via Trust Wallet QR Code Phishing,” illustrating that a familiar wallet interface and familiar token did not make the authorization safe.
For stablecoins, a USDC approval on Ethereum also exposes the user to Ethereum gas and the contract’s network context; an ERC-20 approval on one chain generally does not authorize spending on another chain. Nevertheless, many wallet users operate across Ethereum, Base, Arbitrum, Polygon, and other networks, and they may assume that revoking an approval on one chain fixes every related address. Security requires checking the exact chain, token contract, spender contract, and wallet address separately. Identical ticker symbols are not proof that two tokens are the same asset.
Practical Steps for Reviewing and Revoking Approvals
Begin with a read-only review before signing anything. Open a reputable blockchain explorer or a reputable allowance dashboard, connect your wallet in view mode if the service supports it, and inspect every nonzero allowance rather than searching only for the token currently displayed on screen. Look at the token’s full contract address, the spender’s full address, the approved amount, and any available transaction history. A large allowance to a familiar exchange is not automatically malicious, but it should be understood: the exchange may need a broad allowance for trading, market making, custody operations, or user withdrawals. An allowance to an unfamiliar address with no plausible connection to the service deserves immediate suspicion.
When you decide that a permission is unnecessary, revoke it through a trusted revocation interface or directly through the token contract. The usual transaction sets the allowance to zero, or replaces it with a smaller amount; depending on the token and interface, this may require gas. Before confirming, check that the network is correct and that the token and spender addresses match what you reviewed. Some tokens use a race-condition allowance pattern, while others require a zero allowance to be set before a new value can be approved. If a revocation fails or behaves unusually, do not keep retrying blindly; compare the token’s documentation and inspect the pending transaction.
For a recurring payment, set the smallest allowance that covers the expected transaction and revoke it after payment when practical. If a processor insists on an unlimited allowance, first verify the contract, its audit history, its administrators or upgrade rights, and the exact asset being approved. A low gas price is not a security control, and a familiar brand name is not proof that the displayed contract is legitimate. Keep a transaction hash for every payment or approval, use a dedicated wallet for experimentation, and transfer only the amount needed for the task rather than maintaining a large balance in an actively approved wallet.
Exact, Unlimited, and Alternative Approval Methods Compared
Approval design affects convenience, transaction costs, and the size of the potential loss. Exact approvals are more operationally disciplined, but they can require additional transactions whenever the authorized amount is exhausted. Unlimited approvals reduce friction but can expose the entire current balance of the approved token. Permit2, discussed in Circle material on simplifying onchain payments, changes the interaction model by allowing users to approve a broader spending policy and then sign shorter-lived permits for particular recipients, amounts, and expirations. That can improve control without removing the need to inspect signatures, domains, deadlines, and contract behavior.
| Feature | Exact token approval | Unlimited token approval | Permit2 or another signed-permit flow |
|---|---|---|---|
| Spending authority | Fixed amount stated in the approval | Potentially the entire approved balance at spend time | Usually limited by recipient, amount, nonce, and expiration |
| Gas and friction | May require a new approval after exhaustion | One approval may support many later transfers | Initial setup may cost gas; later signatures can avoid separate onchain approvals |
| Main risk | Excessive exact amount still creates a risk window | Compromise can expose all tokens of that type held by the wallet | Phishing, signature misinterpretation, or unsafe permit parameters can still cause loss |
| Best use | One payment, bounded subscription, or controlled merchant flow | Carefully reviewed, established contract that needs broad access | Frequent payments where fine-grained expiration and amount controls matter |
| Revocation | Set allowance to zero or a lower permitted value | Same, but verify that no rapid withdrawals occurred | Revoke the relevant contract policy and invalidate unused permits where supported |
Other alternatives include using a smart-account wallet with spending policies, custodial checkout through a regulated provider, payment links that specify a fixed amount, or an exchange withdrawal directly to the final destination. These methods can reduce the need to grant token allowances, but each introduces different operational and custody tradeoffs. A smart account may be able to impose per-transaction or daily limits, but its owner, recovery method, and upgrade controls matter. A custodial account may be easier for a consumer, but the provider bears custody and account-security risk. No interface removes the need to verify the destination.
Common Approval Mistakes and Scam Patterns
One common mistake is confusing a successful payment with a completed security review. The user sees the expected payment, assumes the allowance has expired, and leaves unlimited authority active. Another is approving a token because the interface says “set amount,” while ignoring that the spender may be a proxy contract with upgradeable logic. Third, users often rely on a token symbol rather than its contract address; an attacker can deploy a token with a name and ticker copied from a popular asset. Fourth, people may revoke the wrong approval after checking only the first search result, leaving the dangerous permission untouched.
QR-code phishing is a particularly important failure mode. A counterfeit page can present a genuine-looking wallet connection or payment request while directing the user to a malicious contract. The security problem is not that Ethereum itself failed, but that the user approved an address under false pretenses. Cyfirma’s reported Trust Wallet QR-code case is a concrete reminder to verify the origin URL, wallet request details, chain, token contract, and spender before signing. A seed phrase or private key should never be entered to approve a payment, and no legitimate approval process generally needs it. If a wallet asks for unlimited USDT approval inside an unexpected QR flow, stop and verify through an independent channel.
Another mistake is believing that a token transfer to a contract proves the contract is safe. Audit status helps but does not eliminate risk, and an audit may cover one deployment, one version, or a limited set of functions. Upgradeable contracts can also change after an audit. Users should review the contract’s source repository, deployment address, proxy and admin relationships, and recent governance or upgrade activity where those details are available. Because these checks take time, the practical alternative is to use small balances and exact approvals rather than attempting to become a full-time smart-contract auditor.
When You Should Approve, Revoke, or Stop
Act immediately when you discover an approval you do not recognize, a spender linked to a known exploit, an unexpectedly large allowance, or evidence that a wallet was compromised. Revoke the affected token allowance on the correct chain, move any remaining assets to a new wallet if compromise is plausible, and check subsequent activity. If a token or contract remains suspicious, do not interact with it merely to “clean up” the wallet; use a trusted explorer or security provider to understand the permission first. Time matters because an attacker with a valid allowance may act before a user notices.
For normal use, review approvals every 30 to 90 days, or more often when you use DeFi services frequently. High-value wallets should be reviewed monthly, and any wallet that signs experimental applications should be reviewed after every substantial session. The interval is a practical control, not a guarantee; an attacker can exploit a valid allowance seconds after a review. A useful rule is to revoke permissions after one-off payments, subscriptions that have ended, abandoned trials, and contracts no longer needed. Keep active allowances for services that require them, but cap the token balance held in the wallet so an unlimited allowance is not equivalent to unlimited total exposure.
There is no universal threshold such as “$100 is safe” or “$10,000 is dangerous.” The right amount depends on the wallet balance, token volatility, contract reliability, payment frequency, and the user’s ability to monitor activity. A $5,000 allowance can be serious for a wallet that normally holds $5,000, while it may be trivial for a treasury with tightly controlled custody procedures. In stablecoins, dollar-denominated reasoning is useful, but the asset and chain still matter. A 1,000 USDC allowance on Ethereum and a 1,000 USDC allowance on an unverified network should not receive the same treatment.
Cost, Timing, and Limits of Approval Security
Revoking an ERC-20 approval is an onchain state change and generally costs gas on networks that charge for transactions. The price varies with network conditions, transaction complexity, and token behavior; it is not fixed by the token’s dollar value. On a low-fee layer-2 network, the same operation may be inexpensive, while on Ethereum during congestion it may cost materially more. A permit-based flow can reduce later network activity, but it may require an initial onchain setup transaction and still leave a signature that can be exploited if its parameters are wrong. Users should compare the gas cost with the potential loss, not assume that a cheaper revocation is unnecessary.
Approval security also has an operational cost. Exact approvals can require multiple transactions, which increases fees and time. Unlimited approvals can simplify frequent trading or payments, but they make monitoring and revocation more important. Some token implementations support allowance decreases, while others do not, and some interfaces require the allowance to be reset to zero before a new exact amount is entered. This is why a failed or pending transaction should be investigated rather than replaced with an unlimited approval as a shortcut. The user may pay more gas than intended or leave two conflicting allowances, depending on the token and contract sequence.
Finally, no dashboard or wallet can certify that a contract will remain safe. Prices can fall, governance can change, bridges can fail, and interfaces can be compromised. As of 29 September 2026, the durable security practice is layered: verify the chain and addresses, minimize token balances, use exact or expiring permissions, revoke promptly, monitor approvals, and keep high-value assets separate from experimental activity. ERC-20 approvals are useful tools, but they should be granted with the same seriousness as an instruction to move money later.