Token Approvals: What You Permit and How to Revoke It

Two actions hide behind one swap

ERC-20 is a common standard for interchangeable tokens on Ethereum and compatible networks. Its allowance is the amount an owner has authorised a particular spender to use. The token contract records that permission; the spender is the address allowed to act on it, often an application's smart contract rather than the website you see.

In the ordinary approval-and-transfer flow, approving changes the allowance, while a later transferFrom operation moves tokens under that authority. A successful approval therefore does not prove that a swap or deposit completed. Check the application's subsequent transaction and your resulting balances separately.

What remains after spending 50 tokens?

Imagine a hypothetical wallet holding 800 units of a token, with no fees or unusual token behaviour. You want an application to spend 50 units once. Under a conventional allowance that decreases when spent, approving 50 and then spending 50 leaves a balance of 750 and an allowance of zero. Approving 800 for the same action instead leaves 750 tokens and permission to spend another 750.

This is a token-quantity limit, not a daily budget or a price guarantee. An ordinary ERC-20 approval does not include an expiry date. An effectively unlimited allowance can also cover tokens received later, so an empty balance today does not make a forgotten approval harmless. Token implementations and additional permission systems can behave differently; inspect the actual remaining allowance rather than assuming the example always applies.

Broad approvals can reduce repeated approval transactions and their network costs. The uncomfortable trade-off is that saving a few confirmation steps can leave a much longer relationship with a contract than the reader intended. Our editorial judgment is to match the permission to the intended use and review any convenience-driven excess, not to treat every unlimited request as proof of a scam.

🔎 Read the authority, not just the button

Before confirming, compare four fields: the selected network, the exact token contract, the spender address and the amount. A familiar token symbol or application logo does not establish those identities. Use an independently reached official application reference to check the spender; if you cannot explain why that address needs the permission, pause rather than approve to get past the screen.

For a one-off operation, a limited allowance can reduce what the spender is authorised to take if it is malicious or later compromised. It does not make the approved amount safe or guarantee a fair swap. Review the proposed trade, minimum output and other transaction conditions separately; permission size and trade quality answer different questions.

A signature can matter without an immediate gas bill

A signature request without an immediate gas charge is not automatically a harmless login. ERC-2612, an extension to ERC-20, allows a signed permit message to set an allowance when submitted on-chain. Read its spender, value, network and token context, and deadline. That deadline limits when the permit can be submitted; it does not by itself make the resulting ordinary allowance expire.

Remove the permission—and verify the result

Begin a permission review with the correct wallet address and network. A reputable approval checker or supported wallet interface can display the tokens and spenders involved. Reach it through an independently verified route, not an unsolicited recovery message or search advertisement. Do not enter a recovery phrase or private key to inspect or revoke an allowance.

For an ordinary ERC-20 allowance, revocation sets the selected spender's allowance for that token to zero. This changes blockchain state, so a conventional revocation transaction requires network fees. Read the confirmation: it should concern the intended token and spender and a zero allowance, not a new broad permission. Fees and supported networks vary; this article does not quote a current gas price.

Wait for successful confirmation and check the remaining allowance again. A pending request is not completed protection, and revocation cannot undo tokens already transferred. If you later use the application again, it may ask for a new approval. Removing one spender's permission also leaves other spenders and other networks unchanged.

When revocation is not enough

Approval cleanup is not a repair for an exposed recovery phrase or private key. Someone controlling that secret can authorise new actions, so removing one allowance does not restore exclusive control. If funds disappear whenever gas is added, stop repeatedly funding the address and consult the wallet provider's verified compromise guidance; automated theft may be involved.

Close one old permission deliberately

Start with one application you no longer use. Record its network, token, spender and current allowance, then decide whether any continuing permission is justified. If you revoke it, keep the transaction confirmation and verify the new allowance. The useful outcome is a permission you can account for, not merely a tidier list of connected websites.