Token approvals are permissions written to a blockchain, not settings stored in an app. When you approve a contract to spend a token, you record on-chain that a particular address may transfer up to a particular amount of that token — now, or at any point in the future, without asking you again.
The reason token approvals matter is that they outlive everything you do to your own software. You can uninstall the app, switch wallets, buy a new laptop and change your habits, and the approval still sits there on the chain. Whoever controls that contract keeps the permission you granted, for as long as it exists.
- An approval is a standing permission with a limit, not a one-off payment authorisation.
- Unlimited approvals are the default in most interfaces, so a single bad contract can drain a token balance much later.
- Approvals live on-chain and survive wallet software changes, reinstalls and new devices.
- Every new approval is a new risk surface, and its size should be a decision rather than a click.
What an approval actually permits
It permits a specific contract address to call a transfer function on your token balance, up to the allowance you set. The token contract enforces the permission; your wallet is only the interface that wrote it.
That distinction explains a common confusion. People assume the wallet is guarding them, and that a compromised or unfamiliar site only affects the session it was opened in. In practice the wallet was a pen. The permission is now a line in a public ledger that any future transaction from that contract can exercise.
Allowance versus balance
The allowance is a ceiling, not a transfer. Approving a large number does not move anything today; it means the contract may move up to that number whenever it chooses. This is why an approval can sit dormant for months and then be used in a single transaction you never see coming.
Approvals are per token and per network
Approving one token on one network says nothing about another token, or the same token on a different chain. A wallet used across several networks can accumulate a large number of independent permissions, most of which nobody remembers granting.
Why unlimited is the default
Unlimited is the default because it saves the application a second transaction later. If a trading interface asked for an exact allowance every time, you would sign an approval before every trade, pay gas twice, and blame the interface for being slow.
So the interface asks for the maximum, and the maximum is presented as a convenience. The trade-off is asymmetric: the app saves one signature, and you carry an open-ended permission for as long as the contract exists. That is a reasonable trade for a contract you trust and a poor one for a contract you will never use again.
Some interfaces let you edit the allowance before signing. It is usually a small link rather than a prominent field, which tells you what the designers expect. Editing it is worth the extra ten seconds for anything involving a token you hold in size.
Token approvals outlive your wallet software
Reinstalling a wallet, restoring a seed into a different app, or moving to new hardware changes nothing about existing token approvals. They are attached to the address, not the software, and the address is derived from your seed.
This produces the least intuitive consequence in the whole topic: a wallet you consider “fresh” can still carry permissions granted years ago by a version of yourself using different software. The only way to see them is to look them up on-chain, and the only way to remove them is to send a transaction that sets the allowance back to zero.
| Permission type | What it authorises | Scope | How it ends |
|---|---|---|---|
| Exact-amount token approval | One contract may move up to a set number of tokens | One token, one network, until used or revoked | Revoke, or let the allowance be consumed |
| Unlimited token approval | The same, with no practical ceiling | Your entire balance of that token, indefinitely | Only revocation |
| Operator approval for a collection | A contract may transfer any item you own in that collection | Whole collection, not a single item | Revoke the operator permission |
| Off-chain signed permit | A signature that can be submitted later to create an allowance | Until it expires or is used | Expiry, or spending the nonce |
| Native currency transfer | Nothing standing; each transfer is its own transaction | Single transaction | Already finished when confirmed |
An approval is not a memory of what you did. It is a live instruction that anyone holding the other end of it can still follow.
How to audit and revoke token approvals
Auditing means listing every allowance your address has granted and deciding which ones still deserve to exist. Most wallets surface this in a security or approvals panel, and several independent revoke tools read the same on-chain data without needing your keys.
Revoking means sending a transaction that sets the allowance to zero. It costs network fees, because it is a real state change on a real blockchain, and it requires the same care as any other transaction. A revoke tool that asks for your seed phrase is not a revoke tool.
What to look for in the list
Unlimited allowances to contracts you do not recognise. Allowances to contracts you used once and abandoned. Operator permissions for collections you no longer trade. Anything attached to an address you keep long-term but rarely use. The list is usually longer than people expect, which is the point of looking.
What revoking does not fix
Revoking stops future use; it does not undo a transfer that already happened, and it does not remove the contract’s ability to do anything you granted separately. If a token has already been moved, revocation changes nothing about that transaction.
- Open your wallet’s approvals or security panel, or an independent revoke tool, and connect read-only first if the option exists.
- List every allowance for the address and sort by unlimited first, since those carry the largest exposure.
- Identify each contract: if you cannot explain why it needs the permission, treat it as unnecessary.
- Revoke the ones you cannot justify, one transaction at a time, and confirm each transaction on your own device.
- Check that the interface shows the allowance dropping to zero rather than to a smaller number.
- Repeat on every network you actually use, because the list is per chain and rarely complete on the first pass.
- Put a reminder in your calendar to review again in a few months, since new approvals accumulate silently.
- For anything you use regularly, replace the unlimited approval with an amount close to what you actually need.
Sizing new approvals instead of clicking through
The cheapest defence is at the moment of signing: approve an amount, not a blank cheque. If an interface offers an editable allowance field, use it and set a number that covers the trade you are about to make plus a small margin.
The second cheapest defence is reading what you sign. Approval requests are distinguishable from transfers if you slow down for three seconds: a transfer moves a specific amount now, an approval grants a permission for later. Interfaces that blur the two are worth avoiding entirely.
A third habit helps more than any tool: use a separate address for experiments and unfamiliar applications, funded with what you are willing to lose. Approvals on a throwaway address cannot reach the balance you keep elsewhere, no matter how careless the session was.
0 comments
No comments yet — ask a question and we will answer it here.