Approving a contract is not a one-off payment. It writes an allowance into the token's own storage, and that allowance stays there — spendable at any time, without another signature from you — until it is used up or set back to zero. Most of them are set to unlimited because that is what apps ask for. Enter an address above to see which ones are still standing.

Where the list comes from:

Every Approval and ApprovalForAll event this address has emitted, collapsed so only the most recent grant per token and spender survives. A later approval of zero is a revocation and is not listed.

What is read live:

For every row on the page, allowance(owner, spender) is read from the token contract at one pinned block. A spender that has already used part of a finite allowance emits no event, so the granted figure alone would overstate the exposure.

What revoking does:

Sends approve(spender, 0) to the token, from your wallet, paying gas in USDC. Arcscan encodes the call and shows it to you; it never holds a key and never signs.

What this cannot tell you:

Whether a spender is trustworthy. An approval to an upgradeable proxy can mean something different tomorrow than it did when you granted it, and this page cannot see that — it can only tell you the permission exists.

What is a token approval, and why does it outlive the transaction that made it?

Approving a contract writes an allowance into the token's own storage: from that moment the spender can call transferFrom and move up to that many of your tokens, at any time, without another signature from you. It is not tied to the swap or deposit you were making — it stays there until it is spent down or explicitly set back to zero. That is why an approval you granted to an app you used once, months ago, is still a live permission today.

What does an unlimited approval actually mean?

Wallets and apps commonly request 2^256-1 — the largest number the type can hold — so you never have to approve again. It never runs down and it never expires. If that contract is compromised or was malicious to begin with, the ceiling on what it can take is your entire balance of that token, including tokens you buy afterwards.

Why does this list sometimes show less than the amount that was approved?

Because a transferFrom decrements an allowance silently — it emits a Transfer, never an Approval — so the event history alone can only tell you what was granted. The On-chain Now column reads allowance(owner, spender) straight from the token contract at a single pinned block, so it shows what is genuinely still spendable. Where the two differ, the on-chain figure is the one that matters.

Is an empty result proof that I have no approvals?

No, and the page says so rather than implying otherwise. Approvals are reconstructed from Approval events in the blocks Arcscan has indexed. An approval granted before the start of that range, and never touched since, emitted no event inside it and cannot appear here. The block range that was searched is printed under the table.

What does revoking cost, and does Arcscan handle my keys?

Revoking is a normal transaction — approve(spender, 0), or setApprovalForAll(operator, false) for an operator approval — sent to the token contract, and it costs gas in USDC like any other. Arcscan never holds a key, never signs, and never sends anything: it encodes the call, shows you exactly what it says, and your wallet is where you approve it. You can also copy the calldata and sign it somewhere else entirely.

Why is an operator approval listed with no amount?

Because setApprovalForAll has no amount. It authorises the operator to move every token you hold in that collection, including ones you have not acquired yet, until you withdraw it. Rendering that as a dash in an allowance column would make the widest permission on the page look like the narrowest.