Token approval checker for six chains
Data: your browser talks directly to public chain nodes. Your browser asks each chain's public node about the address you typed, batching every question into one request per chain through the Multicall3 contract. The reading happens between you and the node - the address never reaches us, so we cannot see whose wallet you looked at.
Every time you traded on-chain, you signed a permission that outlived the trade: a contract that may still move that token out of your wallet, usually with no limit and no expiry.
An approval is a standing permission, not a receipt
Paste a public address and this page reads those permissions back to you, on six chains at once, without connecting a wallet. Moving a token through any on-chain contract takes two steps: first you approve the contract to spend that token, then it spends. The second step ends; the first one does not. Most interfaces ask for the largest number the token can hold, because that means never asking again - which is convenient right up until the contract is drained by someone else, and every wallet that ever approved it is drained with it.
- The permission survives the trade, the interface and the year.
- It is per token and per contract, so one wallet can hold dozens.
- It moves tokens only - your native coin is never at risk from one.
What this page checks, and what it cannot
It asks each chain about a fixed list of the contracts people actually approve, above all Permit2, which modern trading interfaces approve once per token and then reuse forever. That is a list, not a history. Reading every approval an address has ever granted means replaying every event the chain ever emitted, which is an archive node's job and not something a browser tab can honestly claim to have done. So a clean result here means "none of the ones we looked at" - it is a useful answer, and it is not a certificate.
- Six chains, in one pass, from your own browser.
- A contract that did not answer is reported as unread, never as clean.
- The date the list itself was last verified on-chain is printed on the page.
Removing one is a transaction, and it is yours to sign
Setting an allowance back to zero costs gas, because it is an ordinary transaction on the token contract. It has to be signed by the wallet that granted the permission, which is exactly why this page does not offer to do it: we would have to ask you to connect a wallet, and nothing in this cluster asks you for a key or for a signature. Each row links to the contract in a block explorer, and every serious wallet now has an approvals screen of its own.
The habit that makes this page boring
Approve what a trade actually needs rather than an unlimited amount, and keep the wallet you experiment with separate from the one that holds anything. Both cost a little convenience and remove most of the tail risk: an unlimited approval on an empty wallet is worth nothing to anybody.
Questions
- Do I have to connect my wallet?
- No, and there is nothing here to connect it to. An address is public information, so reading its approvals needs only the address itself. The page never asks for a key, a seed phrase or a signature.
- It says no approvals. Am I safe?
- It means none of the contracts on our list can spend those tokens. It is not a statement about every approval the address has ever granted - that would need an archive node rather than a browser. Read it as a clean result on a specific, published list.
- What does "unlimited" actually mean?
- The largest number the token contract can hold, which in practice is every token of that kind you will ever own in that wallet, now and in the future. Several wallets write their own variant of it, and all of them are shown here as unlimited rather than as an enormous number.
- Why does it check six chains and not all of them?
- Because each chain on the list was verified by hand: every token and contract address on it was read on-chain, not copied from another list. Guessing wrong there would show a permission that does not exist, or miss one that does.