Token approvals: why disconnecting an app does not revoke access

A wallet can keep the same token balance after an approval and still have a different security position. The change is a permission: another address may now be able to move a specified token without a fresh approval for every transfer.

That distinction explains why a wallet balance and a record of outstanding permissions answer different questions. This explainer concerns common ERC-20 token approvals on Ethereum-compatible networks. Native assets, NFTs and smart-account permissions can follow other rules.

A balance and an allowance are separate records

The ERC-20 standard defines both a balance and an allowance. A balance records tokens associated with an address. An allowance records how much a particular spender is permitted to transfer from that address through the token contract's delegated-transfer mechanism.

Consider a hypothetical account holding 500 units of a token. Approving a spender for 100 does not itself send those 100 units away. It permits subsequent transfers within that authorization, subject to the token's implementation and available balance.

This is technical spending authority, not a conclusion about legal ownership. Nor is one ERC-20 approval automatically permission to move every other asset in the wallet. The relevant scope is the token contract, the account granting permission and the spender receiving it.

A review of the approval therefore needs more than the application's name. The actual spender address and amount are the fields that define the authorization.

The amount describes the potential exposure

An application may request a specific spending limit or a very large allowance commonly described as unlimited. The latter can reduce repeated approval transactions, but leaves a broader permission in place.

MetaMask's approval guidance explains why excessive allowances matter if an approved contract is exploited or the authorization is malicious. The immediate trade amount and the spending permission should be examined separately.

For example, a screen might describe a 20-token exchange while requesting permission to spend far more. The exchange describes the intended action; the allowance describes what the spender may be able to do. Those two amounts need not match.

A clear interface should make this difference legible. An approval is easier to assess when the reader can identify its scope and purpose without translating a promotional label into a contract address.

A signature can also create authority

An approval does not always begin with an ordinary transaction submitted by the token holder. For tokens that implement ERC-2612, a signed message can authorize an allowance update. Another party can submit that message to the token contract.

The signed data includes the spender, amount, nonce and submission deadline. The scheme also binds the signature to a domain associated with the contract and chain. A valid signature is therefore an authorization with specific semantics, even when signing it does not immediately consume the holder's gas.

The deadline needs careful interpretation: in ERC-2612 it limits when the permit can be submitted. It does not, by itself, make the resulting ERC-20 allowance expire at that time.

The practical question is what the message authorizes once used. A wallet prompt saying “sign” does not answer that question on its own.

Some systems introduce a second permission layer

Uniswap's Permit2 documentation describes a separate contract that first receives a standard token approval. It then manages more specific spending permissions.

Its two main mechanisms differ:

• SignatureTransfer uses a one-time authorization for a transfer or a batch of permitted tokens. It does not create a standing Permit2 allowance.
• AllowanceTransfer maintains a spending limit and expiration for a designated spender. When authorized by signature, its signature-submission deadline and allowance expiration are separate fields.

Neither mechanism should be confused with the underlying token approval granted to Permit2. A one-use transfer permission does not mean that underlying approval has disappeared.

An understandable permission summary therefore identifies both layers. It states which token can be accessed, which contract holds the initial allowance, and which application-level authorization is being requested. Similar-looking wallet prompts can represent different arrangements.

Disconnecting does not remove an allowance

MetaMask distinguishes disconnecting an application from revoking its token approvals. Removing a wallet connection does not erase an existing on-chain allowance. Revocation requires the relevant on-chain change and generally incurs a network fee.

For an ordinary ERC-20 allowance, setting the approved amount to zero removes that permission once the change takes effect. This changes that spending permission; it does not recover tokens already transferred. An unused signed permit can be a separate authorization. One implication of ERC-2612's separate allowance and nonce rules is that zeroing an existing allowance does not necessarily invalidate an unused permit. It may still set the allowance again if its nonce, deadline and other validation conditions remain satisfied.

A practical permission review

Use these checks when reviewing an approval or deciding whether an old permission is still needed:

1. Confirm the account and network. An allowance belongs to a particular account and token contract; checking another network can give an incomplete picture.
2. Identify the spender and limit. Record the token contract, spender address, remaining allowance and any expiration. Compare that scope with the action you intended.
3. Review permissions through your wallet's official instructions or the network explorer's approval checker. If you revoke an allowance, confirm that the transaction succeeded and that the intended allowance changed.
4. Consider signatures as well as transactions. A list of current on-chain allowances is not a complete record of every authorization you have signed. For Permit2, distinguish the token's approval to Permit2 from the application's permission inside it.

The useful record is a permission inventory alongside the asset inventory. For each approval, ask: which token, which spender, how much, and until when? Those answers reveal control that a balance alone cannot show.

Source review: 22 September 2026.