Wallet approval review and revoke guide: how to check, how to revoke, and clear out old approvals

What an approval actually is: approve and allowance

Let's pin the terms down first so the rest stays clear. The tokens you use on chains like Ethereum and BNB Chain (USDT, USDC and so on) mostly follow one shared standard, and that standard has an action called approve. It means: you permit a smart contract to use a certain token in your wallet, up to a certain limit, without you having to sign each time.

That permitted amount is called the allowance. A down-to-earth analogy: you set up an account at a shop, and from then on the shop can charge you within "a cap you set" without you swiping and entering a PIN each time. The allowance is that cap, and the approve is the moment you signed up for the account.

Why does this design exist? Because decentralised trading, lending and staking need the contract to "use your tokens on your behalf" to work. If every single swap required you to sign an approval afresh, the experience would be miserable. So the protocol's approach is: you approve once, and afterward the contract uses it repeatedly within the limit. Functionally that's fine — the trouble is "who" the approval went to, "how much" it was for, and that you "forgot it's still there".

An approval is a protocol-layer fact, not the design choice of any one app. For a lower-level, neutral explanation, see ethereum.org's explanation of token standards and its security page.

An approval is not a transfer

This is the misunderstanding most people get stuck on, and the one scams exploit most, so it gets its own section. Plenty of people think "I didn't press transfer and my balance didn't drop, so I'm fine", but approve and transfer are two entirely different on-chain actions, and confusing them makes you relax at exactly the moment you should be alert.

A transfer is you sending a token from your own address to another address. It moves the balance immediately — the number of that token in your wallet drops on the spot, and the transaction record clearly logs "how much sent out, to where". This is the "spending money" everyone intuitively understands.

An approve is nothing like that. It moves no tokens, your balance doesn't drop by a cent, it merely records a rule on-chain: a certain contract address may, from now on, use this token of yours within a certain limit. The instant you sign the approval, your assets are untouched, so you'll see "nothing was deducted, the balance is unchanged" — and that's precisely where it's dangerous. The power to use the funds has already been handed out, it just hasn't been used yet.

Put the two side by side and it's clear: a transfer is "I pay you a sum now", and it ends when paid; an approval is "I authorise you to come and deduct at any time later", and that rule keeps hanging there until it's used or revoked. So the risk an approval brings has nothing to do with whether anything was "deducted at the time" — you see no deduction at all, yet you may be drained, all at once and within the limit, at some point you've long forgotten. The exact gap a scam page loves to use: it gets you to sign an approval, shows "claimed successfully, no fee", you assume nothing happened, but the key has already been handed over.

So judging whether an action is safe is never about "how much did this deduct from me", it's about "what power did I just sign away". If the pop-up shows an approve / authorise type action, against a contract you don't recognise, with an unlimited amount, then even if it deducted not a cent, you should stop.

Why one old approval can carry your money off

The key is that an approval stays "continuously valid". After you approve, that approval doesn't expire on its own, unless you actively revoke it (set the allowance back to zero) or the contract itself is designed to reset to zero after use (most ordinary approvals are not). In other words, an approval you signed half a year ago to claim an airdrop, play a small game, or use a DApp you'd never heard of, is very likely still sitting on-chain today, quietly waiting to be used.

The truly dangerous scenario goes like this: you connect to a page that looks like "claim airdrop", "verify eligibility" or "unlock rewards", it pops up an approval window, and you hit confirm without reading. Nothing happens at the time — no deduction, no prompt, the page even says "claimed successfully". But you've actually handed the right to use a token over to a contract the other side controls. They're in no hurry to act; they wait until that token accumulates to a certain amount in your wallet, or until you've more or less forgotten, and then move the balance within the limit all at once.

This is why so many victims insist "I never gave my seed phrase to anyone" yet were still drained — because this path doesn't use the seed phrase at all. It runs on the approval you "signed yourself", technically completely legal and fully valid on-chain. It's also the most insidious part of fake airdrops and malicious approvals.

What's wrong with an unlimited approval

Many DApps, when requesting an approval, default not to "just enough for this time" but to an astronomical number — large enough to be effectively "unlimited". Why do it? Because it's convenient for the DApp: approve once and you never have to sign again, for a smooth experience. It sounds considerate, but the cost falls entirely on you.

