Permission survives the original interaction
ERC-20 separates a holder's token balance from allowances granted to spenders. An approval authorizes a particular address to use the token's delegated transfer mechanism up to the allowance. Interfaces often call a very large allowance unlimited because it avoids repeated approval transactions. The permission generally remains until consumed or changed according to the token implementation; closing a browser tab or disconnecting a website does not itself modify that on-chain state.
2 sources for this section
A concrete exposure
Suppose a user intends to swap ten tokens but grants a spender a very large allowance. If that spender is malicious, compromised, or upgraded to unsafe code, the permitted balance can be exposed beyond the original ten-token trade. Later deposits of the same token can also matter while the allowance remains. The approval normally concerns that token and spender, not every asset in the wallet, although other signed permissions may create additional exposure.
2 sources for this section
Reviewing and reducing permissions
Check the network, token contract, spender, allowance amount, and whether the spender can change behavior. A limited allowance can narrow exposure but does not make the underlying trade safe. Revocation changes future permission after its transaction is accepted; it cannot recover assets already moved and can be affected by pending transactions. Permission systems built on signed messages or additional approval contracts may add further layers. Use the exact permission model instead of assuming a single revoke button covers every authorization.
2 sources for this section
The source notesEvidence & further reading2 sources
- ERC-20: Token standard Ethereum Improvement Proposals · Primary source · accessed 2026-09-21
- Token approvals and spending permissions MetaMask · Primary source · accessed 2026-09-21