What Are Token Approvals?

In brief

Under ERC-20, approve(spender, value) sets how much spender may withdraw from the caller, allowance(owner, spender) reports the remaining permission, and transferFrom(owner, recipient, value) uses it. Calling approve again replaces the current allowance; it does not add to it.

These rules are specific to ERC-20 tokens and compatible implementations. Native ETH has no ERC-20 allowance. ERC-721 NFTs and Solana tokens have separate approval or delegation models, so a wallet should not describe all of them as if they were the same permission.

An on-chain revocation prevents future spending only after the revocation is confirmed and only to the extent the token follows the expected allowance rules. It cannot return tokens already transferred, cancel a completed theft, or automatically invalidate a different approval system.

Approval, allowance, and transfer

The approval is the state-changing action. The allowance is the resulting owner–spender limit stored by the token contract. A later transferFrom is the action that actually moves tokens.

That separation lets an application perform a later operation under rules the user accepted. A DEX router can pull the swap input, a lending contract can take a deposit, and a bridge contract can lock a token. The approved spender need not wait for the owner to come back online; it can submit transferFrom whenever its own logic permits, provided the balance and allowance are sufficient.

The permission is attached to three things:

1. the ERC-20 token contract;
2. the owner address;
3. the spender address.

Approving a router for token A does not approve token B. Approving one router does not approve every contract operated by the same website. Names and logos are not identifiers; the token and spender addresses are.

Exact approvals and very large approvals

For a one-time operation, an application may request exactly the amount it expects to spend. Other applications request 2^256 − 1, the largest uint256, which interfaces commonly call an unlimited approval. ERC-20 itself describes an amount, not a special “unlimited” flag. Some implementations optimize maximum allowances by not reducing them during transferFrom, while others simply start from a very large number.

An exact approval narrows the amount exposed but may require another transaction next time. A very large approval saves repeat approval transactions but leaves a larger permission behind. Neither choice proves that the spender is safe.

Moving all of a token out of the account may temporarily leave nothing to take, but it does not necessarily erase the allowance. Tokens later received at the same address can again be exposed while the approval remains.

The allowance-change race

ERC-20 warns about replacing one non-zero allowance with another. Suppose a spender still has an allowance of 100 and the owner submits a transaction changing it to 50. If the spender sees that pending transaction, it may spend the old 100 first; after the owner’s transaction confirms, it may then have the new 50.

The standard tells client interfaces to set the allowance to zero before setting a new non-zero amount for the same spender. That takes two state changes and does not make a hostile spender harmless while the zeroing transaction is pending. Applications and libraries also use other patterns, but token behavior is not perfectly uniform; callers must handle implementations that return false, omit expected return data, or impose token-specific approval restrictions.

Permits are signed approvals, not harmless messages

ERC-2612 adds permit, which can set an ERC-20 allowance from an EIP-712 typed signature. A relayer may submit that signature, so the owner may not send a separate approve transaction or hold ETH for that step.

The important timing detail is easy to misstate: ERC-2612’s deadline is the last time the signed permit may be submitted. Once a valid permit is submitted, the resulting allowance does not expire at that deadline under ERC-2612. It remains until spent or replaced unless the token or another permission layer adds separate expiry behavior.

EIP-712 is only a format for typed signed data; it does not itself grant an allowance. Sign-In With Ethereum is also not an ERC-20 approval. Users must inspect the signature’s verifying contract, chain, spender, value, nonce, and deadline rather than assuming every message signature is a login.

Revoking safely

For a conventional ERC-20, approving the same spender for zero replaces the allowance with zero. A revocation tool normally prepares that token-contract call for the user. Check all of the following:

• the correct network and token contract;
• the exact spender address, not only its label;
• the pending transaction’s status;
• the final result of allowance(owner, spender).

Revocation is not retroactive. If a spender uses the allowance before the revocation confirms, the transfer may succeed. Revoking one ERC-20 allowance also does not revoke an ERC-721 operator, a Permit2 permission, a Solana delegate, or another owner–spender pair.

If unauthorized tokens have already moved, revocation limits further use of that permission; it does not reverse the blockchain transfer. Securing the remaining account and investigating other permissions are separate steps.

Related permissions are not ERC-20 allowances

ERC-721 has per-token approve and collection-wide setApprovalForAll. The latter can let an operator transfer every ERC-721 the owner holds from that contract, but it is not an ERC-20 amount allowance. See NFTs for the ownership model.

Solana’s Token Program records an optional delegate and delegated amount on an individual token account. Its Revoke instruction clears that account’s delegate. The security idea is similar—another address receives spending authority—but the data model and instructions are not ERC-20.

A practical reading checklist

Before authorizing a token permission, ask:

1. Which standard and chain does this instruction use?
2. Which token contract or mint is affected?
3. Who is the spender or delegate?
4. What amount can it use?
5. Does the resulting permission expire, or only the signature?
6. Can the application function with a smaller amount?
7. How will the permission be verified and revoked afterward?