Token Allowance

Overview

Why Token Allowance matters

Some decentralized payment and exchange applications need to transfer tokens as part of a later action, rather than asking users to send tokens immediately to the application. Allowances separate the user's consent to let a contract access funds from the contract's later execution of that access. The model is powerful but creates permissions that can outlive a single transaction.

How it works

On a standard ERC-20 token, the owner calls approve(spender, amount) to set the spender's limit. A permitted contract can later call transferFrom(owner, recipient, amount), which typically reduces the relevant allowance and transfers the tokens if the owner has enough balance. The authorization is recorded in token-contract state; it is not a generic permission covering every asset in the wallet. Some token designs use permit-style signed approvals, but those signatures can be just as sensitive as on-chain approvals. A checkout integration should explain when an approval is required and whether a second transaction will actually move the tokens. Developers must also be alert to token-specific approval behavior and race conditions when changing an existing nonzero allowance.

What safe approval screens should explain

A good approval interface tells users the token contract, exact spender address and allowance amount. If it asks for unlimited approval, it should explain why and allow a bounded alternative where possible. The user should also understand whether approval will be followed by a second action that performs the actual swap, deposit or payment. Permission is especially risky when the spender is an upgradeable contract whose future code may change under administrator control. Wallets and audit tools can help users inspect active allowances, but none can undo a transfer already executed by a permitted spender. A merchant should never tell customers to approve a random third-party contract merely because a token payment appears stuck; first determine whether the selected checkout flow actually requires an allowance.

A real-world payment example

A customer wants to swap 100 USDC. A decentralized exchange first requests permission for its router to spend that token, then asks the customer to submit the swap. If the router has an unlimited allowance and is later compromised, it may be able to transfer the customer's remaining USDC up to the permitted limit. A safer workflow restricts allowances where practical and reviews existing approvals.

Limits and common misunderstandings

"Approve" is not synonymous with a completed payment. A malicious website can trick a customer into signing unlimited spend permissions with no immediate loss, then take funds later. Revoking an allowance is itself an on-chain action with fees and does not reverse past transfers.

How it differs from related concepts

Token allowance authorizes potential future spending by a named contract. Transaction signing authorizes a particular signed action. A wallet connection alone should not grant spending rights, although users should inspect all requested permissions.

Explore further

Official background: technical documentation.

Related glossary terms: Smart Contract, Token Contract Address, Crypto Wallet.