The problem with an unlimited approval is direct: it removes the cap. If this contract is an upstanding project — no bugs, not hacked — then at most it "could use a lot of your money but won't". But the moment any one of those premises collapses — the contract has a backdoor, the private key is stolen, the team runs off, or what you approved in the first place was a phishing contract — then the entire balance of that token in your wallet is within its reach to use at any time. Setting the allowance to unlimited turns "the worst-case loss" from "the amount that should have been used this time" into "everything you own".

Some wallets and DApps now let you change the approval amount at signing time, swapping unlimited for a number that's just enough. Change it whenever you can — it won't make you earn less, it'll only make you lose less in the worst case. When you can't change it but must use it, remember to come back and revoke it once you're done.

How to check what approvals your wallet has

Approvals are all recorded on-chain and publicly viewable; you need no one's permission to see your own. There are mainly two routes to check, and using them together is steadiest.

Route one: a block explorer

Every chain has its own block explorer: Ethereum has Etherscan, BNB Chain has BscScan, and so on. Paste your wallet address in, and these explorers usually have a dedicated feature for viewing "token approvals" (a common name is Token Approvals or similar). Open it and you'll see a list: which tokens you've approved, which contract address each was approved to, and the current amount.

When looking, watch three things: one, whether you recognise the "contract address" — ones you don't, or that map to a site you long forgot, are the most suspect; two, whether the "amount" is unlimited (shown as an enormous number, or marked Unlimited); three, whether the token this approval covers actually has a balance in your wallet — a balance present, plus unlimited approval, plus an unfamiliar contract, those three together are the ones to handle first.

Route two: an approval check / revoke tool

A block explorer alone leans engineer-ish and isn't always easy to read. There are third-party tools that make "check approvals" more intuitive: connect your wallet and they list all your approvals as cards, marking the contract, amount and risk clearly, with a button to revoke directly. One of the best known is revoke.cash. To stress: these tools are not official, and not endorsed by this site — they save effort, but you must assess for yourself whether to trust them. The next section is dedicated to how to think about this kind of tool.

How to revoke: the concept of the steps

This section covers EVM chains first (Ethereum, BNB Chain, and most chains compatible with them); they share one approval model, so the logic is the same. TRON, Solana and others outside this family have a different approval concept and get their own section next.

On EVM, revoking an approval at heart means sending a new transaction that sets a contract's allowance for a token back to zero. Interfaces vary wildly and button names differ between apps, but what they do underneath is identical. Below the whole flow is broken out as concept only, not hard-coded to which menu's nth button — those change at any time, so memorising paths is useless; memorise the principle and the interface won't fool you.

1. Connect the wallet, and first confirm it's the right wallet and address. Whether you pair a block explorer with your wallet or use a third-party revoke tool, the first step is to connect the wallet. Once connected, don't rush to act — first check that the currently connected address is the one you mean to clean up, because a revoke can only revoke approvals "this address issued itself", and connect the wrong account and you won't find the one you want. At the same time, see clearly which chain you're on: the same address has separate approvals on Ethereum and on BNB Chain, so to revoke on one chain, switch your wallet to that chain.
2. Find the allowance for "that token to that contract". An approval isn't one lumped record; it's recorded set by set, "a token × a contract". From the list you found earlier, locate the set you mean to handle: which token, approved to which contract address, current amount. Lock onto the ones that are "unfamiliar contract + unlimited amount + the token has a balance" first. Ones you recognise, trust and still use (for example a DEX you use daily) can stay; you don't have to clear everything.
3. Send a transaction that sets the amount to zero. When you trigger the revoke, whether the button says Revoke, Remove or something else, what it does is call approve once more on that token contract, changing the amount given to that contract from its original number to 0. In other words, a revoke is itself an approve, just with the amount set to zero — that's the only difference from "a new approval", and the point you'll be checking shortly.
4. Check in the wallet pop-up before signing. This step matters most: after you press revoke, your own wallet pops up a transaction confirmation window, and that window is the final gate, not whatever the tool's web page says. Check three things — is the transaction going to the contract of "the token you mean to revoke"; is the party being authorised the contract you mean to revoke; and is the amount set to 0 (or shown as revoke / cancel approval). Confirm it really is "set the amount to zero", not another approval handing out new power and certainly not a transfer, then hit confirm. If you don't understand it, or the contract shown doesn't match the one you mean to revoke, stop.
5. Pay gas, wait for it on-chain, refresh to confirm. A revoke is a transaction written to the chain and costs that chain's fee (gas), paid in the chain's native coin (ETH on Ethereum, BNB on BNB Chain), so before acting confirm that address has a little native coin to pay the fee, or the transaction can't be sent. After sending, wait for it to be packed and confirmed — an Ethereum block is roughly a dozen-odd seconds, BNB Chain a few seconds faster, longer when the network is busy. Once confirmed, return to the list and refresh, and that amount should be zero or gone from the list. If it hasn't gone, it's either not on-chain yet or the transaction failed, so re-check the transaction status.

