Approvals Beyond ERC-20: setApprovalForAll and Permit2

Three approval shapes, one habit

An ERC-20 approval is a number: the spender may move up to that amount of one token. It is set by a transaction, it can be changed by another transaction, and the risk is bounded by the number.

The two approvals in this guide are not bounded that way.

An operator approval is a boolean over a contract. It says the operator may manage every token the owner holds in that contract. There is no amount, no token id, and no per-item limit.

A Permit2 approval is a permission managed by a separate contract. It can be an on-chain allowance with an expiry, or a signed message that authorises one transfer. The signature is not a transaction, so it does not appear in the same place as an approve, and it may not be visible in a wallet’s approval list at all.

A revocation habit built only on ERC-20 allowances covers the first shape and misses the other two.

setApprovalForAll: one call, every token

EIP-721 defines setApprovalForAll(address _operator, bool _approved) as the function that can “Enable or disable approval for a third party (‘operator’) to manage all of msg.sender’s assets.” The standard adds that the contract must allow multiple operators per owner, and that the ApprovalForAll event “emits when an operator is enabled or disabled for an owner.”

EIP-1155 uses the same function name and a nearly identical definition: “Enable or disable approval for a third party (‘operator’) to manage all of the caller’s tokens.” It also requires the ApprovalForAll event and defines isApprovedForAll as the read function that “Queries the approval status of an operator for a given owner.”

The scope is the part that matters. EIP-721 says the operator can manage “all NFTs of the owner.” EIP-1155 says the approval covers “one’s entire set of tokens on behalf of the approver.” Neither standard provides per-token approval; EIP-1155 explicitly points to a separate scoped-approval interface for that use case.

Three properties follow:

1. It is owner-scoped, not collection-wide. The operator can move the tokens that this owner holds in that contract. It cannot move another owner’s tokens, and it cannot move tokens in a different contract.
2. It covers future tokens. The permission is a standing flag on the contract. A token the owner receives after the approval is covered by it, because the check is isApprovedForAll(owner, operator), not a list of token ids.
3. It is revoked by the same call with false. There is no expiry and no automatic decay. The approval lasts until the owner sends a transaction that turns it off, or until the contract is upgraded in a way that clears it.

Why a marketplace asks for it

The operator pattern exists because the alternative is unusable at scale. A marketplace that wants to let a seller list ten NFTs could ask for ten separate approve(tokenId, marketplace) transactions, each with its own gas cost. Or it could ask for one setApprovalForAll(marketplace, true) and then transfer any of the seller’s tokens when a sale occurs.

The second option is better for the marketplace and for the seller’s gas bill. It is also the option that a phishing site will ask for, because one signature or transaction gives it everything.

The attack does not require a bug in the NFT contract. The operator is doing exactly what the standard permits: calling transferFrom on tokens it is approved to manage. Theft and authorised transfer are the same operation from the contract’s point of view. The only difference is whether the owner intended to grant the operator.

That is why the confirmation screen matters more than the contract. A wallet that shows “approve all” without naming the operator and the collection is asking the user to trust a sentence they cannot verify.

Revoking an operator approval

Revocation is setApprovalForAll(operator, false). It is a transaction, it costs gas, and it has to be sent to the contract that holds the tokens.

Two practical problems follow.

The approval may not appear in the wallet. Many wallets show ERC-20 allowances because they can read allowance(owner, spender) for a known token list. Operator approvals are a different event and a different read. A wallet that does not index ApprovalForAll will show a clean approvals screen while an operator still has control. The check has to be done with a tool that reads the standard, not with a generic “revoke” button that only knows ERC-20.

The revocation is per contract. An owner who approved the same marketplace on five collections has five approvals to revoke, each with its own transaction. There is no batch revocation in the standard. A revoke tool may batch the transactions, but each one is still a separate call to a separate contract.

ERC-1155 uses the same function name, so the same habit applies. A single marketplace may hold operator approvals on both an ERC-721 contract and an ERC-1155 contract, and revoking one does not revoke the other.

Permit2: approvals managed by a second contract

Permit2 is described in its own documentation as a “next-generation token approval/meta-tx system.” It is two contracts:

