Token Approval Checker: Find & Revoke Risky Allowances

A token approval checker answers a question every crypto user should be asking more often: which smart contracts can move my tokens right now, without asking me again? Every DeFi swap, bridge deposit, and marketplace listing you have ever signed likely left behind a standing permission — and those permissions do not expire. Noxos Intelligence audits them with its Revisor engine, which enumerates every active ERC-20 allowance an address has granted across 14 EVM chains, flags unlimited grants, and ranks spenders by the USD value actually at risk.

This guide covers the full picture: what an approval is at the contract level, why "approval checker" and "allowance checker" name the same tool, how to audit your own wallet in about two minutes, how revocation works — and what it cannot undo — and the signature-based grants that never show up in on-chain allowance state at all.

What Is a Token Approval? approve(), allowance(), and setApprovalForAll

ERC-20 tokens do not let a contract simply take your funds. Dapps use a two-step pattern instead: first you call approve(spender, amount) on the token contract, granting the spender permission to move up to that amount of your tokens; later, the spender calls transferFrom to pull tokens within the limit. The granted amount is stored inside the token contract itself, and anyone can read it back:

approve(spender, amount)       // you grant permission
allowance(owner, spender)      // anyone can read what's granted
transferFrom(owner, to, amt)   // the spender pulls tokens, up to the allowance

Three properties make this pattern dangerous in practice. First, the allowance lives in the token contract's storage — it survives even if the dapp's website disappears, the team walks away, or the protocol is exploited. Second, most dapps historically requested unlimited approvals (the maximum 256-bit integer, MaxUint256) so users would not pay gas to re-approve before every trade. An unlimited grant means the spender can move your entire balance of that token — including tokens you acquire years later. Third, nothing on your side ever prompts you to review any of this.

NFTs have an even blunter version: setApprovalForAll(operator, true) hands an operator control over every NFT you hold in that collection, present and future. There is no partial version — it is all or nothing, which is exactly why wallet drainers love asking for it.

Approval or Allowance? Why a Token Allowance Checker Is the Same Tool

The terminology splits people looking for help. The ERC-20 standard calls the stored value an allowance — that is literally the function name, allowance(owner, spender). The act of granting it is an approval. Block explorers tend to say "token approvals"; many security tools brand themselves as a token allowance checker instead. Both are reading the same mapping in the same contracts.

So whether you searched for a token allowance checker, an approval checker, an approval scanner, or a revoke tool: same category, same on-chain data, same fix. Noxos itself uses both words — the consumer tool ships in the toolkit as the Allowance Checker, and Revisor is the engine underneath it. Whatever you call it, the job is identical: enumerate every token-spender-amount triple your address has granted, price the exposure in dollars, and hand you a revocation path.

How to Check Your Token Approvals in Two Minutes

Checking costs nothing and touches nothing. Reading allowance state is a read-only operation — you paste an address, you do not connect a wallet, and you sign nothing. That also means you can audit any address: your own, a relative's hardware wallet, or a team treasury.

1. Paste the address. Revisor sweeps every active ERC-20 allowance the address has granted across 14 EVM chains in a single pass — no switching networks, no per-token lookups.
2. Read the summary cards. Three headline numbers: total active approvals, total USD at risk, and the count of unlimited grants. If USD at risk is near zero, you are in good shape. If the unlimited count is not zero, keep reading.
3. Work the list worst-first. Results are ranked by USD at risk, so the top row is always your single largest exposure.
4. Inspect each row. For every approval you see the token, the spender contract (with a label when it is a known protocol), the granted amount, the dollar value currently exposed, an explicit unlimited flag, and when the grant was made — stale dates are a strong revoke signal.
5. Revoke through the deep link. Each row links into revoke.cash with your wallet and chain prefilled, so removal is a short guided step instead of a manual hunt.

The granted-at date deserves special mention. An unlimited stablecoin approval from 2023 to a contract you cannot name is not a hypothetical risk — it is an open door with your address on it.

How to Revoke a Token Approval — and What Revoking Can't Fix

A revocation is not a special operation. It is the same approve() call with the amount set to zero: approve(spender, 0). For NFT operators it is setApprovalForAll(operator, false). Once the transaction is mined, the spender's power over that token is gone.

