Token Allowance
Pronunciation: TOH-kun uh-LOW-uhns
Also known as: Spending Allowance, ERC-20 Allowance
Definition
Token Allowance is the amount a token owner authorizes another address or smart contract to spend on the owner’s behalf. In ERC-20 systems, the owner approves a spender and the spender later uses transferFrom up to the remaining allowance. An allowance is delegated spending permission, not a transfer and not ownership of the approved tokens. In practice, wallets and applications should display spender identity, token contract, amount, expiration or permit conditions, and remaining allowance, while users should revoke permissions that are no longer needed. The main risks are that unlimited or stale allowances can be abused if the spender contract, private key, interface, or upgrade authority is compromised.
Overview
Token Allowance is the amount a token owner authorizes another address or smart contract to spend on the owner’s behalf. In ERC-20 systems, the owner approves a spender and the spender later uses transferFrom up to the remaining allowance. For token integrations, the relevant rule can exist in smart-contract code, an upgradeable module, an issuer policy, or an off-chain compliance service. Systems should therefore inspect both the deployed implementation and the current administrative configuration instead of relying on a token name or interface label.
An allowance is delegated spending permission, not a transfer and not ownership of the approved tokens. It should be read alongside Token Transfer Limit, Token Pause Authority, and Token Blocklist. These related concepts describe different parts of the lifecycle, so substituting one label for another can hide who has authority, which balance is measured, or what action is actually permitted.
Operationally, wallets and applications should display spender identity, token contract, amount, expiration or permit conditions, and remaining allowance, while users should revoke permissions that are no longer needed. A production system should preserve the applicable network, contract or asset identifier, units and precision, rule version, responsible role, effective timestamp, and the transaction or source record used to make the decision. Changes should be observable and reconciled rather than inferred from a wallet display alone.
The principal risks are that unlimited or stale allowances can be abused if the spender contract, private key, interface, or upgrade authority is compromised. Teams should test normal and exceptional paths, including failed transactions, delayed external services, upgrades, role changes, unavailable redemption or transfer routes, and inconsistent data between blockchain, market, legal, and accounting systems.
Key Takeaway
Token Allowance delegates spending power, so the verified spender, approved amount, remaining allowance, and revocation path must be checked.
Sources
- ERC-20: Token Standard — Ethereum Improvement Proposals (2026-08-02)
- OpenZeppelin ERC-20 Documentation — OpenZeppelin (2026-08-02)
- OpenZeppelin Access Control — OpenZeppelin (2026-08-02)