Background
ERC721C is an extended version of the standard ERC721 contract that introduces configurable control mechanisms for marketplaces, whitelists, and authorization rules. These configurations define which addresses or contracts are allowed to perform specific actions — for example, minting, transferring, or interacting with the NFT contract.
In particular, the whitelist determines which operators (e.g., marketplaces or custom smart contracts) can execute token transfers without being restricted by the contract’s transfer logic. The authorizers, on the other hand, are responsible for verifying and enforcing these permissions at runtime.
Updating these configurations correctly is critical to maintaining secure and compliant token operations. Misconfiguration can lead to blocked transfers, unauthorized listings, or exposure to malicious operators.
How to check Whitelist and Authorizers
Each ERC721C contract has a corresponding TransferValidator contract. On block explorers (such as Etherscan), you can view the TransferValidator’s “Read Contract” section to inspect its configuration details.
Authorizers Mode (Recommended):
Check getCollectionSecurityPolicy method, make sure first parameter in response is false.
In this mode, we need to make sure magic eden royalty zones in authorizer.
Chain | Zone Address |
Ethereum | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Polygon | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Arbitrum | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Sei | 0x679d0ac4c9d28235645a1868ae33a101dbf48a97 |
Berachain | 0xb44d689fa76adfffbca5ee35b073e80b2a9a68c6 |
Base | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Avalanche | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Bsc | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
Abstract | 0x714f9ae540f66cd8d900aef7f4f1cc4e6ade137c |
Apechain | 0x19f1b63f4fa6ee5ebca6017e04d837483d6cdf3d |
WhiteList Mode:
If we don’t use authorize mode, we should also check getCollectionSecurityPolicy method, we should see the third parameter in response, this represent transferSecurityLevel.
Magic Eden conduit on other chains is: 0x2052f8a2ff46283b30084e5d84c89a2fdbe7f74b, abstract is 0xda20e10c1e8098dbde281bd251b9b280ef9a0ff5
Level 0 – Recommended
Operator must be whitelisted OR authorized by authorizer OR caller == from (OTC)
Level 1 – No restrictions
Your conduit can call freely.
Level 2 – Blacklist + OTC enabled
Your conduit must NOT be blacklisted (neither its address nor its codehash). Whitelist not required.
Levels 3, 5, 6 – Whitelist + OTC enabled
Since your conduit is the caller (and not the token owner), it must be:
Whitelisted (address or codehash in the list applied to the collection), OR
Authorized by an allowed authorizer (
beforeAuthorizedTransfer/afterAuthorizedTransferflow).(If the token owner calls directly, OTC allows it without whitelist; but marketplace conduits are operators, so they must be whitelisted or authorized.)
Levels 4, 7, 8 – Whitelist + OTC disabled
Transfer is allowed if caller or
fromis whitelisted, or the transfer is authorized, or their codehashes are whitelisted.For a conduit (caller !=
from), you again need whitelist (address/codehash) or authorization.Level 9 – Soulbound
No transfers at all.