Practical consequences follow directly from that:

• Each revocation is one on-chain transaction. You pay gas per approval, per chain. This is why prioritization matters — clearing twenty dust approvals can cost more than the exposure they represent.
• Revoking is fully reversible. If you use the dapp again next month, you simply approve again — ideally for a bounded amount this time.
• Revoking cannot claw anything back. If a spender already used its allowance to take funds, setting it to zero closes the door for the future but recovers nothing. What is gone requires tracing, not revoking — that is a case for investigators, and speed matters far more than most victims realize.

Also note what revocation does not cover: it clears the one on-chain allowance you target, and nothing else. Other chains, other tokens, and — as the next section explains — signatures you have already handed out are separate problems.

Invisible Allowances: Permit, Permit2, and Signature-Based Approvals

Here is the uncomfortable truth every honest allowance checker should tell you: a clean result does not mean zero exposure. Some grants never appear in on-chain allowance state until the moment they are used.

EIP-2612 permit lets you approve by signing an off-chain message instead of sending a transaction. Until someone submits that signature, no allowance exists on-chain — no checker anywhere can see it. Wallet drainers exploit exactly this window: a phishing site asks for a harmless-looking signature, then the attacker submits it later, creating and spending the allowance in a single transaction. By the time the state changes, the balance is already gone.

Permit2 adds a second layer. You grant the Permit2 contract itself a (typically unlimited) token-level approval once, and it then manages per-dapp sub-allowances in its own storage via signatures. A token-level checker will show you "approved to Permit2" — which is accurate — but the individual grants routed through it live in Permit2's own accounting, not in the token contract.

What to do with this knowledge:

• Treat any token-level approval to a permit-style router as high-sensitivity. If you do not actively use it, revoke it.
• Never sign messages you do not understand. Simulate transactions before signing, and be suspicious of any site that requests a signature when you expected a simple transfer.
• Run your checker again after any interaction that felt wrong. Drain-style permits become visible on-chain the moment they execute, and a fresh unlimited grant you never knowingly made is the smoking gun.

Approval Drains in the Wild

This risk class has a long public record. In December 2021, attackers compromised BadgerDAO's web front end and injected malicious approval prompts into the real site; users who signed granted an attacker-controlled spender, and roughly $120 million left their wallets. In April 2023, a bug in a newly deployed SushiSwap router contract (RouteProcessor2) let arbitrary callers spend tokens users had approved to it — about $3.3 million drained within days, from approvals granted in good faith.

And here is an illustrative composite — not a specific case, but the pattern that recurs in recovery casework. A user grants an unlimited stablecoin approval to a small yield farm in early 2024, exits the position that summer, and forgets it. The farm's admin keys are compromised eighteen months later. The attacker enumerates every address that ever approved the contract, and the user's wallet — holding a much larger balance by then — is emptied in a single transferFrom. No new signature, no phishing, no mistake made that day. The mistake was made in 2024 and left standing.

How drained funds move afterwards — through swaps, bridges, and mixers — is a story of its own; see our breakdown of a DeFi exploit from flash loan to cash-out. The takeaway for approval hygiene is simpler: every one of these losses passed through an allowance that a two-minute audit would have surfaced.

Token Approval Checker vs. revoke.cash vs. Block-Explorer Tools

Where does a dedicated token approval checker like Revisor sit against the tools you may already know? An honest comparison — we deep-link into revoke.cash on purpose:

Capability	Revisor (Noxos)	revoke.cash	Block-explorer tools
Chain coverage per lookup	14 EVM chains in one pass, one view	Broad chain support, viewed per selected network	The explorer's own chain only
Prioritization	Ranked worst-first by USD at risk, with summary totals	Sortable approval list	Raw list, minimal ranking
Unlimited grants	Explicitly flagged and counted	Visible in the amounts	Visible in the amounts
Spender identification	Labels from an investigation-grade address database	Community labels	Contract names where verified
Revocation	Deep-links into revoke.cash, prefilled	Native, with wallet connected	Native, with wallet connected

