Key Takeaways
NFT approvals work differently from token approvals in a way that most holders never stop to consider, because the permission that makes NFT marketplaces convenient is the exact same permission that makes NFT drainers effective. A single signature can authorize an address to move every item you own in a collection, not just the one you're currently trying to list or claim, and that gap between what a request appears to cover and what it actually covers is where most NFT theft happens.
Direct answer: ERC-721 NFTs support two kinds of approval: approve, which authorizes a transfer of exactly one token ID, and setApprovalForAll, which authorizes an operator address to transfer every token you hold in that collection now and in the future. ERC-1155 collections only have setApprovalForAll to begin with. Legitimate marketplaces rely on setApprovalForAll so you don't have to sign a new approval for every single listing, but that same broad grant is what a fake mint or "verify ownership" site asks for when it wants to sweep an entire collection in one shot. Check every setApprovalForAll grant you've given with an approval-checker tool, and revoke any tied to a marketplace you don't recognize or no longer use.
- setApprovalForAll covers a collection's entire present and future holdings, not just one item, and stays active until manually revoked.
- NFT drainers favor setApprovalForAll precisely because it turns one signature into access to an entire collection at once.
- High-value NFTs make a single successful approval far more lucrative for an attacker than a typical token drain.
- Legitimate marketplaces genuinely need setApprovalForAll for normal listing workflows, which is exactly what lets a malicious request blend in.
- An approval-checker tool shows every setApprovalForAll grant you've given, to which operator address, so you can revoke what you no longer need.
- NFTs being unique does not protect them from a valid transfer approval; a live grant moves them exactly like any other on-chain asset.
How NFT Approval Mechanics Actually Work
Fungible token approvals, the kind covered elsewhere on this site, grant a spender the right to move up to a specific amount of a specific token. NFT approvals work on a different axis entirely, because NFTs aren't interchangeable units with an amount, they're individually identified items, and the ERC-721 and ERC-1155 standards that define how NFTs behave on-chain build their permission systems around that difference.
ERC-721, the standard behind most well-known NFT collections, defines two separate approval functions. The first, approve, takes a spender address and a single token ID, and grants that spender the right to transfer that one specific NFT and nothing else. If you own five items from a collection and approve one of them for a marketplace to complete a sale, that approval has zero effect on the other four; each token's approval is tracked independently, and approving one token doesn't touch any other token's approval state.
The second function, setApprovalForAll, works on an entirely different scope. It takes an operator address and a boolean flag, and when set to true, it grants that operator the right to transfer any and every token you own within that collection's contract, indefinitely, until the approval is explicitly revoked by calling the same function again with the flag set to false. Critically, this isn't limited to tokens you already hold at the moment you sign. Ownership at the collection level is checked at the time of any transfer attempt, not baked into the approval itself, so an operator holding a live setApprovalForAll grant can move a new item into that same wallet from that same collection the moment it arrives, even if the approval was signed months earlier and you've since forgotten it exists.
ERC-1155, the multi-token standard used for many gaming items, editions, and semi-fungible collections, simplifies this further by only including setApprovalForAll. There is no per-item approve function in the ERC-1155 specification at all, which means any operator approval granted on an ERC-1155 contract is, by the standard's own design, already a collection-wide grant with no narrower option available. If a site or app asks for an ERC-1155 approval, there is no "just this one item" version of that request to look for; the broad grant is the only kind that exists.
This distinction matters because it determines the blast radius of a single bad signature. Approving one ERC-721 token ID for a shady contract is a bounded mistake, limited to whatever that one item is worth. Granting setApprovalForAll to the same contract is unbounded in a very real sense: it covers your entire holdings in that collection today, and it keeps covering whatever you hold in that collection tomorrow, for as long as the grant stays live.
Why setApprovalForAll Is Used So Pervasively by Legitimate Marketplaces
It would be easy to read the previous section and conclude that setApprovalForAll is inherently a red flag, but that conclusion doesn't hold up against how NFT marketplaces are actually built to function. Every major marketplace, from long-established platforms to newer aggregators, relies on setApprovalForAll as standard operating procedure, and there's a concrete technical reason for that rather than pure convenience-seeking.
Without setApprovalForAll, listing an NFT for sale would require an on-chain approve transaction for that specific token ID before the marketplace's smart contract could ever execute a transfer on your behalf, and that transaction costs gas and requires a separate wallet signature. If you wanted to list ten different items from the same collection, you'd need to repeat that approve-then-list sequence ten separate times, paying gas ten separate times, before a single sale could go through. For active collectors and traders, that overhead adds up fast, both in fees and in the sheer number of signature prompts required just to manage a collection.
setApprovalForAll collapses that entire pattern into one signature per collection per marketplace. Approve the marketplace's contract once for a given collection, and every item you list from that collection afterward, this month or next year, goes through without another approval transaction, only the listing signature itself, which in many cases is a free off-chain signature rather than a gas-costing on-chain transaction. That's a genuine and significant improvement in usability, and it's the reason the pattern is universal across the NFT ecosystem rather than a shortcut any single platform could easily avoid.
The problem is that this legitimate, ubiquitous request looks identical whether it's coming from a marketplace you've used for two years or a fake mint page that was deployed yesterday. A setApprovalForAll prompt doesn't carry a badge saying who's really asking or what they intend to do with the access; it's a generic function call with an operator address attached, and the wallet interface presenting it to you often gives no more context than the raw request itself unless you specifically know to look closer. The exact feature that makes real marketplaces efficient is the same feature that lets a malicious request hide in plain sight among dozens of ordinary ones.
Why NFT Collections Are an Especially Attractive Drainer Target
Attackers optimize for return relative to effort, and NFT collections score unusually well on that calculation compared to typical token balances, for two compounding reasons.
The first is per-item value. A wallet's fungible token holdings are often spread across a modest balance of one or a few assets, but a single NFT from a sought-after collection can be worth many multiples of that entire balance, sometimes reaching into tens or hundreds of thousands of dollars for a single item during active market periods. An attacker who successfully phishes a token approval gets access to whatever balance was sitting in that token; an attacker who successfully phishes an NFT approval gets access to assets whose individual value can dwarf that, especially once a wallet holds several pieces from a valuable collection.
The second, and the more important multiplier, is scope. Stealing tokens one balance at a time is already efficient because a single approval typically covers an entire fungible balance in one signature. But stealing NFTs item by item, the way approve alone would require, means a separate approval and a separate transfer for every single piece, each one a chance for the victim to notice something is wrong or for the transaction to fail. setApprovalForAll removes that friction entirely for the attacker: one signature, and every valuable item in the collection becomes transferable in a single automated pass, no per-item interaction required. A wallet holding six items from a blue-chip collection isn't six separate theft opportunities anymore, it's one signature away from being emptied completely.
Put together, high per-item value and one-signature access to an entire collection is exactly the combination that makes building automated NFT sweeper infrastructure worth an attacker's time. A drainer operation that specializes in NFT approvals can target collections known for high floor prices, deploy a convincing front end once, and let a bot handle the actual transfers the moment each victim signs, extracting value at a scale that per-item theft could never match.
Worked Example: The Fake Allowlist Verification Sweep
Illustrative walkthrough — for education only.
Here's a realistic version of how a setApprovalForAll grant turns into a fully drained NFT collection, following the pattern most commonly reported by collectors.
Step one: the pretext. A collector who owns several pieces from a popular NFT collection sees a post in the collection's official-looking Discord or on social media announcing an upcoming companion drop, with allowlist spots reserved for existing holders. A link promises to let holders "verify NFT ownership" to secure their spot before the list fills up. The urgency and the holder-specific framing both feel plausible, since genuine allowlist campaigns for real collections work exactly this way.
Step two: the connect. The site looks polished, using the same fonts, colors, and even some of the same artwork as the real collection's official channels, because all of it was copied from public sources. A "Connect Wallet" button leads to a standard wallet connection prompt, which by itself reveals nothing sensitive, just the wallet's public address, so nothing about this step raises alarm.
Step three: the "verification" request. After connecting, a button labeled "Verify Ownership" or "Claim Allowlist Spot" triggers a wallet signature request. Behind that button, the site isn't running any actual ownership check, it's calling setApprovalForAll on the collection's real contract, naming the attacker's own address as the operator. Depending on the wallet used, the request may show as a plainly labeled "Set Approval For All" prompt with the operator address visible, or, in a wallet that doesn't decode the call clearly, as generic "Contract Interaction" text that gives no real indication of what's being authorized.
Step four: the signature. The collector, expecting a routine "confirm you hold this NFT" step, signs without scrutinizing the function name or the destination address closely, since the whole flow was built to look like a standard verification gate rather than a permission grant. The transaction confirms on-chain, and the site shows a success message, sometimes even fabricating a fake "You're on the allowlist" confirmation to keep the illusion going and delay suspicion.
Step five: the sweep. The attacker runs automated monitoring infrastructure watching for new setApprovalForAll events naming their operator address across whichever popular collections they're targeting. The instant this approval confirms, a bot script fires, executing transferFrom calls for every item the collector holds in that collection, moving them out one after another in rapid succession, often within the same block or the next few blocks. Some operations list the stolen items directly on real marketplaces at a discount for fast liquidity, others move them straight to a separate wallet for later disposal.
Nothing about the individual signature the collector approved looked obviously wrong in isolation, a wallet connection and a single transaction confirmation are both routine, unremarkable actions collectors take constantly. What made it work was the mismatch between the pretext, a supposedly harmless ownership check, and the actual on-chain call, an unrestricted, indefinite transfer authorization over the collector's entire holdings in that collection, a mismatch the interface didn't make obvious enough on its own to catch.
The Verification Habit for NFT Actions
The worked example above turns on one detail: nothing on the fake site needed to actually check NFT ownership, because the real target was the approval signature itself. A short verification habit, applied every time a wallet asks you to sign something related to an NFT, closes that gap before a signature goes out.
The habit: Before confirming any NFT-related signature, identify whether the request is approve, scoped to a single token ID and lower in risk, or setApprovalForAll, scoped to your entire collection and materially higher in risk, whenever your wallet surfaces that distinction. Then check that the operator or spender address matches the marketplace you actually intend to use, not just a name or logo on the requesting page.
Most modern wallets that decode transaction data will name the function being called, showing text like "Set Approval For All" or "Approve" along with the collection and operator address involved, rather than presenting only raw, undecoded calldata. If that information is visible, treat a setApprovalForAll request with more scrutiny than a single-token approve by default, since the two carry meaningfully different exposure regardless of how similar the surrounding page looks. A request framed as "verification," "claiming," or "checking eligibility" has no legitimate reason to need a setApprovalForAll grant at all; genuine ownership verification can be done by reading public blockchain data, which requires no signature and no approval whatsoever.
The operator address check matters just as much as the function name. A known marketplace's operator or conduit contract address is public information, and a request naming a different, unfamiliar address as the operator, regardless of how the requesting site brands itself, is not going to that marketplace at all. If your wallet or a transaction-simulation tool shows the destination address, compare it against the marketplace's officially published contract address before signing, the same way you'd check a bank's routing number rather than trusting a label alone.
None of this requires understanding smart contract code. It requires reading two pieces of information a decent wallet already surfaces, the function name and the operator address, before tapping confirm, rather than treating a signature prompt as a formality to click through.
How to Check and Manage Your NFT Approvals
Because setApprovalForAll grants persist indefinitely once signed, the realistic defense isn't only avoiding new bad signatures, it's periodically auditing the ones you've already given, some of which may be months or years old and long forgotten.
A token and NFT approval-checker tool, connected read-only to your wallet address, queries the relevant collection contracts for every address that currently holds an active setApprovalForAll grant tied to your wallet, across every collection you've ever interacted with. The result is a plain list: which collection, which operator address holds the approval, and, where the tool can identify it, which marketplace or service that operator address belongs to. This is the practical starting point described in more depth on this site's dedicated guide to token allowance checker tools, which covers fungible token allowances alongside NFT operator approvals in the same workflow.
Once you have that list, the review itself is straightforward. Marketplaces you actively use and recognize by name are generally fine to leave approved, since revoking them just means you'll need to re-approve the next time you list something there. Operators tied to marketplaces you tried once and never returned to, platforms that have since shut down, or addresses you simply don't recognize at all are the ones worth revoking, since each one is a standing grant with no corresponding benefit to you anymore. Revoking sends a new setApprovalForAll transaction with the flag set to false, which costs a small amount of gas but immediately and completely removes that operator's ability to move anything from the collection in question.
This is worth doing as a recurring habit rather than a one-time cleanup, particularly after connecting to any new NFT-related site, minting from a new collection, or participating in any claim or allowlist process, since each of those is a moment where a new approval, legitimate or not, may have been requested. A quarterly pass through an approval checker, or a check immediately after any unfamiliar mint or claim, catches accumulated grants well before their number becomes unmanageable.
Misconceptions Versus Reality
| Misconception | Reality |
|---|---|
| NFTs can't really be "stolen" the same way tokens can, since each one is unique | Uniqueness prevents duplication, not theft; a valid approve or setApprovalForAll grant lets the approved address transfer that NFT away exactly like any other on-chain asset |
| setApprovalForAll only covers the NFTs I currently own at the moment I sign | The grant authorizes transfers of anything you hold in that collection at any point while it's active, including items acquired after the approval was signed |
| If a marketplace I trust asks for setApprovalForAll, any request with the same wording must be safe too | The function name and framing are identical whether the requester is a real marketplace or a fake site; only the operator address distinguishes a legitimate request from a malicious one |
| A site can't actually steal my NFTs just by asking me to "verify ownership" | Genuine ownership verification requires no signature at all, since it can be done by reading public blockchain data; any signature requested for "verification" should be scrutinized as a potential approval grant in disguise |
| Revoking an old NFT approval is unnecessary if I haven't had a problem yet | An unused but still-active setApprovalForAll grant remains exploitable indefinitely if that operator's private key or infrastructure is ever compromised, regardless of how long it's gone unused without incident |
Common Mistakes That Make This Work
A handful of everyday habits around NFT approvals are what actually let this category of attack succeed against people who would never fall for a more obvious scam.
- Granting setApprovalForAll to every marketplace tried once, without ever revoking old ones. Collectors who experiment with several marketplaces over time accumulate operator approvals faster than they clean them up, leaving a growing set of standing grants to platforms they no longer use or barely remember trying.
- Not distinguishing NFT approval risk from token approval risk when reviewing wallet activity. Treating "I checked my token allowances" as equivalent to a full approval review misses the NFT-specific operator grants entirely, since they live in a separate part of the same approval-checker results and require the same level of attention.
- Signing "verification" or "claim" requests without checking what function is actually being called. A wallet prompt framed around confirming eligibility or ownership is assumed to be low-risk by default, when the underlying call can just as easily be a full collection-wide approval grant.
- Assuming a familiar-looking site or Discord announcement guarantees a request is legitimate. Visual branding and community framing are the easiest parts of a real allowlist campaign to copy; the operator address behind a signature request is not something copied branding can fake.
- Reviewing approvals only after a loss instead of on a recurring schedule. Standing setApprovalForAll grants sit exploitable indefinitely; a periodic check catches them before that operator's key or infrastructure is ever compromised, not after.
Risks, Limitations, and Exceptions
- Not every wallet decodes setApprovalForAll requests clearly; some still display raw calldata or generic "Contract Interaction" text, which limits how reliably the function-name check can be applied without a transaction simulator.
- An approval-checker tool can only report grants it can see on-chain; it can't retroactively undo a transfer that already occurred before the grant was revoked.
- Revoking an approval costs gas and requires a signed transaction, meaning cleanup itself carries a small, ongoing cost that can discourage frequent review if fees are high at the time.
- An attacker's operator address can be a fresh contract with no prior reputation, so address familiarity alone isn't a complete check; cross-referencing against the marketplace's officially published contract address is the more reliable step.
- A device already compromised by malware can undermine even a correctly scrutinized approval, since malicious software can alter what's displayed or silently substitute a different transaction than the one reviewed.
- Some legitimate protocol upgrades or marketplace migrations genuinely require re-approving a new operator contract, so not every unfamiliar operator address is malicious; verifying through the marketplace's own official announcement channel resolves that ambiguity.
Practical Implementation Checklist
- Before signing any NFT-related request, check whether your wallet identifies it as approve or setApprovalForAll, and treat setApprovalForAll with higher scrutiny by default.
- Compare the operator or spender address shown in the request against the marketplace's officially published contract address, not just the requesting site's branding.
- Treat any "verify ownership" or "claim allowlist spot" flow that requests a signature as suspect, since genuine ownership checks require no signature at all.
- Run a token and NFT approval-checker tool against your wallet address to see every active setApprovalForAll grant and which operator holds each one.
- Revoke approvals tied to marketplaces you no longer use, don't recognize, or can't verify against an official source.
- Repeat the approval check quarterly, and immediately after connecting to any new mint, claim, or allowlist site.
- Keep NFT approval review as its own step separate from token allowance review, since both live in the same checker tool but represent different exposure.
Tool Opportunity
A combined token and NFT approval dashboard, built for exactly this workflow, would let readers audit both fungible allowances and NFT operator grants for a connected wallet address in a single pass, without requiring a separate check for each collection.
Recommended inputs: a wallet address (read-only, no signature required to view), and an optional filter by chain or by collection for wallets holding NFTs across multiple networks.
Expected outputs: a list of every active setApprovalForAll grant with the collection name, the operator address, and where identifiable, the marketplace or service that operator belongs to, alongside a similar list for outstanding token allowances, with a one-click link into the revoke flow for each entry.
Validation requirements: never request a seed phrase or private key at any point in the flow, since the entire check only needs a public wallet address, and clearly label any unrecognized operator address as "unidentified" rather than guessing at a marketplace name it might belong to.
Sources
- Ethereum Improvement Proposals, "EIP-721: Non-Fungible Token Standard," defining the approve and setApprovalForAll functions for ERC-721 tokens. See eips.ethereum.org/EIPS/eip-721.
- Ethereum Improvement Proposals, "EIP-1155: Multi Token Standard," defining setApprovalForAll as the sole operator-approval mechanism for ERC-1155 tokens. See eips.ethereum.org/EIPS/eip-1155.
- OpenSea Support Center, guidance on reviewing and revoking wallet approvals granted to marketplace and third-party contracts. See support.opensea.io.
Frequently Asked Questions
What's the actual difference between approve and setApprovalForAll for NFTs?
For an ERC-721 collection, approve grants transfer rights over exactly one specific token ID and nothing else, so if someone misuses that approval the most they can take is that single item. setApprovalForAll grants an operator address transfer rights over every token you currently hold in that entire collection, plus every token from that same collection you acquire afterward, until you explicitly revoke it. ERC-1155 collections only have setApprovalForAll to begin with; there is no per-item approve function in that standard, so any operator approval on an ERC-1155 contract is already collection-wide by design.
Why do legitimate NFT marketplaces ask for setApprovalForAll at all?
Marketplaces use setApprovalForAll so you only need to approve their contract once per collection, rather than paying gas and signing a new approval for every single item you list. Without it, listing ten items from the same collection would mean ten separate on-chain approve transactions before the marketplace could ever execute a sale. That convenience is genuine, but it also means the request looks completely ordinary, which is exactly what a malicious site imitating a marketplace is counting on.
Why do drainers target NFT collections specifically instead of just tokens?
A single valuable NFT can be worth many times an average wallet's fungible token balance, and a single setApprovalForAll grant hands over an entire collection at once rather than requiring the attacker to steal each item individually. That combination of high per-item value and one-signature access to everything makes NFT collections an efficient target for automated sweeper bots.
How can I tell if a wallet request is asking for setApprovalForAll instead of a single approve?
Wallets that decode the transaction, rather than just showing raw hexadecimal data, will typically name the function being called, such as setApprovalForAll or Set Approval For All, and may show the specific operator address and a toggle for granting or revoking. If your wallet only shows generic text like "Contract Interaction" with no function name, that's a sign to slow down and verify the request through a transaction simulator or block explorer before signing, since the interface isn't giving you enough information to judge the risk on its own.
Can setApprovalForAll actually steal NFTs I haven't minted or bought yet?
Yes, and this is the detail most people miss. The approval isn't a snapshot of what you own the moment you sign; it authorizes the operator address to move anything from that collection sitting in your wallet at any point in the future, for as long as the approval remains active. An attacker holding a live setApprovalForAll grant can transfer a new item the moment it lands in your wallet, even months after the original approval was signed.
How do I check which setApprovalForAll grants I've given and revoke the ones I don't need?
A token and NFT approval-checker tool connected to your wallet address will list every setApprovalForAll grant across the collections you hold, along with the operator address each one was given to. From there you can identify grants tied to marketplaces you no longer use or don't recognize, and revoke them individually, which sends a transaction resetting that operator's approval status back to false.
Is it true that NFTs can't be stolen the way fungible tokens can, since each one is unique?
No, that's a common misconception. Uniqueness protects an NFT from being counterfeited or duplicated, but it does nothing to protect it from a valid transfer authorization. A live approve or setApprovalForAll grant lets the approved address move that NFT out of your wallet exactly as it would move any other on-chain asset, regardless of how one-of-a-kind the item is.
Conclusion
setApprovalForAll exists because listing NFTs one signature at a time would make marketplaces nearly unusable, and that legitimate purpose is precisely why it's the go-to request for NFT drainers: it's a normal, expected part of using any marketplace, which lets a malicious version of the same request hide among dozens of harmless ones. The gap between approve, bounded to a single item, and setApprovalForAll, unbounded across an entire collection present and future, is the single most important distinction to check before signing anything NFT-related. Read the function name your wallet surfaces, verify the operator address against the marketplace you actually intend to use, and treat any "verification" or "claim" flow that requests a signature as a request that needs justifying, not a formality to click through. Run an approval-checker tool periodically to see what you've already granted, and revoke anything tied to a marketplace you don't recognize or no longer trust. Use this page alongside the broader token approvals hub for the token-side version of this risk, and the revocation guide for the mechanics of clearing out old grants.
Related Reading
- Token Approvals & Blind Signing — the parent hub covering approval and signature risk across both tokens and NFTs.
- Malicious approval transactions — how attackers disguise approval requests as unrelated actions across both token and NFT contracts.
- Token allowance checker tools — the tools used to audit both fungible allowances and NFT operator approvals for a wallet.
- How to revoke token approvals — the step-by-step mechanics of clearing out approvals once you've identified which ones to remove.
- Malicious dApp connections — the broader pattern of harmful requests delivered through a fake or compromised site once a wallet is connected.