setApprovalForAll Explained: The NFT Approval That Drains Whole Collections
A setApprovalForAll scam is the most common way NFT collections get drained, and it almost always starts with one signature you did not fully read. The setApprovalForAll function is a standard part of the ERC-721 and ERC-1155 token specs. When you call it, you name another address as an "operator" and give that operator permission to move every NFT you hold from a given collection contract, now and in the future. There is no per-item limit and no amount field. Once an attacker is set as your operator, they can transfer out your entire collection from that contract in a single sweep, without asking you to sign again. This guide explains exactly what the grant does, why it is mechanically different from a token allowance, how malicious sites disguise the request, and how to audit and revoke it.
Key Takeaways
- setApprovalForAll grants an operator control over an entire NFT collection from one contract, not a single item.
- It has no quantity or amount field, so the grant is effectively unlimited and persistent until revoked.
- Fake mints and counterfeit marketplaces request it under the guise of "enabling" or "listing" your NFTs.
- Revoking an operator approval is a separate action from revoking ERC-20 token allowances.
What setApprovalForAll actually grants
setApprovalForAll takes two arguments: an operator address and a boolean (true or false). When you sign it with the value set to true, the NFT contract records that the named operator is allowed to call transferFrom and safeTransferFrom on any token ID you own within that contract. That is collection-wide authority. If you hold ten NFTs from one project today and mint five more next month, the operator can move all fifteen without a new signature.
This is the single most important thing to understand: the approval is tied to the collection contract and the operator, not to specific NFTs. You are not approving "this one ape." You are approving "anyone holding this operator key can take everything I own from this contract, indefinitely." It is the NFT equivalent of handing someone a master key to a room and letting them keep it. This persistence is why setApprovalForAll sits behind the majority of NFT wallet drains.
How it differs from an ERC-20 spending-cap allowance
Most people first meet the word "approval" through ERC-20 tokens. There, the approve function sets a spending cap: a numeric allowance a spender can pull, like 100 USDC. The risk with ERC-20 is the infinite-approval pattern, where dApps request an unlimited cap for convenience. But even an infinite ERC-20 allowance is still scoped to one token. setApprovalForAll is a different shape of risk because it is a boolean switch, not a number, and it covers your whole holding in a collection at once. If you are new to the concept, our guide to approval transactions covers the underlying mechanics in more depth.
| Property | ERC-20 approve | setApprovalForAll (NFT) |
|---|---|---|
| What it controls | One token type, up to a set amount | Every NFT you hold in one collection |
| Limit field | Numeric cap (can be infinite) | None, it is a true/false switch |
| Covers future assets | No, capped at the allowance | Yes, new mints are exposed too |
| How to revoke | Set allowance back to 0 | Call setApprovalForAll with false |
How fake mints and counterfeit marketplaces request it
Attackers rarely ask for setApprovalForAll out of context. They wrap it in a normal-looking action. A fake mint page promising a free or discounted drop will pop a wallet request the moment you click "mint," and that request is actually setApprovalForAll on a collection you already own. A counterfeit marketplace clone, often advertised through a hacked social account or a paid ad, will ask you to "enable" or "approve for trading" before you can list anything. Legitimate marketplaces do use setApprovalForAll, which is exactly what makes the fake version convincing.
The deception works because the action you expect (minting, listing, claiming) is plausible, and the wallet shows a function name most users do not recognize. This pattern overlaps heavily with ice phishing, where the malicious transaction is an approval rather than an obvious transfer, and with broader signature phishing tactics. The asset never leaves your wallet during the signing step, so nothing looks stolen yet. The drain happens minutes or hours later when the operator calls transferFrom and sweeps the collection. By then the approval has already done its job.
How to read the request before signing
The single best defense is learning to read the wallet prompt. When a site triggers a transaction, modern wallets display the contract method being called. If you see "setApprovalForAll" and a parameter set to "true" for an action that should not need it, stop. Ask whether the operation in front of you genuinely requires collection-wide permission. Claiming an airdrop, viewing a gallery, or connecting to a site should never require it.
Check three things. First, the function name: is it setApprovalForAll? Second, the operator address: does it match the verified contract of the platform you intended to use, or is it an unknown address? Third, the boolean: true means you are granting, false means revoking. Many drainer sites count on you clicking through the prompt on autopilot. A counterfeit marketplace will also often ask you to grant approval for a collection on a site you have never interacted with before, which is a strong red flag. If anything is unfamiliar, reject the request and verify the URL independently before you try again. Most of these flows are powered by an off-the-shelf wallet drainer kit designed to make the prompt look routine.
How to audit and revoke operator approvals
Operator approvals live on a different surface from ERC-20 allowances, so a tool or dashboard that only shows token spend caps may not surface them at all. To audit properly, use a revocation tool that explicitly lists NFT operator approvals, often labeled "approvals for all" or shown per collection. Connect your wallet in read mode, review every collection where an operator is set, and identify any operator address you do not recognize or no longer use.
To revoke, you call setApprovalForAll again on the same collection contract, this time with the boolean set to false for that operator. This is an on-chain transaction, so it costs gas, and it must be done per collection per operator. There is no single button that clears every NFT approval at once across all contracts. Our step-by-step revocation walkthrough shows the process for both token allowances and operator approvals. Make this a periodic habit, not a one-time cleanup, especially after using new mint sites or marketplaces.
Habits to avoid blanket-approving unknown contracts
Prevention is cheaper than cleanup. Keep a dedicated "minting" wallet that holds only the funds and NFTs you are actively using, so a bad approval cannot expose your long-term holdings. Treat every setApprovalForAll request as a deliberate decision rather than a formality, and never grant it on a site you reached through an ad, a direct message, or an unsolicited link. Verify marketplace and mint URLs from official sources, not search ads, which are routinely hijacked by drainer operators.
Finally, build a routine: review your approvals monthly, revoke anything stale, and revoke immediately after you finish using a one-off mint site. Operator approvals do not expire on their own, so an old grant from a forgotten project remains a live attack surface for as long as you leave it active. A few minutes of auditing protects assets that may be worth far more than the gas it costs to revoke.
This article is for educational purposes only and is not financial advice.