A few reminders: a revoke costs gas, so there's no need to revoke every single one — just clear out the genuinely suspect, unused ones. When revoking several, remember each is an independent transaction with its own gas, and each needs its own check in the pop-up, so don't go numb and sign blindly just because you're doing several in a row. And a revoke only switches off "whether it can be used again in future" — if money within the allowance was already moved before you revoked, the revoke can't bring that part back; it guards "afterward". So check and revoke early and regularly, not after something goes wrong.

Non-EVM chains (TRON, Solana, etc.)

Everything above is about EVM chains. But your assets aren't necessarily all on Ethereum or BNB Chain — many people hold USDT on TRON, or are active in the Solana ecosystem, neither of which is in the EVM family. These chains have the concept of "approval" too, but the model isn't quite the same, and the entry points and tools for revoking differ. The principle is consistent; the method must change.

TRON: tokens on TRON (most commonly TRC-20 USDT) also have the approve action, with logic close to EVM — you approve a contract to use your token within a limit, it can likewise be set to unlimited, and it likewise stays hanging. The difference is that it's TRON's own chain, so checking and revoking need a TRON-supporting block explorer and tools, and a TRON-supporting wallet to sign. You can't take the entry point you use for Ethereum approvals and apply it directly; the address format, the explorer, and the signing wallet are not the same set.

Solana: Solana's model differs more. Its common form is a token's delegate / approve concept — you delegate part of the spending power of a token account to another address. The expression differs from EVM's allowance, and the entry points for checking and revoking (cancelling the delegation) differ too, needing Solana's own ecosystem tools and wallet. The EVM routine of "find the allowance, set the amount to zero" doesn't map directly onto Solana.

How chains differ, where the entry points are, what tools to use — these shift with the ecosystems, so this page doesn't hard-code them. The one principle to remember: whatever the chain, you should regularly check your approvals / delegations and revoke the unfamiliar, unused ones; but don't carry one chain's operating steps straight over to another. First work out which chain your assets are on, and how that chain's approvals are checked and revoked, then act. Be especially careful not to assume across chains.

How to think about third-party revoke tools

Tools like revoke.cash really are convenient: they organise scattered approvals into a clear list, sparing you the digging in a block explorer. But before using one, keep a few things in mind.

• It's not official, and not endorsed by this site. It's a third-party service; whether and how far to trust it is your own judgement, not something anyone vouches for on your behalf.
• The check-approvals part is low-risk, because it's read-only. Connecting your wallet so it can read your approval list doesn't require you to sign a transaction that touches assets, so it's relatively safe.
• The part that truly needs a signature is the revoke — look before you sign. Whichever tool you revoke through, the transaction finally sent appears in your own wallet's pop-up. That pop-up is your last gate — what it shows and which contract it goes to is governed by your wallet, not just what the tool's web page says.
• Confirm the URL yourself. Well-known tools often have people building phishing copies. To use one, go in via a URL confirmed from a reliable source, don't click links of unknown origin; for ways to compare a URL, see the golden rule of logging in from a bookmark, and you can also drop a suspicious link into the look-alike domain checker for a character-by-character read.

In the end, a tool just reformats on-chain data into something more readable; the decision and the final signature are still in your hands. Treat it as a magnifying glass, not a safe.

The account-security check to run after revoking

