ERC20 Token Allowances: Who Can Spend Which Tokens?

ERC20 token allowances let a wallet owner authorize a particular spender to transfer a particular token, up to a recorded amount. An allowance is separate from the wallet’s token balance. Understanding the owner, token contract and spender together explains why an approval can remain relevant after a website disconnects, and why approving a payment does not itself move the tokens.

The permission lives in the token contract

The ERC20 specification defines approve, allowance and transferFrom alongside the ordinary transfer operation. A direct transfer moves tokens at the instruction of the sender. With an allowance, the owner first gives another address permission to spend; that spender can then use transferFrom within the token contract’s rules.

The address shown as the spender matters as much as the amount. A recognizable website name is a useful interface label, but the permission is recorded against an address. An approval for one spender is not permission for every application that uses the same token. Equally, the approval does not extend automatically to every other token in the wallet.

For someone reviewing a wallet request, that creates a concrete reading order. Identify the network and token contract, confirm the spender address through a trusted source, then read the amount being authorized. A logo or familiar ticker cannot establish all of those facts.

The relationship is easy to lose in a transaction history. An approval and a later transfer can be separate transactions, initiated at different times. Looking only for the transaction that originally added tokens to a wallet will not explain every permission that can affect them.

A balance and an allowance answer different questions

Consider a hypothetical wallet holding 80 units of a token. Its owner approves a spender for 30 units. The balance describes what the owner currently holds; the allowance describes how much that spender is authorized to take through the delegated transfer mechanism.

If the spender transfers 12 units using the usual finite-allowance behavior, the balance and remaining allowance both change. The remaining authorization is 18 units. A later incoming transfer can increase the owner’s balance without creating a new approval. Conversely, a large allowance does not manufacture a balance or guarantee that a transfer can succeed.

This distinction becomes more important when an interface offers a very large spending cap. OpenZeppelin’s ERC20 implementation treats the maximum unsigned integer value as an infinite allowance and does not reduce it when spending through transferFrom. That is an implementation detail to recognize when inspecting a token, not a claim that every token behaves identically.

A wallet display that says “unlimited” is therefore describing a permission choice, not an estimate of the next payment. The practical question is whether the permitted amount matches the intended relationship with that spender. A one-off purchase and repeated use of a service can lead to different authorization decisions.

Replacing an allowance has an ordering problem

ERC20’s approve operation sets an allowance to the supplied value. It does not simply add that value to the amount already approved. That replacement rule can be surprising when an owner thinks in terms of topping up a spending budget.

There is also a transaction-ordering risk when changing an existing nonzero allowance. The ERC20 specification discusses a scenario in which a spender uses the old allowance before the replacement takes effect, then can use the newly approved amount afterward. The intended new cap does not necessarily describe the total spent across that transition.

The specification recommends that user interfaces set an allowance to zero before setting a different nonzero value as a mitigation. It does not require token contracts to enforce that sequence. A zero-reset workflow also should not be presented as a universal safety guarantee: already executed transfers remain executed, transactions need confirmation, and token implementations can differ.

For a product team, the explanation belongs near the permission change. “Update cap” is incomplete if a user reasonably reads it as immediately replacing every opportunity to spend. Pending transactions and the spender’s existing authorization affect what can happen before the new state is confirmed.

Disconnecting a website leaves a different boundary

A website connection lets an application interact with a wallet interface under the connection’s permissions. The token approval is a separate on-chain authorization. MetaMask’s allowance-revocation guide explains that disconnecting a site does not revoke its token approvals.

That explains a common mismatch between a wallet’s connected-sites screen and its token permissions. Removing a connection can end the convenient route through which a website requests actions, while a previously approved spender still has an allowance recorded in the token contract.

Revocation changes that on-chain permission and can require a network transaction fee. It should be checked on the intended network for the intended token and spender. A revocation request that refers to a different contract does not establish that the original permission was removed.

Revocation also has a time boundary. It can restrict later use of the permission after the change takes effect; it cannot reverse tokens already transferred. Reviewing the current allowance and reviewing a disputed transaction are related investigations with different evidence.

What a careful approval screen should explain

A useful interface makes the token contract and spender inspectable, shows the requested amount in understandable units, and distinguishes the approval from the eventual purchase or swap. It should also make a persistent permission legible when the next action requires only a small amount.

These are product-design implications of the permission model, not evidence that a particular spender is safe. An address can be correctly identified and still belong to software with bugs or operational risks. The ability to read an allowance does not audit the application that can use it.

The same separation helps during support. A report saying “the wallet is disconnected” does not settle whether an allowance remains. A report saying “the approval succeeded” does not prove that the intended purchase completed. Each claim needs the corresponding connection state, token authorization or transfer evidence.

Our Crypto research desk covers the surrounding wallet and payment infrastructure. For allowance questions, keep the unit of investigation narrow: one owner, one token contract and one spender on a specified network.

Reporting & Sources

Reviewed October 22, 2026. This explainer uses the original ERC20 standard, the relevant allowance and transfer sections of OpenZeppelin Contracts 5.x, and MetaMask’s revocation documentation. The numerical wallet example is hypothetical. Implementation-specific behavior is identified explicitly; this article does not evaluate individual tokens or spenders.