Allowance

An allowance in the context of blockchain and cryptocurrency is a delegated spending permission set within a smart contract that authorizes a designated address (the spender) to transfer up to a specific amount of tokens from the owner’s account. This mechanism is most prominently implemented through the ERC-20 token standard’s approve() and transferFrom() function pair, enabling token holders to grant third parties controlled access to their funds without surrendering custody of their private keys.

Many dApps use an allowance before transferring a user’s ERC-20 tokens. The user authorizes a spender, which can then transfer up to the permitted amount under the token’s rules. Some flows use a prior approval or a permit signature rather than a separate new approval transaction. An authorized malicious spender can still misuse the permission.

An ERC-20 token exposes allowance(owner, spender) to report spending permission. Implementations commonly store it in a nested mapping. Finite allowances are generally reduced when spent; some implementations treat the maximum uint256 value as an unlimited allowance and do not decrement it. The storage design and event behavior are implementation-specific.

NFT approvals differ from fungible-token allowances. ERC-721 supports approval of an individual token and operators through setApprovalForAll(); ERC-1155 uses operator approval. ERC-2612 adds signed permits for compatible ERC-20 tokens. These permissions must be understood according to the relevant standard rather than treated as identical spending caps.

Origin & History

2015: Ethereum launched with the ability to deploy custom smart contracts, laying the groundwork for programmable token standards that would eventually require allowance mechanisms for inter-contract token transfers.

2015–2016: Early token contracts on Ethereum implemented ad hoc approval mechanisms. Developers recognized that smart contracts needed a way to move tokens on behalf of users to enable exchanges, crowdsales, and other multi-party interactions. The community began converging on a standardized approach.

2015: Fabian Vogelsteller and Vitalik Buterin proposed ERC-20, including approve(), transferFrom(), and allowance(). It became a widely adopted interface for fungible tokens. (Source: ERC-20 token standard)

The ERC-20 specification documents the race condition involved in replacing an existing allowance. Its interface guidance recommends setting an allowance to zero before setting a new value, while recognizing the need for careful transaction handling.

Some older ERC-20 implementations added increaseAllowance() and decreaseAllowance() helpers. They are not required by ERC-20 and are not included in OpenZeppelin Contracts 5.x’s base ERC20 interface. Integration code must check the token and library version. (Source: OpenZeppelin ERC20 implementation reference)

2020: ERC-2612 specified permit(), allowing an allowance to be authorized by an off-chain signature. Someone must still submit the permit on-chain and pay transaction gas; it can be bundled with a subsequent action.

2021–2022: The explosion of DeFi protocols brought the concept of “unlimited allowances” — where users approve type(uint256).max — into mainstream discussion. Security researchers and projects like Revoke.cash raised awareness about the risks of leaving unlimited allowances active on dormant or potentially compromised contracts.

2022: Uniswap introduced Permit2, which supports signature-based transfers and time-bounded spending permissions after approval to its contract. This can simplify integrations but introduces another permission layer and does not eliminate malicious-signature risk.

In Simple Terms

1. An allowance is like authorizing someone to spend up to a stated amount from a particular account. The limit is not automatically daily or monthly: a standard ERC-20 allowance has no built-in renewal period or expiry.
2. Imagine lending your library card to a friend but telling the librarian they can only borrow three books on your account. The librarian (smart contract) enforces the limit — even if your friend tries to check out ten books, the system only allows three.

Important: Setting an allowance does not transfer any tokens — it only grants permission for a future transfer. Tokens remain in the owner’s wallet until the spender actually calls transferFrom(). Additionally, many dApps request “unlimited” allowances for convenience, but this means the contract could potentially move all of your tokens of that type if it is ever compromised.

Key Technical Features

The ERC-20 Allowance Functions

• approve(spender, amount) — Sets the allowance for spender to spend up to amount of the caller’s tokens; emits an Approval event
• allowance(owner, spender) — Returns the current remaining allowance that spender can use from owner’s balance
• transferFrom(from, to, amount) — Transfers tokens using the caller’s applicable spending authorization, subject to the token’s checks.
• These three functions together form the core delegation mechanism of the ERC-20 standard