The short version: revoke.cash is an excellent revocation tool, which is exactly why Revisor hands off to it rather than reinventing the final step. What Revisor adds is the investigation layer in front — one aggregated 14-chain sweep instead of a per-network walk, worst-first USD ranking so you triage instead of scroll, and spender labels backed by the same address-labeling database our forensics platform uses to attribute wallets in real cases.

Which Approvals Should You Revoke First?

Gas per revocation means order matters. Work down this list:

1. Unlimited grants to spenders you cannot identify. If the spender is unlabeled and you do not remember the dapp, revoke immediately — and consider scanning the contract to understand what you were exposed to.
2. Any approval to an exploited, paused, or abandoned protocol. When a protocol you have touched appears in the exploit feed, checking your allowance to it is the first move — attackers race to spend inherited approvals.
3. Unlimited grants to legitimate protocols you no longer use. The protocol may be honest today; its admin keys, upgrade path, or front end may not be tomorrow. Re-approving later costs one transaction.
4. Stale bounded approvals with real USD at risk. Bounded beats unlimited, but a two-year-old 50,000 USDC allowance is still 50,000 USDC of exposure.
5. Bounded dust — leave it. A three-dollar allowance to a DEX router is not worth the gas to clear. Spend attention where the dollars are.

Revisor's worst-first ranking encodes most of this automatically: the unlimited flag plus USD at risk float the rows that matter to the top of the list.

Make Approval Audits Part of Your Routine

Approvals are one layer of a broader habit, not a one-off panic. Before granting a new one, check the dapp's domain against known phishing infrastructure, prefer bounded amounts whenever the interface offers them, and simulate anything unusual before you sign. Then fold a monthly Revisor sweep into your wider self-custody security practices — monthly as a baseline, immediately when a protocol you have used is exploited, and immediately after signing anything on an unfamiliar site.

FAQ: Token Approvals and Allowance Checkers

Is it safe to revoke all token approvals?

Yes. Revoking only removes a spender's permission to move your tokens in the future — it never touches balances, positions, or NFTs. The one side effect is convenience: the next time you use that dapp you must approve again and pay gas for the new grant, and automated features that rely on a standing allowance, such as open limit orders, may stop executing until you re-approve.

Does revoking a token approval cost gas?

Yes. A revocation is a normal on-chain transaction that sets the allowance for that spender to zero, so you pay the network fee once per approval, per chain. On most EVM chains the cost is small, but it adds up across many approvals — which is why worst-first ranking matters: spend gas clearing grants with real USD at risk, not harmless dust.

Do token approvals expire on their own?

No. An ERC-20 allowance persists until it is overwritten or spent down — the standard has no expiry mechanism. A bounded approval shrinks as the spender uses it; an unlimited approval effectively never does. That is why grants from years ago still work today, and why running a token allowance checker periodically matters more than any one-time cleanup.

Can an old token approval drain my wallet?

Yes — this is precisely the risk. An unlimited approval lets the spender contract move your entire balance of that token whenever it is triggered, and if that contract is later exploited or its admin keys are compromised, the attacker inherits the permission. The allowance covers your balance, not a snapshot, so tokens you acquired long after granting it are exposed too.

What is the difference between a token approval and a token allowance?

Nothing practical — they are two names for the same on-chain state. "Approval" describes the action of calling approve() on a token contract; "allowance" is the stored result that the allowance() function reports. A token approval checker and a token allowance checker therefore read exactly the same data; whichever term you searched, you are looking at the same category of tool.

How often should I check my token approvals?

Monthly is a sensible baseline for anyone active in DeFi, with an immediate extra check whenever a protocol you have used announces an exploit and after any signature on an unfamiliar site. A check is read-only, needs no wallet connection, and takes about two minutes across all 14 supported EVM chains — essentially free compared with the cost of one forgotten unlimited grant.

Audit Your Approvals Today

The approvals you forgot are the ones attackers count on. A two-minute, read-only audit closes doors before anyone walks through them. See Revisor and the rest of the Noxos workstation in the interactive demo, run an audit on your own address, and revoke worst-first. And if you are here because funds have already moved, do not stop at revocation — open a recovery case so investigators can trace where they went while the trail is still fresh.