Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


To revoke a crypto token approval safely, identify the exact blockchain, wallet account, token contract, and spender contract; read the current allowance through a trusted interface or explorer; submit an approval of zero or the network's supported revoke action; then wait for confirmation and read the allowance again. Disconnecting a dapp does not normally cancel an on-chain allowance.
Key Takeaways
- A token approval authorizes a spender contract; it is different from a wallet-site connection.
- Verify chain, account, token contract, spender, current allowance, and transaction data before signing.
- Revocation usually requires an on-chain transaction and network gas.
- Confirmation is not enough: read the final allowance and confirm the revoke transaction reduced it to zero.
- Revoking cannot restore assets already transferred or secure a wallet whose keys are exposed.
The ERC-20 standard defines allowance as the amount an owner permits a spender to withdraw, and approve as the method that sets that allowance.[1] A decentralized exchange router, bridge, lending market, subscription contract, or malicious contract may request this authority so it can call transferFrom later.
An allowance belongs to a specific tuple: blockchain, token contract, owner address, and spender address. The same names or symbols on another network do not refer to the same permission. Native coins generally do not use ERC-20 allowance, although wrapped versions and account-abstraction systems may introduce different permissions.
| Item | What to verify | Why it matters |
|---|---|---|
| Network | Exact chain and chain ID | Permissions do not carry automatically across chains |
| Owner | Wallet account granting authority | A connected wallet may expose several accounts |
| Token | Contract address, not symbol alone | Fake tokens can reuse names and symbols |
| Spender | Contract address and documented role | The website brand is not the spender identity |
| Allowance | Current raw and human-readable amount | “Unlimited” may be a very large integer |
| Transaction | Method, target, fee, and final effect | A fake revoke can grant a new permission instead |
A wallet connection usually lets a site see an address and request signatures. Disconnecting removes or forgets that session permission in the wallet interface. It does not rewrite the token contract's stored allowance. MetaMask explicitly distinguishes disconnecting an account from revoking a smart-contract allowance.[3]
Closing a browser tab, clearing cookies, deleting an app, or changing RPC providers also does not cancel a confirmed approval. Conversely, revoking an allowance does not necessarily disconnect the site, cancel off-chain orders, terminate a protocol position, or remove permissions implemented by another contract standard.
Use the protocol's documentation to understand consequences before revoking. Some active positions require a spender for deposits, repayments, automated strategies, or recurring operations. Revocation may make a feature fail, but it should not by itself transfer assets to the protocol.
Open a known block explorer or the wallet's documented approval manager from a typed or bookmarked official domain. Do not click a sponsored “revoke” result, a link in an unsolicited alert, or a direct message claiming an urgent approval emergency. Fake revocation sites are designed to obtain a more dangerous signature.
Select the exact network and owner address. Compare the address with the wallet's trusted display or account details. If the tool supports several approval types, separate fungible-token allowances from NFT operator approvals and protocol-specific permissions. This guide addresses ERC-20-style token allowances.
Create an inventory before signing anything:
If you cannot explain an approval, that supports revoking it, but it does not justify signing an opaque transaction.
For an ERC-20 token, the relevant read is allowance(owner, spender). The result is public and does not require a wallet signature. You can compare the approval manager's result with the token contract on a reputable explorer or through a second trusted RPC interface.
Check decimals when translating the raw integer into token units. An interface may call a maximum integer “unlimited.” Also verify that the contract is the genuine token: a scam airdrop can show the same symbol while pointing to unrelated code.
If the allowance is already zero, no ERC-20 revocation is needed for that tuple. Investigate whether the warning instead concerns another chain, another spender, an NFT approval-for-all, a permit signature that has not yet been used, or compromised keys.
Ethereum.org's guidance describes revocation as an on-chain transaction that cancels token access.[2] A common ERC-20 operation calls approve on the token contract with the spender address and an amount of zero. If you later need a smaller nonzero cap, follow the token and tool's documented flow: the ERC-20 standard warns clients to set an existing allowance to zero before setting another nonzero value for the same spender.[1] Confirm the zero transaction before approving the new cap. Token implementations can behave differently, so use a reputable tool and inspect the simulation or decoded method.
Before signing, confirm:
Reject blind signing when the wallet cannot decode an unexpected request. Do not approve a “security contract” merely because a website says it is required to revoke another contract.
Sign the verified transaction and record its hash. A pending transaction has not changed the allowance yet. Wait for the network's appropriate confirmation depth, then check whether it succeeded rather than reverted or was replaced.
Read allowance(owner, spender) again from the token contract. Revocation is complete only when the final value is zero. If you deliberately approve a lower cap afterward, read the allowance again after that separate transaction. Refreshing a website badge is weaker evidence than the on-chain read.
| Result | Meaning | Next action |
|---|---|---|
| Confirmed and allowance is zero | Revocation completed | Record result and remove obsolete connection if desired |
| Confirmed but allowance unchanged | Wrong tuple, failed semantics, or unusual token | Stop and inspect transaction and contract |
| Pending or dropped | No reliable final change | Check nonce, fees, and replacement status |
| Allowance returns after a later action | Another approval was signed | Review new transaction and protocol workflow |
| Assets already missing | Revocation is not recovery | Preserve evidence and treat as an incident |
Repeat the process for each network, token, and spender that needs review. One revocation does not cover copies on other chains.
If a seed phrase, private key, or signing device is exposed, an attacker can sign transfers or create new approvals. Move remaining assets to a wallet controlled by fresh secrets using a carefully verified plan. The self-custody guide explains the control boundary, while the crypto hacks guide covers evidence and containment.
If assets were already transferred, revocation cannot pull them back. If an unlimited approval exists but no theft has occurred, prompt revocation can reduce future exposure, subject to transaction ordering and network conditions. Do not advertise your incident in public replies where impersonators can target you.
Unknown dust or scam tokens create a different problem. Do not visit a URL embedded in a token name and do not approve a contract merely to hide or sell it. See the crypto dusting guide. Install wallet software only from verified sources; the fake apps guide explains common delivery traps, and the broader online security guide provides a general risk checklist.
Safe revocation is a state-verification task. Establish the correct chain, owner, token, spender, and allowance; use a trusted interface to construct the zero-allowance transaction; inspect the decoded call; and verify the final on-chain value after confirmation. Disconnecting a site is separate, and revocation is only one containment step when secrets or assets are already compromised.
Usually yes, because changing an ERC-20 allowance is an on-chain transaction. The fee is paid in the network's native asset.
No. Disconnecting normally removes a site's local connection but leaves existing on-chain allowances unchanged.
Review whether each spender is trusted and still needed. Reducing unused authority limits exposure, but revocation can interrupt active protocol functions and costs gas.
A genuine zero-allowance call should not transfer tokens, but a fake site can ask you to sign a different call. Verify the decoded target, method, spender, and value.
You may be viewing another chain, owner, token, or spender; the transaction may have failed; or the interface may be stale. Read the contract state independently.
No. It can restrict later transferFrom calls, but it cannot reverse earlier transfers.
Create a fresh wallet on trusted equipment and plan a migration. An attacker with the key can create new approvals after you revoke old ones.
Advanced users can construct the token-contract transaction directly, but mistakes are possible. A reputable wallet or explorer interface can make the tuple and call easier to inspect.
Disclaimer: This article provides general security information, not legal, financial, investment, smart-contract, or recovery advice.
Sources checked 8 September 2026.
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.





