NFT approvals are not the same as token approvals

You have read the advice about revoking token approvals, and you have run a revoke tool over your wallet. The list came back clean. Two weeks later a collection you had held for a year is gone, transferred out in a single transaction you did not sign that day.

The approval that moved it was still there. It was an NFT approval, and most people check the wrong list because ERC-20 and ERC-721 grant permission through different functions that do not appear in the same place.

What an NFT approval actually grants

An NFT approval is permission granted to another address to transfer non-fungible tokens you own, on your behalf, until you revoke it. That much sounds like a token allowance, and the resemblance is where the trouble starts.

An ERC-20 approval is bounded by an amount. You approve a contract to spend up to some number of tokens, and even an "unlimited" approval is at least confined to one token contract — approving a router for USDC does not touch your DAI.

An NFT approval has no amount, because the assets are not fungible. Instead there are two forms:

`approve(operator, tokenId)` grants control of one specific token. Sell one item on a marketplace, and this is the minimum the sale needs.

`setApprovalForAll(operator, true)` grants control of every token you hold in that collection, including ones you buy afterwards. This is what marketplaces request, because otherwise you would sign a transaction per listing.

That second sentence is the part that matters and the part rarely stated plainly. An operator approved this way in January has authority over an item you mint in June, with no further signature, because the permission attaches to the collection rather than to the pieces you owned at the time.

A token approval caps what can leave. An NFT approval does not cap anything — it hands over the collection.

Why the revoke tool said you were clean

Because it was showing you token allowances. Most dashboards default to the ERC-20 view, and the NFT approvals live behind a second tab labelled "NFTs" or "Collectibles". If you never clicked it, you audited half your exposure and came away reassured, which is worse than not auditing at all.

There is a second reason approvals are missed. setApprovalForAll is granted per collection contract, so one marketplace generates one approval for every collection you have ever listed from. A wallet that has traded across fifteen collections carries fifteen separate standing grants to the same operator, and revoking the one at the top of the list leaves fourteen.

Checking this properly means going contract by contract. A wallet scanner such as Riskira enumerates both approval types against an address without connecting the wallet, which is the right order of operations: know what is outstanding before you sign anything to change it.

How the signature gets obtained

Nobody reads setApprovalForAll and agrees to it. The signature is obtained in a context where an approval is expected, and three are common.

• A minting page. You are told to approve before minting, which sounds procedural. The approval is for a collection you already hold, not the one being minted.

• A "verification" or "wallet check" flow. Sites that ask you to verify ownership legitimately use a signed message, which costs no gas and grants nothing. If gas is being charged, it is not a verification — it is a transaction, and a transaction can change permissions.

• A support process. Someone helpful in a Discord walks you through fixing a stuck listing. The fix includes an approval.

The distinction worth internalising is the second one. Signing a message and sending a transaction are different acts. A message signature proves you hold the key; it cannot move an asset by itself. A transaction changes on-chain state, which includes granting operator rights. If your wallet shows a gas estimate, you are doing the second thing regardless of what the page called it.

The exception people get caught by is a gasless order signature — the EIP-712 typed data marketplaces use for listings. That costs no gas but is not a plain message either: it authorises a trade at terms shown in the structured data. Read the price and the collection in the wallet's decoded view before signing, because an order signed for 0.001 ETH is an order.

Auditing and revoking, in order

This takes about ten minutes for a wallet with normal history.

1. List both types. Open your revoke dashboard and visit the NFT tab explicitly. Note every setApprovalForAll still marked active.
2. Sort by what you actually hold. An approval on a collection you no longer own anything in is a low priority; one on your highest-value holding is not.
3. Identify each operator. A named marketplace you use is a considered risk. An unlabelled contract you cannot place is not — and unfamiliarity is reason enough to revoke, since re-approving takes one transaction when you next need it.
4. Revoke, cheapest first. Each revocation is its own transaction with its own gas cost, so batch them at a quiet period rather than during peak fees.
5. Re-check afterwards. Confirm the list is empty rather than assuming the transactions landed.

Two things this does not do. It does not undo a transfer that already happened — approvals are prospective only. And it does not protect a compromised seed phrase, because an attacker holding the key does not need an approval at all.

Keeping the exposure small afterwards

The durable fix is structural rather than procedural, because auditing depends on remembering to audit.

• Separate the wallets. Hold long-term items in an address that never connects to a site. Trade from a second address funded with only what is in play. This single split removes most of the risk class, since an NFT approval can only reach what the approving address holds.

• Prefer per-token approvals when the interface offers them. Some marketplaces will grant approve for a single tokenId. It costs one transaction per listing and it is worth it for high-value pieces.

• Treat approvals as expiring. Revoke after a sale concludes rather than leaving standing grants for a marketplace you might use again in eight months.

• Watch the approval, not just the balance. A wallet that alerts on new setApprovalForAll events tells you within minutes if something was signed that you did not intend, which is the window in which a mistake is still recoverable.

More on the permission model in web3 security, the related ERC-20 case in transaction safety, and the recovery-service scams that follow a loss in crypto scams. The function definitions themselves are in the ERC-721 standard if you want to read what you are granting.

The short version

Revoking token allowances does not revoke NFT approvals. They are granted by different functions, listed on a different tab, and setApprovalForAll covers every item in a collection including the ones you have not bought yet.

Audit both lists, revoke operators you cannot name, keep long-term holdings in an address that never connects, and remember that a gas fee on a "verification" step means you are signing a transaction, not proving ownership.