Key Takeaways
Every time a wallet asks you to "approve" a token before a swap, deposit, or trade, it's asking you to set a number: how much of that token a contract may move out of your wallet, on its own, until you revoke that permission. Most interfaces pre-fill that number at the token's practical maximum by default. Understanding why, and knowing the number can usually be changed, is the single most useful piece of on-chain security literacy for anyone who uses DeFi protocols, DEXs, or NFT marketplaces regularly.
Direct answer: An unlimited approval authorizes a spender contract to move any amount of a token up to its maximum representable value — functionally your entire balance — while a limited approval caps that authorization at a specific amount matching the transaction at hand. Unlimited approvals exist because they save gas on every future transaction with that protocol; the tradeoff is that if the spender contract is ever exploited, compromised, or malicious, an attacker can drain the full approved balance, not just what the original transaction intended. Neither choice is universally correct — it depends on how much you trust the protocol and how often you'll use it.
- An approval amount can be set to anything: a token's practical maximum (commonly the max uint256 value) or a specific figure matching the transaction being made.
- Unlimited approvals are more gas-efficient for frequent users because the approval only has to happen once per protocol, not before every future interaction.
- The cost is that your entire balance of that token becomes reachable by the spender contract for as long as the approval stands, regardless of how small the original transaction was.
- Many wallets let you edit the approval amount before confirming, but the control is often a small, easy-to-miss link rather than a prominent field.
- Limited approvals reduce exposure per protocol but require a fresh approval, and fresh gas, before every future transaction with that protocol.
- The reasonable default differs by relationship: unlimited for protocols you trust and use often, limited for one-off interactions with anything newer or less proven.
The Technical Distinction: What an Approval Amount Actually Is
On Ethereum and every EVM-compatible chain, a token that follows the ERC-20 standard doesn't let other contracts move it out of your wallet by default. Before a DEX, lending protocol, or marketplace can pull tokens from your address — to execute a swap, take collateral, or complete a sale — you first call that token's own approve function, naming the spender's address and an amount it's allowed to move. That amount is stored on-chain as an allowance, tied to your address, the token, and that spender. Each time the spender calls transferFrom, the token contract checks the allowance and decrements it, refusing the transfer once it runs out.
The amount field can be set to any value the token's data type supports. Balances and allowances are stored as 256-bit unsigned integers, so the largest number the field can hold is 2256 minus 1 — a 78-digit integer, far beyond any real-world token supply. Setting the approval to that maximum is what's commonly called an "unlimited" approval: not infinite in a literal sense, but functionally unlimited for any balance a person could plausibly hold. Setting the amount to exactly 50 units, or exactly what one swap needs, is a "limited" approval: the spender can move up to that amount and no more, and once used, the allowance returns to zero.
This distinction matters because the approval and the transaction it enables are separate on-chain events. Signing an approval doesn't move tokens by itself; it grants permission for a future transfer. That permission persists indefinitely as a standing allowance until it's consumed by transfers or you submit a new approval that changes the number, including a "revoke" transaction setting it back to zero. Nothing about a token's use case requires an unlimited allowance — a protocol only ever needs the amount involved in the action you're currently taking. Unlimited approval is a convenience choice layered on a system built for precise, minimal permissions.
Why Wallets and dApps Default to Requesting Unlimited
It's tempting to read the unlimited-approval default as pure carelessness on the part of dApp developers, but the honest explanation is more of a real tradeoff than a design failure. An approval is its own transaction, with its own gas cost, separate from the swap or deposit that follows it. When gas is expensive, that fee is not trivial — it can rival or exceed the cost of the transaction it's enabling. If a protocol only ever requested a limited approval scoped to the current transaction, a regular user would pay that gas fee again before every single future interaction, even after using the protocol without incident for years.
Requesting an unlimited approval the first time converts that repeating cost into a one-time cost. After the first approval, every subsequent swap, deposit, or trade with that contract skips the approval step entirely, since the standing allowance already covers it. For an active DeFi user who interacts with the same DEX or lending protocol dozens or hundreds of times, this is a genuine, material gas savings. Framing unlimited approvals as simply "bad" design ignores that the default emerged from real user behavior and real gas costs, on networks where frequent re-approval has, at various points, been a meaningfully expensive habit.
It's worth being precise about the tradeoff: unlimited approvals aren't more efficient in some abstract sense, they shift cost and risk in opposite directions. A limited approval costs more gas over time but bounds exposure to what you intend at each step. An unlimited approval saves gas over time but expands exposure to your entire balance of that token for as long as the approval exists, whether or not you're actively using the protocol. Defaulting to unlimited optimizes for the gas-savings side of that tradeoff, on the assumption that most approvals go to protocols users will return to.
The Security Tradeoff: Convenience Versus Exposure
The gas savings from an unlimited approval are real, but they come paired with a specific, quantifiable exposure a limited approval doesn't create. An approval doesn't expire when the transaction it was meant for completes; it sits as a live, standing permission on-chain, associated with a spender contract, indefinitely, regardless of whether you ever use that protocol again. That permission is only as trustworthy as the contract holding it, for as long as the contract exists.
Smart contracts are not static, risk-free entities once deployed. Many are upgradeable, meaning the logic behind an address you approved months ago can change without your involvement. Even non-upgradeable contracts can contain bugs that weren't discovered at launch, and audits don't guarantee the absence of an exploitable flaw. Some contracts have admin keys compromised after launch; some are deployed with malicious logic from the beginning, waiting for enough approvals to accumulate before draining them. In every scenario, the damage an attacker can inflict is capped by one number: the standing allowance the wallet granted. A consumed, zeroed-out limited approval caps that damage at nothing. An unlimited approval caps it at the wallet's full balance of that token, however large that balance has grown since.
This is the shape of the tradeoff: convenience — approve once, transact freely forever after — traded against exposure — a single point of failure that puts your entire balance at risk for as long as the approval exists, tied to a contract you may not be actively monitoring. Neither side is inherently the "responsible" choice; it depends on how much ongoing trust the specific contract has earned.
Worked Example: A $50 Swap That Becomes a $100,000 Loss
Hypothetical, generic example — for education only. Not based on any specific real project.
Consider a user with 100,000 USDC in a wallet who tries a decentralized exchange for the first time, making a small, exploratory swap worth $50. To execute the trade, the DEX's router contract needs permission to pull USDC from the wallet, so it prompts for a token approval first. The interface pre-fills the amount at the maximum by default, framed simply as "Approve USDC," with no dollar figure shown prominently on the confirmation screen. Focused on completing a $50 trade, the user approves it as presented. The swap executes successfully, and the user moves on, having spent maybe $50.03 once gas is included.
That $50 swap is now the only transaction the user has ever made through this DEX. But the approval that preceded it wasn't scoped to $50 — it was scoped to the maximum, meaning the router contract now holds standing permission to move up to the wallet's full USDC balance, including the other 99,950 USDC never touched by the swap. Nothing about that permission is visible in day-to-day use; it exists silently as an entry in USDC's allowance mapping unless the user goes looking for it with an approval-checking tool.
Eight months later, a vulnerability is discovered and exploited in the router contract — the kind of event that happens periodically across DeFi, whether through a coding flaw, a compromised upgrade key, or a novel attack vector nobody had modeled. The user hasn't touched the DEX since that first $50 swap and has no reason to think about it. But the standing approval never expired. The attacker doesn't need the user to sign anything new; they simply call transferFrom against the already-approved allowance, and up to the full 99,950 remaining USDC moves out in one transaction. The loss has nothing to do with the size of the original $50 trade — it's a function of the approval granted eight months prior, one most people in this situation have completely forgotten existed.
Had the user set a limited approval of $50 instead, the identical exploit eight months later would have found an allowance of zero, since that $50 allowance was already consumed by the original swap. The exploit, the vulnerability, and the attacker's actions would all be unchanged; only the exposure would differ, bounded entirely by a choice made on one confirmation screen eight months earlier.
How to Choose a Limited Approval in Practice
Most wallets and dApp interfaces that request an unlimited approval by default still allow the amount to be edited before you sign, but that control is frequently a secondary element rather than the headline of the confirmation screen. Knowing what to look for makes it usable rather than invisible.
What to look for on the approval screen
- A pre-filled amount field showing an extremely large number, often displayed as "Unlimited" — the field that determines exposure, usually editable even when the interface doesn't emphasize that fact.
- A small link, toggle, or edit icon near the amount, sometimes labeled "Edit permission," "Use default," or "Custom spend limit" — frequently the only visible cue that it can be changed, and easy to scroll past.
- Some wallets separate this into two screens: a summary showing "Spending cap: Unlimited," then a details view where the numeric field becomes editable — don't stop at the summary screen if a specific amount matters to you.
- If no editable amount appears in the flow, some wallet extensions still allow rejecting the request and submitting a custom approve transaction through a block explorer, though that's an advanced path best reserved for when it specifically matters.
Setting the amount
Once the editable field is found, replacing the pre-filled maximum with a specific number — matching the quantity or dollar value of the transaction being made, with a small buffer for price movement on volatile assets — submits a limited approval instead. The transaction still requires the same signature and gas payment; only the allowance number changes. There's no separate "limited mode" to toggle — it's simply an unlimited approval with the amount edited down before signing.
Common mistake
The common mistake here is treating the unlimited default as the only option presented, rather than checking whether it's editable at all. Because the edit control is often visually minor, plenty of experienced wallet users have never noticed it exists, and simply click through the default every time without realizing a choice was available.
The Practical Decision Framework
Neither unlimited nor limited approvals are correct in every situation, so the more useful question is which one fits a specific interaction, weighed against two things: how much the spender contract is trusted, and how often it will actually be used.
When unlimited approval is a reasonable choice
- The protocol is one you've used repeatedly over a meaningful period without incident, and you plan to keep using it regularly.
- The protocol has a long operating history, significant value secured by its contracts, and a visible track record of audits and, ideally, a bug-bounty program.
- The gas savings from not re-approving before every transaction meaningfully matters — for example, a DEX or lending market visited several times a week.
- You're comfortable periodically checking and, if needed, revoking the approval as routine wallet hygiene, rather than granting it and never revisiting it.
When a limited approval is the better choice
- This is the first interaction with the protocol, with no established track record yet to base ongoing trust on.
- The protocol is new, recently deployed, unaudited, or associated with a team without a long public history.
- The interaction is a genuine one-off — claiming something, testing a feature, or a single trade with no plan to return to that contract regularly.
- The token involved represents a large share of total holdings, where a worst-case drain is disproportionately severe relative to the gas saved.
Common mistake
The common mistake is applying one rule universally instead of evaluating each approval on its own terms. A user who correctly grants unlimited approval to a long-trusted, heavily used protocol and then reflexively does the same for an unfamiliar contract encountered once has made two very different risk decisions while treating them as identical.
Misconceptions Versus Reality
| Misconception | Reality |
|---|---|
| Limited approvals are always strictly safer, so I should always use them | Mostly true in terms of worst-case exposure, but limited approvals expire after their transaction and require a brand-new approval and gas payment for every future interaction, which for frequent users creates approval fatigue that can itself lead to careless, unread clicking through confirmation screens |
| Unlimited approval means my whole wallet is at risk, not just one token | An approval only ever covers the specific token it was granted for and the specific spender contract named in it; a USDC approval to one DEX has no bearing on any other token or any other contract |
| If I haven't used a protocol in a long time, my old approval to it must have expired | Approvals never expire on their own; a standing allowance persists indefinitely until it's consumed by transfers or explicitly revoked, regardless of how long it's gone unused |
| An unlimited approval is only risky if the amount actually gets used all at once | The risk exists the entire time the allowance stands, independent of whether it's ever exercised; the exposure is the maximum the contract could take, not what it has taken so far |
| Wallets clearly show what an approval authorizes, so I'd notice if something was wrong | Many wallet confirmation screens display technical, generic language and bury the actual editable amount behind a secondary link, making the true scope of the request easy to miss even for attentive users |
| Once I've approved a protocol, there's nothing more to think about | A standing approval is only as safe as the contract holding it remains over time; periodically reviewing and revoking unused approvals is a normal part of wallet maintenance, not a one-time decision |
Common Mistakes
- Accepting the default without checking whether it's editable. The single most common mistake is never noticing that an "Edit permission" control exists, and clicking through the pre-filled maximum by habit.
- Never reviewing standing approvals after they're granted. An approval made once, years ago, to a protocol no longer in use remains a live liability until it's specifically found and revoked.
- Treating every approval the same way regardless of context. A blanket "always unlimited" or "always limited" rule ignores that the right choice depends on the protocol's trustworthiness and how often it's used.
- Confusing an approval transaction with the transaction it enables. Some users assume a successful swap means the approval behind it was scoped narrowly to that action, when in most default flows it was not.
- Assuming a familiar protocol makes unlimited approval risk-free. Reputation and track record reduce, but never eliminate, the chance of a future exploit, key compromise, or newly discovered bug.
- Granting unlimited approval to test an unfamiliar protocol "just this once." A one-off interaction is exactly the scenario where a limited approval costs almost nothing extra in gas relative to the exposure it avoids.
Ongoing Approval Hygiene
Choosing carefully at the moment of approval is half of managing this risk; the other half is treating standing approvals as something to periodically revisit, not a one-time decision.
Practical checklist
- Before signing any approval, check whether the amount field is editable and, for new or infrequently used protocols, replace the default with a figure matching the transaction.
- Periodically review outstanding token approvals using a reputable approval-checking tool, and revoke anything tied to a protocol no longer in use.
- Prioritize revoking unlimited approvals over limited ones when time is limited, since they represent the larger standing exposure.
- Keep track of which protocols hold an unlimited approval from your primary wallet, so a future exploit disclosure for one of them is something you'd recognize and act on.
- Consider a separate, lightly funded wallet for exploratory interactions with newer protocols, so any approval granted there never exposes a large primary balance.
Risks, Limitations, and Exceptions
- Gas costs, wallet interface designs, and the labeling of approval controls change over time and differ across wallets; the general pattern here is consistent, but exact screen layouts will vary.
- Revoking an approval after an exploit has already occurred does not recover assets already transferred; revocation only prevents further access going forward.
- Some newer standards aim to reduce this tradeoff directly — time-limited or session-based permissions, for example — but they aren't universally supported across all tokens, chains, and wallets yet, so this choice remains the primary lever for most users today.
- A limited approval protects against a compromised spender contract, but not against a malicious signature request asking you to approve a larger amount than intended; reading the amount before signing still matters regardless of approach.
- This guide addresses on-chain token approvals specifically; off-chain "permit" signatures function similarly but involve a different signing flow, covered separately in the guide on malicious approval transactions.
Tool Opportunity
A dedicated Swoopr tool should help readers see, at a glance, exactly what a pending approval authorizes and how it compares to a scoped alternative before they sign.
Recommended inputs: the token being approved, the spender contract address, the amount requested by the dApp, and the dollar value of the transaction the approval is meant to enable.
Expected outputs: a plain-language comparison of the requested amount against the transaction's actual size, a flag when the amount is set to the practical maximum, and a summary of the spender contract's public track record (age, verification status, known incident history where available).
Validation requirements: never request or store a seed phrase or private key, label any contract history summary as a heuristic signal rather than a guarantee of safety, and direct the user back to their own wallet interface to make the approval decision rather than executing anything on their behalf.
Sources
- Ethereum Improvement Proposals, "EIP-20: Token Standard," eips.ethereum.org — the technical standard defining the
approveandallowancefunctions that every ERC-20 token approval, limited or unlimited, is built on. - Revoke.cash, Token Approvals learning resources, revoke.cash — practical, plain-language documentation on how token approvals work, how to review them, and how to revoke standing allowances.
- MetaMask Support, "Transaction and signature request warnings" and related permissions documentation, support.metamask.io — wallet-level documentation on how spending caps are presented and edited during a token approval request.
Frequently Asked Questions
What's the actual difference between an unlimited and a limited token approval?
A token approval specifies an amount the spender contract may move on your behalf. An unlimited approval sets that amount to the token's max representable value, usually the maximum uint256 number (2^256 minus 1), so far beyond any realistic balance that it functions as permission to move your entire holding of that token. A limited approval sets a specific, smaller number matching what the transaction needs, so the spender can never move more than that amount.
Why do so many wallets and dApps default to requesting unlimited approval?
It's a genuine gas-efficiency tradeoff, not just careless design. An approval is its own on-chain transaction, separate from the swap, deposit, or trade that follows it. Approve a protocol once for an unlimited amount and you never pay approval gas again for future transactions with it. Approve a limited amount instead, and you pay a fresh gas fee before every single future transaction, which adds up for anyone who uses a protocol regularly.
Is granting an unlimited approval automatically a mistake?
Not automatically. For a protocol you trust deeply and use frequently, an unlimited approval is a reasonable tradeoff many users make in exchange for not re-paying gas on every visit. It becomes a mistake when it's granted reflexively, without knowing it can be edited, to a protocol that's new, unfamiliar, or used only once — exposure taken on for no ongoing convenience benefit.
How do I set a limited approval instead of accepting a dApp's default?
Many wallets show an editable spending cap on the approval confirmation screen, often behind a small link or expandable section labeled "edit permission" or "use default" rather than a prominent field. Replacing the pre-filled maximum with the specific amount needed for the transaction, such as the dollar value being swapped, submits a limited approval instead of the suggested unlimited one.
If I already granted an unlimited approval, what should I do?
Use a reputable approval-checking tool to see every outstanding approval tied to your wallet address, and revoke any belonging to protocols you no longer use or don't fully trust, which resets the allowance to zero. For protocols you still use regularly, keeping the unlimited approval is defensible as long as it's a deliberate choice rather than something forgotten about.
Are limited approvals always the strictly safer choice?
They reduce worst-case exposure, but "always safer" overstates it. A limited approval expires after its intended transaction, so every future interaction with that protocol requires a brand new approval and gas payment. For someone who transacts with the same protocol often, that repetition creates approval fatigue, which can lead to clicking through confirmation screens carelessly, partly undoing the benefit the limited approval was meant to provide.
Which Swoopr resources cover the rest of the token approval picture?
The Token Approvals & Blind Signing hub covers the full topic area, the guide on what a token approval actually is explains the underlying approve and allowance mechanism, the guide on revoking token approvals walks through the revocation process step by step, and the guide on malicious approval transactions covers how attackers disguise approval requests as something else entirely.
Conclusion
Unlimited token approvals aren't a trick or a bug in how DeFi works — they're a deliberate, honest tradeoff that saves real gas for anyone who uses a protocol repeatedly, purchased with a specific, quantifiable exposure that persists as long as the approval stands. The choice worth making consciously, transaction by transaction, is whether that tradeoff fits the situation: unlimited for protocols earned through real trust and regular use, limited for anything new, unfamiliar, or genuinely one-off. Either choice is reasonable when it's made on purpose. The mistake is never realizing a choice existed at all, and going back periodically to check what's still standing is what keeps that choice from quietly expiring into risk.
Related Reading
- Token Approvals & Blind Signing — the parent hub covering approvals, permit signatures, and blind signing risks together.
- What is a token approval? — a deeper look at the underlying approve and allowance mechanism this guide builds on.
- How to revoke token approvals — a step-by-step walkthrough of finding and revoking standing allowances.
- Malicious approval transactions — how attackers disguise approval requests, including permit signatures, as something else entirely.
- Phishing & Wallet Drainers — how malicious approvals are used as the final step in wallet-draining phishing campaigns.
- Hot wallets vs. cold wallets — how wallet choice affects overall exposure to standing approvals.