How an Allowance Works Step by Step

1. The token holder calls approve() on the token contract, specifying the spender address and the maximum amount
2. The token contract updates its internal allowances mapping: allowances[owner][spender] = amount
3. An Approval event is emitted on-chain, publicly recording the permission grant
4. When the spender needs to move tokens, it calls transferFrom(), specifying the owner’s address, the destination, and the amount
5. The token contract checks that amount <= allowances[owner][spender] and that amount <= balanceOf(owner)
6. If the transfer is permitted under the token’s rules, balances change, and a Transfer event is emitted. Finite allowances are normally reduced; implementations may leave an unlimited allowance unchanged.
7. The spender can continue to call transferFrom() until the allowance is exhausted or the owner revokes it by setting the allowance to zero

Approve Front-Running Vulnerability

• Occurs when an owner changes an existing non-zero allowance to a different non-zero value
• A malicious spender can front-run the second approve() transaction, spending the old allowance before the new one takes effect, then spending the new allowance as well
• Mitigation: set the allowance to zero, wait for confirmation, and check spending before granting a replacement. Increment/decrement helpers are an option only on compatible implementations and do not undo already executed transfers.
• ERC-2612 nonces prevent replay of a used permit, but do not remove the allowance-replacement race condition. Its deadline limits permit submission, not the lifetime of an allowance already granted. (Source: ERC-2612 permit specification)

Unlimited vs. Exact Allowances

• Unlimited allowances: A maximum-value approval can expose current and future balances of that token until revoked or otherwise changed. It does not grant access to every asset in the wallet.
• Exact allowances: Limit the amount exposed to a spender. Additional authorization may be needed for later transfers, but signed or bundled flows can avoid a separate approval transaction.
• Time-limited permissions: Permit2’s AllowanceTransfer includes allowance expiration. A signature deadline and an allowance expiration are distinct concepts. (Source: Permit2 permission architecture)
• Use the smallest practical permission and review unused approvals. Limits and expiration reduce exposure but do not make a malicious interaction safe.

Advantages & Disadvantages

Advantages	Disadvantages
Delegated Spending: The user retains their private key, but the approved spender gains authority over the permitted token amount.	Approve Front-Running: Changing a non-zero allowance to another non-zero value can be exploited by a malicious spender through transaction ordering manipulation
DeFi Composability: Allowances enable the composable interactions that power DEXes, lending protocols, yield aggregators, and other DeFi primitives	Gas Overhead: On-chain approvals cost gas. Permits can shift payment to a submitter or bundle authorization with another operation; execution is not free.
Granular Control: Owners can set exact spending limits, revoke allowances at any time, and manage permissions on a per-spender basis	Unlimited Allowance Risk: A maximum approval can remain active after a user stops using a dApp, until changed under the token’s rules.
On-Chain Visibility: Current allowance can be queried from the contract. Approval events help discover permissions, but event history alone may not show every later change.	User Confusion: The two-step approve-then-transact workflow is unintuitive for new users, leading to abandoned transactions and support requests
Revocation: A confirmed transaction can set a standard allowance to zero. It does not reverse previous transfers or necessarily invalidate an unused signed permit.	Stale Permissions: Users often forget about old allowances, leaving dormant permissions active on contracts they no longer use, creating a latent attack surface
Ecosystem Standard: ERC-20 defines a common interface, but token implementations have compatibility differences that integrations must handle.	Smart Contract Risk: An allowance is only as secure as the spender contract — if that contract has a vulnerability, the attacker can drain the approved amount from every user who set an allowance
Extensible Design: The base allowance model has been extended by EIP-2612 permits, Permit2, and other innovations that improve UX and security	No Native Expiration: A standard ERC-20 allowance has no automatic expiry. It can be spent down, replaced, or revoked under the implementation’s rules.