Revoking suspect approvals only closes one hole — "whether this address can be used again by those contracts in future". It doesn't answer a more critical question: how did the other side get you to sign that approval in the first place? If you simply got careless for a moment, clicked a phishing link and signed a bad approval, revoking is more or less enough. But if you suspect something deeper — say you once entered a seed phrase or private key on a suspicious page, screenshotted it to the cloud, or installed a wallet app of unknown origin — then revoking approvals is nowhere near enough.

The dividing line is this sentence: revoking only guards the "via an approval" path; it can't stop the "the other side has your seed phrase / private key" path. As long as there's any risk the private key or seed phrase has leaked, the other side doesn't need an approval at all — they can directly move anything as you, and no amount of revoking helps. So after revoking, run through the following in order:

• Judge whether the private key / seed phrase is at risk of leaking. Think back over this wallet's seed phrase and private key — have they been entered on any web page, sent to anyone, stored in a phone photo album or cloud note, or is the wallet app you installed itself of unknown origin? If any one applies, treat it as possibly leaked and don't bet on luck. How to spot a fake wallet is in fake wallets and the seed-phrase trap.
• If you suspect a leak, move assets to a brand-new wallet. In that case the old wallet is as good as scrapped; it's not something a few revokes can save. In a clean environment, create a brand-new wallet whose seed phrase has never leaked, and move whatever can still be salvaged from the old wallet across. Write the new seed phrase down offline only — no screenshots, no cloud, no sending it to anyone. How to set a wallet up safely from scratch is in the beginner wallet security setup.
• While you're at it, harden the related exchange account. The same batch of scams often doesn't only target your on-chain wallet. Take the chance to reset the exchange account's 2FA, or switch it to a stronger method (use an authenticator app, not SMS alone), check for unrecognised login devices and the withdrawal whitelist, and change your login habit to going in from a bookmark, not clicking search ads. How to guard the entry point is in the golden rule of logging in from a bookmark.
• If a loss has already happened, stop the bleeding and keep evidence first. If it's not prevention but money has already been moved, don't rush to act all over the place; follow the order in the first 4 things to do after a scam: save what hasn't been carried off, keep records like the transaction hash and time, then decide the next step.

To close in a line: a revoke is locking the door back up, and the security check is making sure the thief doesn't still hold another key. Doing the first without the second is locking the front door without knowing the back-door key was copied long ago.

Approval leak vs seed-phrase leak

These two get lumped together, but they differ greatly in severity, and the handling differs too. Tell them apart and you'll know what to do when something goes wrong.

• Approval leak: some approval you signed falls into bad hands, and all they can use is limited to "the token you approved, within that amount". In other words, the loss has a boundary. The handling is clear too — revoke that approval and the hole is plugged, and this wallet can still be used.
• Seed-phrase leak: the seed phrase (or private key) is the wallet's top-level authority, the whole key. Once leaked, what the other side can move isn't one token but everything in this wallet, and revoking approvals can't stop it at all, because they don't need an approval — they can directly move anything as you. In that case revoking is useless, and the only way is to immediately move whatever can still be salvaged to a brand-new wallet whose seed phrase has never leaked, treating the old wallet as scrapped.

So the two lines of defence are on entirely different tiers: an approval is "the key to a particular door", just revoke it; a seed phrase is "the master key to the whole house", and a leak means you can only move out. Exactly for this reason, any page asking you to enter your seed phrase — however it's dressed up as "check approvals", "sync" or "verify security" — is a directly fatal scam, a different thing entirely from a normal operation like revoking an approval. For the seed-phrase trap, see the fake-wallet entry. If something has already gone wrong, what to do first is in the first 4 things to do after a scam.

Common mistakes and risk reminders

Revoking approvals is itself a normal, safe operation, but "going to revoke approvals" has, ironically, been turned into a fair few scam setups. The pitfalls below are common; read through them once and you can sidestep them when you act.

