What Is a Token Approval? How ERC-20 Spending Permissions Work

A token approval is a spending allowance

Think of an approval as an instruction attached to a particular token balance: this spender may move up to this amount on this owner’s behalf. It delegates a limited capability without giving the spender the owner’s private key.

The ERC-20 standard defines three relevant operations: approve sets permission, allowance reports the remaining amount, and transferFrom lets an authorized spender move tokens. The approval itself does not perform the intended swap or deposit.

The scope matters. Approving one token does not, through that approval alone, authorize spending every asset at the address. The permission concerns an owner, a spender, and a specific token contract on a specific network.

A spending allowance is a useful mental model, but it has limits: the token contract enforces an amount, while the spender’s code determines which actions are available. A familiar application name is not a substitute for checking the actual permission.

Where the permission lives and how spending works

The permission lives in blockchain state, rather than a browser cookie. In OpenZeppelin’s ERC-20 implementation, balances and allowances are stored separately. Allowances associate each owner with each approved spender.

1. The owner authorizes an approval transaction targeting the token contract.
2. The token contract records the specified spender and allowance.
3. Later, that spender calls transferFrom, naming the owner, recipient, and amount.
4. The token checks the available allowance and balance. In this implementation, insufficient allowance or balance makes the operation revert.
5. A successful transfer updates balances and, for an ordinary finite allowance, reduces the remaining spending permission.

The transaction must also be included in the chain; clicking a website button is not the same as a confirmed state change. A submitted revocation should therefore be checked after confirmation, rather than treated as effective immediately.

The important separation is between authorization and execution. The owner grants a capability first; the spender uses it later within the limits of the token and application contracts.

Why approval can succeed while a swap never happens

A swap interface can combine several different operations into one journey. Uniswap’s approval guide, for example, distinguishes an onchain token approval, a signature-based permission, and the swap transaction. Other workflows differ, so do not assume every application presents exactly two prompts.

This is why a successful approval is not proof that you received the output token. If a later swap is never submitted, or fails in a separate transaction, an earlier confirmed approval is not automatically reversed.

Read the operation in the transaction history. An approval answers whether spending was authorized. A swap result answers whether the intended exchange actually executed. Checking only for a green confirmation can conflate the two.

An example: the same swap, different remaining exposure

Hypothetical example: Maya holds 1,000 units of a fictional standard ERC-20 token and wants to swap 100. Assume ordinary finite allowances decrease when spent, there are no transfer fees, and no other transactions occur.

She approves a router to spend 100 units. Approval alone leaves her balance at 1,000. The router then completes the intended swap using all 100 units. Her input-token balance becomes 900, and that router’s allowance becomes zero.

Now change one condition: Maya approves 500 units before the same 100-unit swap. After execution, her input-token balance is still 900, but the remaining allowance is 400.

The difference is not the completed trade. It is what remains authorized afterward. Under these assumptions, another attempted 100-unit spend would fail the allowance check in the first scenario but could pass it in the second. Whether the router can actually initiate such a transfer depends on its code and access controls.

This example separates three quantities worth checking independently: current balance, intended transaction amount, and remaining allowance. They need not match.

What an unlimited approval changes

Applications may request a very large allowance to avoid repeated approval transactions. In OpenZeppelin Contracts 5.x, the maximum uint256 value has special treatment: transferFrom does not reduce that allowance. This behaves as an infinite approval, although actual spending still requires sufficient balance.

The convenience is fewer future approval steps. The tradeoff is a permission that can remain relevant beyond today’s transaction. Spending the present balance does not necessarily eliminate the permission; tokens received later may also fall within its scope.

Uniswap’s allowance guidance distinguishes exact, larger finite, and unlimited approvals. Exact amounts narrow exposure but can require fresh approvals for later activity. A larger allowance reduces friction while leaving more spending authority outstanding.

A smaller allowance limits one dimension of risk. It does not establish that the spender is legitimate, that the token behaves normally, or that the transaction has acceptable terms.

Disconnecting and revoking change different things

MetaMask explicitly distinguishes disconnecting from revoking. Disconnecting ends a website’s wallet connection; it does not remove existing token approvals.

For an ordinary ERC-20 allowance, revoking generally means setting the same spender’s allowance to zero. MetaMask’s revocation guide explains that onchain revocations require transactions and network fees. It also describes checking permissions through the relevant network’s block explorer or an allowance-management interface.

Choose the correct network, owner account, token, and spender. After confirmation, verify the resulting allowance. Clearing a permission on one network does not clear separate permissions elsewhere.

Revocation prevents future use of that allowance once effective. It does not reverse completed transfers or solve a compromised private key. An attacker who controls the account can authorize new transactions, so that situation extends beyond allowance management.

Changing a limit has an ordering risk

The ERC-20 specification warns about replacing an existing allowance directly: a spender may use the old allowance before the replacement confirms, then use the new one afterward. An amount entered in your wallet is not a guarantee about which transaction will execute first.

The standard recommends interfaces set an existing allowance to zero before setting another nonzero amount. This helps separate the two permissions, but cannot undo spending that occurs before the zeroing transaction takes effect. If you distrust a spender, account for outstanding permission while a change is pending.

A gasless signature can also authorize spending

Not every spending authorization begins with the owner submitting an approval transaction. ERC-2612 lets supporting tokens accept a signed permit that changes an allowance when submitted onchain. Someone other than the owner can submit it.

A permit includes the spender, amount, nonce, and submission deadline. The nonce helps prevent reuse. Importantly, the deadline limits when that permit can be accepted; it does not automatically make the resulting ERC-20 allowance expire at that time.

Separately, Uniswap’s Permit2 supports signature-based transfers and allowance-based permissions through an intermediary contract. Its models include one-time signature transfers and expiring allowances. These should not be confused with a token’s native ERC-2612 permit.

According to Uniswap’s Permit2 explanation, users first grant the Permit2 contract an onchain token allowance, then authorize application spending with signatures. A malicious signature can therefore matter even when signing itself charges no network fee.

EIP-712 structures signed data so wallets can present its fields for inspection. It does not make the requested action trustworthy. Check the verifying contract, network, spender, amount, and any expiry fields rather than judging a request by whether it is free to sign.

What to check before approving and afterward

The practical question is how closely the permission matches your intended action. Treat the application interface, wallet prompt, and recorded allowance as three views to reconcile.

• Identify the scope. Confirm the owner account, network, token contract, and spender against the application’s official deployment information.
• Compare amounts. Check whether the request covers only the intended transaction or a substantially larger allowance.
• Read signature permissions. Check what can be submitted later, by whom, and under which limits.
• Check completion. Distinguish a confirmed approval from a completed swap or deposit.
• Review what remains. Inspect unused permissions and revoke those you no longer want through a verified interface.

Do not connect to an unfamiliar “security” website merely because a message says an approval is dangerous. Permission management itself involves authorizing actions; verify the tool before using it.