A token approval is a permission stored in an ERC-20 token's contract. It lets one specific address, the spender, move up to a set amount of your tokens on your behalf. Approving moves nothing by itself, and it isn't a master key to your wallet: it covers one token, one spender and one network.
You usually run into approvals when a DeFi app asks for permission before a swap or a deposit. With the standard approve function, that prompt is its own on-chain transaction, and the permission it creates stays in place until someone changes it. This page explains the mechanism and its risks, not whether any particular app is worth using.
What is an ERC-20 allowance?
The allowance is the number behind an approval: how many tokens a spender may still take from an owner's balance. ERC-20 is the standard most fungible tokens on Ethereum follow, and it defines this mechanism in a handful of lines. Its abstract says tokens can be "approved so they can be spent by another on-chain third party" (EIP-20).
Owner, token contract and spender
Three parties are involved, and mixing them up is where most of the confusion starts.
- Owner: the address that holds the tokens, usually your wallet address.
- Token contract: the smart contract that keeps the balances for one token. It also stores every allowance for that token.
- Spender: the address that receives the permission. Often that's an app's smart contract, but the standard accepts any address, including one controlled by a person.
Each allowance belongs to exactly one combination of owner, token and spender, on one chain. Approving a spender for one token gives it nothing for another. An allowance on Ethereum Mainnet doesn't carry over to a token with the same name on a different network either, because that's a different contract with its own records. And the spender is an address, not a website. The domain in your browser tells you nothing reliable about which contract you actually approved.
Approve versus transferFrom
EIP-20 defines three functions that work together (EIP-20, ethereum.org: ERC-20):
approve(spender, value)is sent by the owner and sets how much the spender may take.allowance(owner, spender)reads how much of that permission is left.transferFrom(from, to, value)is called by the spender and actually moves tokens out of the owner's balance, within the allowance.
A made-up example, not drawn from any real wallet: you approve a spender for 100 tokens. Nothing moves. Later the spender calls transferFrom for 30 of them. If you query allowance afterwards, it returns 70, and the spender can use those 70 in one go or in several, without asking you again.
Limited and unlimited approvals
Plenty of apps don't request the exact amount one action needs. They ask for an unlimited allowance instead, a number so large it never runs out in practice. According to ethereum.org, projects do this so you approve once and pay the transaction fee once, rather than before every interaction (ethereum.org: How to revoke token access). Some wallets let you edit the amount in the approval prompt.
What the number limits
The allowance is a ceiling. It says how much the spender may move, not how much it has moved. A large allowance on its own doesn't mean a single token has left your wallet.
What it does define is how far a problem could reach. With an unlimited allowance, the spender can move every token of that type the address holds, including tokens that arrive later. Ethereum.org points out that this still applies after you've withdrawn your funds from the platform back into your wallet, and that contract permissions have no expiry date: an approval granted years ago can be used today (ethereum.org: How to revoke token access).
How much that matters depends on the spender. A contract that only ever pulls what you asked it to pull is a different case from one with a bug, an upgradeable design someone else controls, or code written to drain approved balances. The number shows the maximum possible exposure. It doesn't predict a loss.
How can you review existing approvals?
Allowances live on-chain, so anyone can read them, and every successful approve call has to emit a public Approval event (EIP-20). That public record is what lets block explorers and dedicated approval checkers show which allowances an address has granted. Ethereum.org lists several such tools (ethereum.org: How to revoke token access); this guide doesn't vouch for any of them.
Match the network, token and spender
A list of approvals is only useful if you read it against the right context:
- Network. A checker shows approvals for the chain you selected. Ethereum.org's example: connected to Ethereum Mainnet, you see Ethereum contracts, not contracts on Polygon. Every other network needs its own look.
- Address. Check that the address being inspected is the one that actually holds the tokens. Many people use more than one.
- Spender. Read the spender's address, not just the label next to it. A familiar app name doesn't prove that the contract behind it is the one you meant to approve, let alone that it's safe.
- Amount. Note whether what's left is a fixed number or effectively unlimited.
Open the checker from a bookmark or an address you've verified yourself, not from a link someone sent you.
What happens when you revoke an approval?
Revoking sets the allowance for one token and one spender back to zero. ERC-20 has no separate revoke function. Revoking simply means calling approve with a value of 0, which overwrites whatever was there before (EIP-20).
Set the allowance to zero
Because it changes on-chain state, revoking is a new transaction. Your wallet asks you to confirm it, and it costs a network fee like any other transaction; on Ethereum Mainnet that fee is paid in ETH, as the gas fees guide explains. Ethereum.org notes that processing can take anywhere from a minute to several, depending on the network, and suggests reloading the checker afterwards to confirm the entry is gone (ethereum.org: How to revoke token access).
Until that transaction is in a block, the old allowance still applies. A revocation only works going forward. It doesn't refund the fee you paid for the original approval, and it doesn't reverse anything the spender has already moved.
Reducing versus replacing a limit
A standard approve call doesn't add to or subtract from the current allowance. It replaces it (EIP-20). To go from 100 to 50, you set 50; you don't remove 50.
Changing one non-zero value straight to another has a known weak spot. A spender that sees the change coming could use the old allowance before the new one confirms, and the new one after that. EIP-20 therefore says interfaces should set the allowance to 0 first and only then to the new value. It also says the token contract itself shouldn't enforce this, to stay compatible with contracts deployed earlier. Individual tokens can still implement approve in their own way, so don't assume every token and every wallet handles a change identically.
What revocation does not do
Revoking is narrow by design. It changes one number in one token contract on one chain, and nothing else.
Disconnecting a dapp is different
Disconnecting your wallet from a website ends that site's connection to your wallet. It doesn't touch any allowance you granted while connected, and the spender can keep using it. Ethereum.org's FAQ says exactly this (ethereum.org: How to revoke token access).
A revocation also leaves these things as they were:
- Past transfers. Tokens a spender already moved don't come back.
- Open positions. According to ethereum.org, revoking doesn't end staking, pooling or lending. You stay in those positions.
- A compromised wallet. Anyone holding your private key or seed phrase can send your tokens with an ordinary transfer and doesn't need an allowance at all.
- Signed permissions and NFT approvals. Some tokens also accept an approval as a signed message instead of a transaction (EIP-2612), and NFTs have their own approval functions. Setting one ERC-20 allowance to zero doesn't cancel a signature that hasn't been used yet, and it doesn't touch NFT approvals.
What CoinVett's token check can and cannot tell you
CoinVett's Token Safety Check looks at a token contract: signals such as honeypot behavior, mint functions, proxy setups and how concentrated the holdings are. The guide on how to read a token security scan walks through those signals one by one.
That's a question about the token. Your allowances are a question about you: which spenders you've authorized, for which token, on which chain. A token with an unremarkable contract scan can still sit in your wallet with an unlimited approval to a spender you no longer trust. The Token Safety Check is not a list of your approvals and not a way to revoke them.
One detail trips people up. Native ETH isn't an ERC-20 token, even though it pays for gas on Ethereum, so it has no allowances. Apps that need ETH in ERC-20 form use wrapped ether (WETH), and WETH, like any ERC-20 token, can carry approvals (ethereum.org: WETH).
When you look at any single approval, four facts describe it completely: the network, the token, the spender's address and the amount still allowed. Together they say exactly what someone else can move from your address. A revocation changes that from the moment it confirms, for the price of a transaction fee. The past stays as it is.
Notice: The token amounts in the example are hypothetical; the sources are linked in the text. For information only, not financial advice.
Frequently asked questions
Does disconnecting a wallet revoke an ERC-20 approval?
No. The connection between a website and your wallet is separate from the allowance stored in the token contract. The spender can keep using that allowance until it is changed with an on-chain transaction, for example one that sets it to zero.
Does revoking an approval move my tokens or undo old transfers?
Neither. Revoking sets the allowance for that token and that spender on that network to zero, so the spender can't use it from then on. Your tokens stay where they are, transfers that already happened aren't reversed, and the revocation itself usually costs a network fee.
Do unlimited token approvals expire automatically?
No. An ordinary ERC-20 allowance has no expiry date. It stays valid until it is used up or changed, and an unlimited one is never realistically used up, so it remains usable until it is replaced or revoked. Other kinds of authorization can follow different rules.