What does a token approval allow?
Many applications need two steps. First, your address calls approve(spender, amount) on the token contract. Later, the approved spender can call transferFrom within that allowance.
The spender is an address—often a smart contract—not the friendly name displayed by a website. An approval can remain after you close the page. This is why disconnecting a wallet from an interface does not necessarily revoke token allowances.
A door-pass example
Imagine a pass that opens one storeroom door and allows up to 100 boxes to leave. Signing the pass does not move a box. It authorizes a named holder to move boxes later, within the limit. An unlimited approval is closer to a pass with no useful box limit.
The analogy has a limit: token contracts and application contracts can contain bugs or upgrade controls, and the “door” may be operated by more than one system component.
A safer review routine
- Open the application from a bookmark or independently verified address, not an unexpected message.
- Confirm the network and token contract before reading the friendly token symbol.
- Inspect the spender address, not only the site name, and check that it belongs to the action you intended.
- Compare the requested amount with the amount you actually plan to use. Prefer a bounded allowance when the interface supports it and the extra transaction cost is acceptable.
- Read the wallet’s final confirmation again before signing; reject it if the network, asset, spender, or amount changed.
- After the action, verify the allowance on a trusted block explorer or wallet tool and revoke permissions you no longer need. Revocation is itself an onchain transaction and costs a fee.
Approval safety also depends on signatures. For example, ERC-2612 permits use signed messages to set allowances when submitted onchain. “I see no approvals” is not proof that every permission path is closed. Revocation does not undo a completed transfer or repair an exposed private key.
The distinction between disconnecting an app and revoking an allowance matters: the first changes a connection; the second changes a particular permission. Inspect the resulting onchain state, not just a closed browser tab.
Sources
- EIP-20: Token Standard — normative interface, accessed 13 September 2026.
- Ethereum.org: ERC-20 token standard — accessed 13 September 2026.
- ERC-2612: Permit Extension — signed-approval mechanism, checked 13 September 2026.
- MetaMask: Revoking token allowances — disconnect/revoke distinction, checked 13 September 2026.
See something wrong? Brokzi logs material changes. Prepare a correction note.



