If you hold both tokens and NFTs in a self custody wallet on Base, you have probably noticed that NFT marketplaces ask for permission in a slightly different way than a swap does. It is easy to assume the mechanics are the same, approve a bit, use it, move on. They are not quite the same, and the difference matters for how much risk you are carrying at any given moment.
Two kinds of NFT standards, one approval system
Most NFTs on Base follow one of two standards. ERC-721 covers unique, one of a kind tokens, the kind used for profile picture collections and single edition art. ERC-1155 covers multi token contracts, where a single contract manages several token types and each type can have multiple copies, common for gaming items and editions. Our guide on NFTs on Base covers what these standards mean for ownership. Both standards share the same approval system, which is what this article focuses on.
approve versus setApprovalForAll
Both ERC-721 and ERC-1155 give you two different ways to grant permission, and they are not interchangeable.
approve targets a single item. You tell the contract that one specific address may transfer one specific token ID on your behalf. Once that token moves, or once you approve someone else for it, that permission is gone. It is narrow by design, similar in spirit to approving a fixed amount of an ERC-20 token for one trade.
setApprovalForAll targets an operator instead of an item. You tell the NFT contract that a given address may transfer any token you currently own in that collection, and any token you acquire in that collection later. It is a single yes or no switch, not a list, and it does not expire when one item changes hands.
Marketplaces almost always ask for setApprovalForAll rather than individual approvals. The reason is practical. If you list five items from the same collection, approving each one separately would mean five separate transactions and five separate gas fees. A single setApprovalForAll lets the marketplace's contract manage the whole collection with one signature, which is much cheaper and much more convenient.
Why the convenience comes with a cost
The tradeoff is that setApprovalForAll does not scale down. There is no version of it that says "just these three items" or "up to this value." It is all the tokens you hold in that contract, indefinitely, until you revoke it. If the address you approved is a legitimate, well audited marketplace contract, that is a reasonable trade of convenience for a small, well understood risk. If the address is a scam contract disguised as a marketplace, or a legitimate contract that later turns out to have a bug, the exposure is your entire collection in that contract, not one piece of it.
This is exactly the mechanism behind the NFT drainer scams you may have read about. A fake minting site or a fake claim page asks for a signature that looks routine, and buried in it is a setApprovalForAll grant to an address the scammer controls. Nothing visibly happens at that moment. The wallet does not lose anything until the operator actually calls a transfer, which can happen minutes or months later, on the attacker's schedule rather than yours. This is one of the reasons our guide on avoiding wallet phishing and drainer scams stresses reading what a signature actually says rather than clicking through it.
What to check before you approve
A few habits keep this permission from becoming a blind spot.
- Confirm you recognize the marketplace. setApprovalForAll prompts are normal on legitimate platforms like established Base marketplaces. The habit to build is checking that the site itself is the one you meant to visit, not assuming the prompt is safe because it looks routine.
- Read the wallet's approval screen. A well designed wallet will tell you plainly that you are granting an operator permission over an entire collection, not just one token. If a prompt is vague about what it covers, slow down before signing.
- Separate valuable NFTs from everyday ones. Some collectors keep a dedicated wallet for high value pieces and interact with newer or unfamiliar sites from a separate, lower value wallet. This will not stop a bad approval from happening, but it limits what a bad approval can reach.
- Treat setApprovalForAll for an unfamiliar address the same way you would treat an unlimited ERC-20 approval to an unfamiliar contract. The pattern in our piece on token approvals applies here too: broad, standing permissions deserve more scrutiny than narrow, one time ones.
Checking and revoking NFT approvals
The same tools that list ERC-20 approvals also list NFT operator approvals. A Base block explorer's token approval checker, or a dedicated tool like Revoke.cash, will show you which addresses currently hold setApprovalForAll status over your NFT contracts, alongside your regular token approvals. Revoking one is an on-chain transaction, just like revoking a token allowance, and it costs a small amount of gas. Our step by step guide on checking and revoking token approvals walks through the same tools, and the same steps apply directly to NFT operator approvals.
A reasonable habit is checking this list after using any marketplace or minting site for the first time, and again every month or two if you are an active collector. Revoke anything tied to a site you no longer use, and anything you do not remember approving at all.
The takeaway
NFT approvals are not a smaller version of token approvals, they work on a different scale entirely. A single setApprovalForAll grants control over an entire collection in that contract, not one item, and it stays active until you revoke it. That design exists for a good reason, it makes listing and trading NFTs practical, but it also means the permission deserves more attention than a routine click. Know when a prompt is asking for this kind of access, confirm the site asking for it is the one you intended to use, and review your list of operator approvals the same way you would review your token approvals.