Token Approvals: The Permission You Granted Months Ago and Forgot
By NorwegianSpark Editorial — written with AI assistance and reviewed by the NorwegianSpark SA editorial team | Last updated: 2026-08-19
This article contains affiliate links. We may earn a commission at no extra cost to you. Full disclosure
A wallet is emptied. The seed phrase was never written down anywhere, never typed into a website, never photographed. No malware, no phishing site visited that week, no leak. And the tokens are gone anyway.
This is the most common way self-custodied funds actually disappear, and almost nobody who suffers it understands what happened. Nothing was stolen from the wallet. The wallet gave something permission, months earlier, and that permission never expired.
What an approval actually is
Tokens on Ethereum and compatible chains are not held by your wallet in the way coins are. They are entries in a contract's ledger, and that contract decides who may move them.
The standard that defines this is EIP-20, and it contains two functions that matter here. One lets you send tokens yourself. The other, approve, lets you nominate somebody else to send them on your behalf.
The spec's own description of it is worth reading exactly as written (EIPS/eip-20): approve "allows _spender to withdraw from your account multiple times, up to the _value amount", and "if this function is called again it overwrites the current allowance with _value".
Three things follow directly from that sentence, and all three surprise people.
- It is not one-time. The spender can draw repeatedly until the allowance is used up.
You can read the current state at any time — EIP-20 also defines allowance(owner, spender), which "returns the amount which _spender is still allowed to withdraw". The information has always been public. It is simply not shown to you.
Why you granted it in the first place
Every decentralised exchange, lending market, staking contract and bridge needs this permission. That is not a design flaw; it is how a contract moves your tokens at all.
The problem is the amount. Approving exactly what a swap needs means a new approval, and a new transaction with a new fee, every single time. So interfaces default to approving a very large number instead — effectively unlimited — which makes the first transaction the only approval you ever need.
That default is convenient, permanent and the reason a compromise of that contract, years later, reaches your wallet. Ethereum.org's security guidance is blunt about it: do not allow unlimited spend limits, because "an unlimited spend could enable the smart contract to drain your wallet" (ethereum.org/security).
The signature version, which is worse
There is a second route to the same permission, and it is the one behind most modern wallet drains.
EIP-2612 adds a permit function, which "allows users to modify the allowance mapping using a signed message, instead of through msg.sender" (EIPS/eip-2612). The signed data is structured with EIP-712 so wallets can display it.
The motivation is legitimate — it removes a whole transaction, and it means a user who holds tokens but no ETH for gas can still use them. The consequence is that a signature, with no transaction and no fee, can grant a spending permission.
That breaks the mental model almost every user has. People are trained to be careful about transactions and casual about signing, because signing is how you log in to a site and usually costs nothing. A permit signature looks like a login and behaves like an approval.
If a wallet asks you to sign something you did not initiate, or something whose plain-language description you cannot follow, the correct response is to reject it. There is no downside to rejecting a legitimate request; you can always redo it.
Auditing what you have already granted
The approvals you hold now were granted by you, are visible on-chain, and can be listed.
- Use a revocation tool for the chain you are on. Several exist, they read the same public allowance data, and reputable wallets increasingly include one. Ethereum.org links its own guidance on how to revoke smart contract access.
The EIP-20 spec even carries a note about changing allowances: clients should set an allowance to zero before setting it to a new value, because of a front-running attack vector in changing it directly. Most modern interfaces handle this for you, and it is a good illustration of how much sharp edge sits under a button labelled "Approve".
Habits that make this a non-issue
- Set a spend limit when the wallet offers one. Approving the amount you are actually trading, rather than the maximum, converts a permanent exposure into a temporary one.
Frequently Asked Questions
Does revoking an approval move my tokens?
No. Revoking sets the allowance for that spender to zero. Your tokens do not move, your balance does not change, and nothing about your wallet's contents is affected. It only removes somebody else's ability to move them.
Do token approvals expire on their own?
Not under EIP-20. The standard defines no expiry, so an allowance persists until it is spent down or explicitly changed. An approval granted years ago is still live today unless you changed it.
Is an unlimited approval always a mistake?
Not always, but it is always a permanent exposure to that contract. The trade-off is one transaction fee per swap against an open-ended permission, and for a wallet holding meaningful value the fee is usually the cheaper side of that trade.
How can signing a message cost me tokens if there is no transaction?
Because EIP-2612 lets an allowance be set by a signed message rather than by a transaction. The signature is the authorisation; somebody else submits the transaction that uses it and pays the fee. This is why an unexpected signature request should be rejected rather than approved.
The short version
Approvals are not an attack. They are a feature you use every time you touch a decentralised protocol, and the risk comes entirely from their being unlimited and permanent by default.
Audit them once, get in the habit of revoking what you stop using, and treat signature requests with the same suspicion as transactions. That covers the great majority of the ways a self-custodied wallet actually gets emptied — far more than any advice about seed phrases, which most victims never mishandled at all.
Sources: EIP-20 and EIP-2612 (eips.ethereum.org) and the ethereum.org security guidance, all read 19 August 2026.
Content on AICryptoCoin is for informational purposes only and does not constitute financial advice. Always do your own research and consult a qualified financial advisor before making investment decisions.