Risk Management

Unlimited Allowance Exploitation

• If a compromised spender can invoke transfers against an allowance, the approved token balance may be at risk, including later deposits while the permission remains active.
• Mitigation: approve only the exact amount needed for each transaction; use tools like Revoke.cash or Etherscan Token Approval Checker to audit and revoke stale allowances
• Periodically review all active allowances and revoke permissions for contracts you no longer use

Phishing-Based Approval Attacks

• Attackers create malicious dApps or fake interfaces that trick users into calling approve() on their token contracts, granting the attacker’s address unlimited spending rights
• Mitigation: verify the token, spender, chain, amount, and signature details through trusted sources. An audit does not make a compromised website or malicious approval safe.
• A hardware wallet can protect signing keys, but it cannot stop an authorized spender from using an approval the user has already granted.

Approve Front-Running

• Occurs in the window between broadcasting an allowance change transaction and its inclusion in a block
• Mitigation: confirm a zero allowance and review recent spending before replacing it. Check any helper or permit behavior against the exact token implementation; a permit is not a universal front-running fix.
• Private transaction submission may reduce public-mempool exposure, but it does not remove permission risks or guarantee transaction ordering.

Contract Upgrade Risk

• If a spender contract is upgradeable via a proxy pattern, a malicious upgrade could introduce token-draining logic that exploits existing allowances
• Mitigation: favor immutable contracts or contracts with time-locked governance upgrades; revoke allowances from proxy contracts when they undergo upgrades
• Monitor governance proposals for contracts you have active allowances on

Cultural Relevance

The concept of token allowances has become one of the most discussed topics in blockchain security culture. The phrase “check your approvals” has become a standard piece of advice in the crypto community, particularly after high-profile exploits where compromised contracts drained user funds through existing allowances.

The rise of tools like Revoke.cash and Unrekt reflects a growing culture of “approval hygiene” — the practice of regularly auditing and cleaning up stale token allowances. These tools have transformed allowance management from an obscure technical concern into a mainstream security practice, with crypto influencers regularly reminding their audiences to revoke unused approvals.

The debate between unlimited and exact allowances has also become a cultural flashpoint. Convenience-focused users and dApp developers prefer unlimited approvals to minimize gas costs and streamline interactions, while security-focused community members advocate for exact approvals, viewing unlimited permissions as an unacceptable risk. This tension has driven innovation in the form of Permit2, time-limited approvals, and session-based permissions that attempt to satisfy both camps.

In the broader context of Web3 culture, the allowance mechanism symbolizes both the power and the responsibility of self-custody. Unlike traditional finance where a bank manages permissions on your behalf, blockchain users must actively manage their own allowances — a responsibility that has led to both empowerment and costly mistakes.

Real-World Examples

1. Uniswap Token Swap Approval

• Scenario: A DeFi user wants to swap 1,000 USDC for ETH on Uniswap V3. Before the swap can execute, the user must approve Uniswap’s router contract to spend their USDC.
• Implementation: The user’s wallet prompts them to call approve() on the USDC contract, setting the Uniswap V3 Router as the spender with an allowance of 1,000 USDC (or unlimited, depending on wallet settings). After the approval transaction confirms, the user submits the swap transaction, and the router calls transferFrom() to move the USDC into the liquidity pool.
• Outcome: If exactly 1,000 USDC is authorized and spent in this illustrative flow, the finite allowance is exhausted. An unlimited allowance may remain active until changed, exposing future balances as well.

2. Aave Lending Deposit

• Scenario: A yield farmer deposits 50 WETH into Aave V3 to earn interest and use it as collateral for borrowing stablecoins.
• Implementation: In a standard supply flow, the user authorizes the applicable Aave Pool contract to transfer WETH. A successful supply credits the corresponding aToken position. The exact approval or permit options depend on the asset and interface.
• Outcome: A successful supply can accrue variable interest. An exact finite allowance is exhausted if the full authorized amount is transferred; actual rates and collateral eligibility follow the market rules.

