Token approvals: what you authorize when you click approve

An approval is a permission, not a connection

On many token systems, an approval gives a contract or delegate permission to move a specified asset under defined rules. The exact mechanism depends on the network and token standard. Connecting a wallet to a site, signing an approval and seeing a later transfer are separate events. Closing the tab or disconnecting the interface does not necessarily change an approval already recorded on-chain.

For one concrete example, the Ethereum ERC-20 standard defines approve(spender, value) to set the spender's token allowance; a later transferFrom can use that allowance, subject to the token's rules and available balance. This example illustrates the distinction, not every network's permission system. Wallet connection is separate: MetaMask's guidance distinguishes disconnecting a dapp from changing a token allowance. What a connection lets a site see depends on the wallet and permission request.

Before signing, identify the spender, asset, amount or allowance, network and reason for the request. An application asking for an unlimited allowance may have a technical explanation, but you should understand it before accepting. A smaller allowance can limit the amount authorized under that allowance; it does not make a dishonest application trustworthy or protect other permissions.

What revocation can and cannot do

For an ERC-20 token, a new approval can replace the allowance value, including setting it to zero; other token systems can use different mechanisms. A valid revocation changes a future permission where the network and token support it. It does not reverse a transfer that already happened, repair an exposed private key or make a compromised wallet safe. Revocation itself may require a transaction and the correct fee asset. Use a wallet or permission-review tool reached through documentation you verified independently, not through a stranger's “rescue” link.

A closer check

An approval is a permission granted to a contract or spender, not a transfer itself. Check the asset, spender, allowance and revocation route, and revisit permissions after using unfamiliar applications. A small token balance does not make a broad or unlimited approval harmless.

A paper workflow

Imagine a swap application asks to spend 10 units but requests a much larger allowance. Write down the contract, token, amount and intended action. Then separate three states: connected, authorized and transferred. This prevents a site from describing a broad standing permission as if it were a one-time payment.

If a request is unclear, reject it. For incident response after a harmful approval, read what to do if you think your wallet was compromised and use the affected network's current documentation.