La page se tourne.
Le prochain chapitre arrive…
Psst… appropriez-vous votre lecture.
Polices et thèmes se trouvent dans Apparence. Vos yeux ont aussi leur mot à dire.
Le prochain chapitre arrive…
A token allowance large enough to let a designated spender move present and potentially future balances without asking for another allowance each time.
Vérification de la lecture vocale du navigateur…
Cette lecture est actuellement disponible en anglais. L’interface utilise la langue choisie.
Lire l’original anglais →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.
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.
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.