• AllowanceTransfer manages allowances. A user grants a spender an amount for a duration, and later transfers require a valid permission.
• SignatureTransfer authorises a transfer by signature. The owner signs, and the spender submits the signature with the transfer.

The crucial first step is easy to miss: “users must approve the Permit2 contract through the specific token contract.” Permit2 does not eliminate the on-chain approval. It replaces the pattern of approving every spender individually with one approval to Permit2, after which Permit2 manages the permissions.

That first approval is still an approval to a contract address. If the address is the canonical Permit2 deployment, the risk is the risk of that contract. If a site asks the user to approve a different address and calls it Permit2, the name is doing work the address does not support. The address is the thing to check, not the label.

What a Permit2 signature actually authorises

The two Permit2 mechanisms have different risk shapes.

AllowanceTransfer is closest to a traditional approval. The owner grants a spender an amount for a duration. The documentation says approvals can be “time-bound” and that allowances can be revoked in batches. A broad, long-duration allowance is functionally similar to an unlimited ERC-20 approve, with the added feature that it can expire.

SignatureTransfer is the more distinctive mechanism. The owner signs an authorisation for a transfer instead of setting an allowance. The documentation says the signature “is valid only for the duration of the transaction in which it is spent,” and that the mechanism supports batched transfers to different recipients. Extra data can be included as a witness hash and witness type, and “The type string must follow the EIP-712 standard.”

The single-use property is a real improvement over a standing allowance: a signature that is not submitted cannot be replayed later. But it does not make a phished signature harmless. The party who receives the signature can submit it immediately, in the same transaction window, and the transfer happens. The window is short; the loss is not.

Reading the request before signing

The fields to check depend on which mechanism is in front of you, but the questions are the same.

A confirmation screen that does not answer the first four questions is not showing enough to make a decision. The clear signing versus blind signing guide explains why a wallet that shows a hash instead of the decoded fields is a different risk category, and the transaction simulation guide explains what a simulation can and cannot predict.

What these approvals do not do

They do not transfer ownership. An operator can move tokens, but the owner remains the owner of record until a transfer happens. Revoking the approval stops future transfers; it does not undo a transfer that already occurred.

They do not expire on their own. setApprovalForAll has no deadline. A Permit2 allowance may have one, but the user has to read it. An approval granted for a one-time mint can remain active for years if nobody revokes it.

They do not cover native assets. An operator approval is about tokens in a contract. It does not give the operator access to ETH in the wallet, and it does not authorise a transfer of a token in a different contract.

They do not replace a hardware wallet’s confirmation. A hardware device can display the operator and the collection if the wallet passes the decoded data to it. If the wallet sends only a hash, the device confirms a hash. The device protects the key; it does not invent context the software did not provide.

A checklist for approvals that are not ERC-20

• Check the contract address before approving, not the site’s label.
• For an operator approval, read the operator address and the collection, and ask whether the site needs every token or one.
• For a Permit2 request, identify whether it is an allowance grant or a signature transfer, and read the deadline and amount.
• Remember that the first Permit2 approval is an on-chain approval to the Permit2 contract.
• Revoke operator approvals with setApprovalForAll(operator, false), per contract.
• Use a tool that reads ApprovalForAll; a generic ERC-20 approvals screen may not show it.
• Re-check approvals after a mint or a marketplace session, because a new token is covered by an old approval.
• Treat a signature request as an authorisation even when it does not cost gas.

Sources and what they support

• EIP-721 — defines setApprovalForAll, the ApprovalForAll event, the operator’s scope over “all NFTs of the owner,” and the requirement to allow multiple operators. Read 2026-11-03.
• EIP-1155 — defines setApprovalForAll over “all of the caller’s tokens,” the corresponding event, and isApprovedForAll; notes that per-token approval requires a separate scoped interface. Read 2026-11-03.
• Uniswap Permit2 README — describes Permit2 as a token approval/meta-tx system with AllowanceTransfer and SignatureTransfer, states that users must approve the Permit2 contract through the token contract, describes time-bound allowances, batch revocation, single-use signature transfers, EIP-712 witness data and non-monotonic nonces. Read 2026-11-03.

Risk note. The standards and Permit2 behaviour described here were read from the specifications and the project’s own documentation on 2026-11-03. Contract implementations vary, and a wallet’s display is not the same as the contract’s state. Nothing here is investment advice.