zkEVM Mainnet deployer allowlist
- Follow the process described below to have your deployer wallet address added to the allowlist
- Inherent OperatorAllowlistEnforced.sol to ensure proper handling of royalty and protocol fees
To start, key terms are clarified here to avoid any confusion:
- Deployer allowlist - your deployer wallet needs to be allowed to deploy any custom (ie non-Immutable standard) contracts on Mainnet. If you're only deploying standard contracts via Developer Hub, you don't need to to be added to the allowlist.
- Operator allowlist - smart contract interface that enables token approvals and transfers to be restricted to allow listed users. This enables on-chain royalties to be enforced by restricting a contract's transfers to Immutable's version of the Seaport contract that honors royalties.
- Waitlist - in order for your deployer address to be allowed, you will need to be on our waitlist. You'll find instructions below.
In an effort to maintain network integrity and security, the zkEVM chain has implemented a contract deployer allowlist to limit which addresses are permitted to deploy smart contracts on Mainnet.
This works on a per-deployer basis by specifically allowing the deployer wallet address.
While Immutable zkEVM Mainnet is in "Early Access", the deployer allowlist will be active. This means that in order for you to be allowed to deploy custom contracts, you will need to register on our waitlist. We will progressively assess your project during this period.
- You've successfully been approved for an Immutable grant
- You're building exclusively on Immutable zkEVM
- You're building a web3 gaming project
Process for waitlisting your project
- Log into Immutable Hub, and locate "Help" on the bottom left of your menu
- Here locate and click on "Deploy custom contracts on Mainnet"
- Follow the prompts and fill in the application details to join our Waitlist
- Join our Discord community for updates
Requirements for custom ERC721 collections
All collections deployed on Immutable's zkEVM must utilise the operator allowlist to protect content creator (eg: you, the game studio's) royalty fees and Immutable's 2% protocol fees.
This can be achieved through embedding the following into your smart contract collection designs:
Recommended Approach: For seamless implementation use or inherit Immutable's preset contracts tailored for gas-efficient creation of Web3 gaming assets on the zkEVM network. Immutable offers the following 2 preset contracts:
- Recommended Preset for Web3 Games: ImmutableERC721.sol - Multiple batch minting functions for optimised gas efficiency. Required for use of Minting API (upcoming feature)
- Alternative Presets:
Minimally Required Standard: If the above options are not compatible with your game design, it is mandatory for your collection to inherit the OperatorAllowlistEnforced.sol contract, allowing your collection to interact with the
OperatorAllowlist.OperatorAllowlistEnforcedincludes the functions to identify compliant smart contracts for approvals and transfers, ensuring the preservation of content creators’ royalty fees and protocol fees in third-party marketplace transactions.- If your game design restricts your collections from importing Immutable's preset contracts, please note that your request for inclusion on the Mainnet's deployer allowlist may undergo additional processing time. Immutable will conduct thorough verification to ensure that your collections comply with our mandated standards, safeguarding content creators on the network. Thank you for your understanding and cooperation in ensuring Immutable's zkEVM network remains secure for our web3 gaming community.
The use of the preset contracts accelerates integration with Immutable's ecosystem. If your studio has developed custom ERC721 or ERC1155 collections, ensure they adhere to their respective standards in addition to inheriting the OperatorAllowlistEnforced.sol contract, to safeguard compatibility with Immutable's ecosystem.
The enforcement of game studio royalties and Immutable's 2% protocol fee is achieved through the _setOperatorAllowlistRegistry function located within the OperatorAllowlistEnforced.sol contract.
function _setOperatorAllowlistRegistry(address _operatorAllowlist) internal {
if (!IERC165(_operatorAllowlist).supportsInterface(type(IOperatorAllowlist).interfaceId)) {
revert AllowlistDoesNotImplementIOperatorAllowlist();
}
}
For further details on royalty fee protection, refer to the product guide.
Some things to know
By allowing only specific addresses to deploy contracts, the network minimizes the risk of spam or malicious contracts, ensuring a safer and more reliable ecosystem. The allowlist acts as a filter to maintain a high standard of smart contracts on the network, encouraging best practices in development.
Currently, Testnet is an open network with no deployer allowlist. It allows unrestricted testing and development of custom contracts. The operator allowlist is implemented on Testnet, see the point below for additional details.
All Immutable preset contracts, including those on Testnet, adhere to Immutable's operator allowlist specification. This ensures a seamless transition for game studios when migrating contracts to the Mainnet. If your custom smart contract necessitates approvals for asset transfers or will facilitate asset transfers, it must be added to the operator allowlist by following this process.
If you deploy our standard preset contracts via Developer Hub only in your project, you will not need to be allowlisted. All Hub deployed contracts enforce Immutable's operator allowlist.
If you're however using custom contracts, when you are ready to move your project to Mainnet, your deployer address will need to be allowed based on the above waitlist process.
If your collection does not enforce Immutable's operator allowlist, or requires approvals to be permissioned to smart contracts not on Immutable's operator allowlist, it is unlikely your deployer address request will be approved in the waitlist process.