Skip to main content

zkEVM Mainnet deployer allowlist

⚠️Waitlist during Immutable zkEVM Mainnet Early Access
While Immutable zkEVM Mainnet is in "Early Access", the deployer allowlist will be active. If you wish to deploy non-standard contracts to Mainnet, you will need to
  1. Follow the process described below to have your deployer wallet address added to the allowlist
  2. 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 Immutable 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.

💡Waitlist process for your project
Please note that there's currently no time estimation as to when your project will be allowed. We encourage you to use our standard contracts by deploying via Immutable Hub where possible, as the use of these don't require allow listing. The following criteria will be used in the prioritisation assessment:
  • 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"
Allowlist Help Menu
  • Follow the prompts and fill in the application details to join our Waitlist
  • Join our Discord community for updates

Requirements for custom collection contracts (ERC721/ERC1155)

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:

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 3 preset contracts:

  • Recommended Presets for Web3 Games:
    • ImmutableERC721.sol - Multiple batch minting functions for optimised gas efficiency. Compatible with Minting API. Multiple batch minting functions for offering gas efficiencies for different Web3 gaming use cases.
    • ImmutableERC1155.sol. Semi-fungible tokens. Compatible with Minting API.
  • Alternative Presets:
    • ImmutableERC721MintByID.sol. Single batch minting function requiring game studio to specify token_id at time of mint. Optimised for gas, yet less gas efficient than ImmutableERC721.sol. Compatible with Minting API.

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 and adding necessary overrides to approve and transfer functions, allowing your collection to interact with the OperatorAllowlist. OperatorAllowlistEnforced includes the modifier 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.

Example contracts using OpenZeppelin's ERC721 and ERC1155 standards with the OperatorAllowlistEnforced contract are provided below:

Below is an example ClashOfCatsERC721 contract that inherits our OperatorAllowlistEnforced:

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.19;

import '@openzeppelin/contracts/token/ERC721/ERC721.sol';
import {Ownable} from '@openzeppelin/contracts/access/Ownable.sol';
import {OperatorAllowlistEnforced} from '@imtbl/contracts/contracts/allowlist/OperatorAllowlistEnforced.sol';

contract ClashOfCatsERC721 is ERC721, Ownable, OperatorAllowlistEnforced {
constructor(
string memory name,
string memory symbol,
address operatorAllowlist_
) ERC721(name, symbol) Ownable() {
// OAL address is set in the constructor
_setOperatorAllowlistRegistry(operatorAllowlist_);
}

// Overrides _approve function to include `validateApproval` modifier for OAL
function _approve(
address to,
uint256 tokenId
) internal override(ERC721) validateApproval(to) {
super._approve(to, tokenId);
}

// Overrides setApprovalForAll function to include `validateApproval` modifier for OAL
function setApprovalForAll(
address operator,
bool approved
) public override(ERC721) validateApproval(operator) {
super.setApprovalForAll(operator, approved);
}

// Overrides _transfer function to include `validateTransfer` modifier for OAL
function _transfer(
address from,
address to,
uint256 tokenId
) internal override(ERC721) validateTransfer(from, to) {
super._transfer(from, to, tokenId);
}
}
💡Operator Allowlist Checklist

Here is a simple collection operator allowlist checklist you should follow to ensure your game has no delays at launch:

  • Have you imported OperatorAllowlistEnforced.sol?
  • Have you implemented the allowlist check on transfers?
  • Have you implemented the allowlist check on approvals?
note

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.

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 Immutable 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.

  • Operator Allowlist and preset contracts use solidity 0.8.19 version. If you are using a different version, you may need to fork and modify the contracts to be compatible with your version. Higher solidity version support will be added later.

IMX Whitepaper IMX Tokenomics Block Explorer Careers Contact Us