• Mistaking a fake "revoke" page for the real thing and signing a phishing approval instead. This is the most ironic kind: worried about approval safety, you search "revoke approval" and click in, and it's a phishing copy. It doesn't revoke for you; instead it pops an approval window, or even asks you to enter your seed phrase, and in the mindset of "I'm doing a safety operation" you sign. Remember: confirm a revoke tool's URL from a reliable source before going in, and put suspicious links into the look-alike domain checker for a character-by-character comparison; and a real revoke only ever asks you to sign "set the amount to zero", never to enter your seed phrase.
• Using an "automatic batch clean-up" tool of unknown origin. Some tools tout sweeping away all your approvals in one batch, sorted with a single press, which sounds easy. But every transaction you finally sign is still a real transaction sent through your wallet — if the tool is malicious, what it feeds into your pop-up may not be a revoke at all, but a handover of power to it. Don't let the convenience of "batch, automatic" go to your head; check every one in your own wallet's pop-up before sending, and don't sign what you don't understand.
• Not having enough gas at revoke time, so the transaction stalls or fails. A revoke costs the chain's native coin as a fee. A common situation: the address holds piles of some token but not a scrap of native coin, so the revoke transaction can't be sent at all, or fails when gas is insufficient on a busy network. Before acting, confirm the chain's native coin (ETH on Ethereum, BNB on BNB Chain) has a little balance to pay. If a transaction shows pending for a long time, it's usually gas set too low — don't keep mashing the button, check the transaction status first.
• Accidentally revoking an approval you use daily. Clearing the whole list in one go, you also revoke the approval for the DEX or lending protocol you use often, and next time you use it you have to approve again and pay gas again. Before revoking, sort it out: unfamiliar, unlimited, unused first; recognised, trusted, still in use can stay. Revoking isn't "the cleaner the better", it's closing the holes that should be closed.
• Thinking everything's safe after clearing one chain. The same address has separate approvals on different chains; clear Ethereum and your approvals on BNB Chain, TRON and Solana are still untouched. People with assets spread across several chains have to go through them one by one, not knock off after one chain.
• Only revoking approvals without checking whether the private key has leaked. As the earlier section said: if there's any risk the seed phrase or private key has leaked, revoking can't stop it, and you have to take the move-to-a-new-wallet route. Mistaking "revoke" for a cure-all is the most dangerous complacency.

Building the habit of regular checks

An approval stays put as long as you don't check it. Rather than wait for trouble, make checking a fixed routine. A few practical approaches:

• Look back on a fixed cycle. No need to check daily, but every so often (set yourself a month or a quarter), pull out the wallet's approval list and sweep through it — revoke the unfamiliar, unlimited, unused.
• The habit of revoking once you're done. An approval given for a one-off operation (claiming something, trying a new DApp) — revoke it right after the thing is done, don't let it linger until you forget.
• Limit the amount rather than going unlimited. When signing an approval, change the amount to just enough if you can; what you save is the worst-case loss.
• Keep large holdings separate from your daily operating wallet. Put long-term holdings in a "cold" address that almost never connects to any DApp, and use a separate "hot" address holding only small amounts for everyday DApps and airdrops. Even if the hot wallet's approvals go wrong, the principal isn't touched.
• Never connect to or sign anything of unknown origin. The easiest defence is to never sign those suspect approvals in the first place. Not connecting your wallet to a suspicious airdrop link is the lowest-cost self-protection there is.

Turn these few into habits and it beats however many revoke techniques you learn — because most of the risk is already blocked at the moment you "didn't go connecting and signing recklessly".

FAQ

Will revoking an approval move or deduct my money?

No. Revoking sets a contract's spending allowance back to zero; it doesn't move any of your tokens. The only cost is the transaction's gas (on-chain fee). If a page claiming to "revoke" asks you to approve something new or to transfer during the process, that isn't a revoke — stop.

I revoked the approval — can I recover money taken under it earlier?

No. Revoking only closes off "future" use; if assets within the allowance were already moved before you revoked, revoking can't bring that part back. That's exactly why you check regularly and revoke early, rather than waiting until something goes wrong.

Checking approvals needs a wallet connection — is there a risk?

Simply reading the approval list is a read-only action; it doesn't require you to sign a transaction that touches assets, so the risk is low. What to watch for is a page that "wants you to sign to unlock just to check" — checking approvals needs no such signature. The only step that costs gas and needs a signature is the revoke.

I never gave my seed phrase to anyone — why did the money still vanish?

It was very likely an old approval being used. That path doesn't go through the seed phrase; it runs on an approval you signed yourself in the past, technically completely valid. Check your wallet's approval list and you'll usually find that unfamiliar unlimited approval.