3. Badger DAO Exploit (December 2021)

• Scenario: In December 2021, BadgerDAO suffered a major frontend compromise that induced users to grant malicious token approvals. Its recovery account distinguishes this phishing attack from a compromise of its core smart contracts.
• Implementation: The compromised interface tricked users into granting malicious token approvals. The attacker then used those permissions to transfer assets. Existing approvals to legitimate Badger contracts alone did not automatically authorize the attacker’s address.
• Outcome: The incident demonstrated that a compromised frontend can obtain dangerous permissions even when users retain their keys. Review the spender in every approval rather than trusting the appearance of a familiar website.

4. ERC-2612 Permit on a Compatible Token

• Illustrative scenario: A user wants to authorize a deposit of a token that implements ERC-2612 without sending a separate approve() transaction.
• Implementation: The user signs a permit specifying the owner, spender, value, nonce, and submission deadline. A relayer or application submits it, optionally alongside transferFrom(). DAI’s original permit uses a different interface with a boolean allowed field, so it is not interchangeable with an exact-amount ERC-2612 permit. (Source: ERC-2612 permit specification)
• Outcome: The user may avoid paying gas directly if someone else submits the transaction. Once granted, a standard allowance does not expire at the permit deadline. Nonces prevent reuse of the same permit, not misuse of an active allowance.

Comparison Table

Feature	ERC-20 Allowance (approve/transferFrom)	EIP-2612 Permit (Off-Chain Signature)	Permit2
Approval Method	On-chain approve() transaction	Off-chain EIP-712 signature	Single on-chain approval to Permit2 contract, then off-chain signatures per dApp
Gas Cost for Approval	Implementation- and state-dependent gas	Signing is off-chain; on-chain execution costs gas	Initial approval and subsequent execution cost gas
Expiration Support	No native expiry	Submission deadline; granted allowance has no native expiry	Yes (configurable expiration per allowance)
Front-Running Risk	Allowance-replacement race	Replay protection; replacement race still applies	Permission- and integration-specific risks
Revocation	Requires on-chain approve(spender, 0) transaction	Revoke allowance; assess outstanding signed permits separately	Revoke downstream permission or token approval to Permit2, as appropriate
dApp Compatibility	ERC-20 interface; implementation quirks apply	Only tokens implementing EIP-2612	Compatible ERC-20 tokens, subject to integration behavior
Security Model	Each dApp holds its own allowance independently	Signed allowance update with submission deadline	Shared approval contract with separate downstream permissions

Related Terms

• ERC-20 — The foundational fungible token standard on Ethereum that defines the allowance mechanism through its approve(), transferFrom(), and allowance() functions.
• Token Approval — The act of calling approve() to set a spender’s allowance, granting delegated spending permission for a specific token.
• ERC-2612 Permit — Signed authorization that a submitter executes on-chain to update an allowance. It can avoid a separate user-paid approval transaction.
• Permit2 — Uniswap’s universal token approval contract that consolidates and manages allowances across multiple dApps with time-limited, signature-based permissions.
• transferFrom() — The ERC-20 function that allows a spender to transfer tokens from an owner’s account, consuming the previously set allowance.
• Approval Checker — A tool for discovering spending permissions. Coverage varies by chain and implementation; verify the tool and current on-chain allowance.

FAQ

Conclusion

A token allowance grants real spending authority even though it does not transfer tokens immediately. Check the spender and amount, distinguish a signature deadline from permission expiry, and confirm revocations on the correct chain.

Further reading on UEEx: Centralized and decentralized exchanges; Crypto security and risk; Encryption and cryptography

Sources

ERC-20 token standard

ERC-2612 permit specification

OpenZeppelin ERC20 implementation reference

Permit2 permission architecture

UEEx.com | Cryptocurrency Exchange Glossary | © 2026

This glossary entry provides educational information about blockchain technology and is not investment advice.