Token Allowances: How to Review and Revoke Approvals

A permission, not a payment

ERC-20 tokens do not let a contract pull funds from your wallet by default. The standard gives the token owner an explicit function, approve(address _spender, uint256 _value), which grants the spender an allowance. The spender then calls transferFrom to move tokens up to that amount.

EIP-20 is precise about the semantics: approve allows the spender “to withdraw from your account multiple times, up to the _value amount”. Calling approve again with the same spender replaces the previous allowance rather than adding to it. The read-only allowance(owner, spender) function returns what remains.

That design is why the approval step exists. A decentralised exchange cannot debit your balance directly; it needs a permission recorded in the token contract. The permission is public, persistent, and independent of the website that requested it.

What the number means

The _value in an approval is the ceiling, not a reservation. If you approve 500 TOK, the spender can move 500 in one call or 100 five times. If you approve the maximum uint256, the spender can move your entire balance of that token, now or later.

The token standard itself warns about approval races: a user interface should first set an allowance to zero before assigning a new value to the same spender, because a spender watching the mempool can spend the old allowance before the new one lands. EIP-20 notes that contracts cannot enforce the reset without breaking compatibility, so the responsibility sits with the interface and the user.

Three practical rules follow:

• Approve what the trade needs, not the maximum. A limit of the exact amount caps the loss if the spender is compromised.
• Read the spender address. The permission is granted to a contract, not to a brand. A phishing site can ask you to approve a contract that looks like a familiar router.
• Treat unlimited approvals as standing risk. They are convenient, and they remain usable indefinitely unless the spender contract is paused or the allowance is revoked.

How to review approvals

A wallet does not show every permission on its main screen. The common places to look are:

• Wallet portfolio tools. MetaMask Portfolio has a Spending Caps view that lists token approvals and can submit revocations. MetaMask’s help centre lists Ethereum Mainnet, Polygon, BNB Chain, Optimism and Base as supported networks at the time of writing.
• Block explorer approval checkers. Etherscan and its sister explorers offer a token-approval tool that reads the token contracts for a given address.
• Third-party revoke tools. Services such as Revoke.cash aggregate approvals across chains. They are convenient, and they are an additional trusted component; connect only when you intend to revoke.

A review should answer four questions for each row: which token, which spender, how much remains, and whether the spender is a contract you still use. An approval to a contract you no longer recognise is the one to remove first.

How revocation works

Revoking is not a special protocol message. It is another approve call, with the same spender and a value of zero. The token contract overwrites the allowance; allowance then returns zero, and transferFrom fails for any amount above zero.

Consequences:

1. It is an on-chain transaction. You pay gas, and you need the native token of that chain to pay it.
2. It affects one token and one spender at a time. Ten approvals mean ten writes unless a tool batches them.
3. It does not reverse history. A transfer that already executed is settled. Revocation only prevents the next one.
4. It can be undone by a future approval. The permission is a state, not a lock.

The MetaMask guidance draws the distinction that matters most: disconnecting a dApp stops it from seeing your address in that session, while revoking removes its ability to move tokens. The two actions are not substitutes.

A worked example

Suppose a wallet holds 1,000 USDC and approves a router for the maximum amount to swap 100 USDC. The swap uses 100 USDC through transferFrom; the allowance falls to 900 USDC if the router decremented it correctly. The remaining 900 is still spendable by that router.

If the router contract is later exploited, the attacker can call transferFrom for the remaining allowance without any new signature from the wallet. Revoking to zero before the exploit would have capped the loss at zero; revoking after the transfer executes does nothing.

This is why the useful habit is periodic review, not a one-time cleanup after a headline. Approvals accumulate quietly, and the wallet’s balance is the exposure ceiling.

What approvals do not cover

An allowance is specific to a token contract and a spender. It does not grant access to ETH itself, to tokens you have not approved, or to a different chain’s copy of the same ticker. NFT marketplaces use a separate approval function for collections, which is outside the ERC-20 allowance model and should be reviewed in the same spirit.

It also does not protect you from signing a malicious transaction. If you sign a call that transfers your tokens directly, the approval layer is irrelevant. The CEX vs DEX guide explains the custody difference; the approval layer is the part of self-custody that has no central intermediary to reverse a mistake.