Differences to Ethereum

EVM differences

The Immutable zkEVM chain is built from a geth fork. While Immutable keeps its chain as consistent as possible with mainnet Ethereum, there are some notable differences. This section summarises those differences.

Solidity compatibility

Immutable zkEVM's most recent hard fork brings us in line with Ethereum's Cancun fork. We therefore officially only support Solidity versions up to and including 0.8.25. This means that if you use ^, you will pull the latest solidity compiler version that may not be compatible with Immutable zkEVM.

In Solidity, that is

pragma solidity <=0.8.25;

EIP-4844 Blobs

Blob transactions are not currently supported. Any such transactions will be rejected by the Immutable zkEVM RPC.

The BLOBHASH op code will always return an empty bytes32 (0x0).

The BLOBBASEFEE op code will always return 0x1.

The blobGasUsed and excessBlobGas block headers will always be 0x0.

PREVRANDAO Op Code

The PREVRANDAO op code was introduced by EIP-4399. The op code is specified to return the value of the mixHash field of the block header.

Immutable zkEVM runs a consensus mechanism based on EIP-225 which requires the mixHash field of the block header to always be set to uint256(0).

Therefore, smart contracts deployed on Immutable zkEVM cannot rely on PREVRANDAO op code to return a pseudo-random value. It will always return uint256(0).

RPC endpoint support

We’ve disabled support for debug_* calls because they have an unbounded memory usage on geth, and we don’t want it to be used as a DDoS vector. We expect users who rely on these endpoints to query QuickNode instead.

Additionally:

• We’ve disabled support for engine_* calls because they are unnecessary in our current deployment
• We’ve disabled support for txpool_* calls to prevent front-running
• We’ve disabled support for admin_* calls

For a list of supported methods, see this documentation.

Access Control Lists (ACLs)

Immutable currently has one gating list:

1. Transaction blocklist - This ACL will apply to Mainnet and Testnet. To comply with international regulations, we must block a list of sanctioned wallet addresses from accessing the chain.

Please note that Immutable previously had a Deployer Allowlist during the early days of our chain. The Deployer Allowlist was removed on 2024-Oct-14. Our chain is now open for any web3 developer to deploy their protocol on Immutable zkEVM.

Royalty enforcement

💡MANDATORY COMPLIANCE

To make sure that creators receive their hard earned loyalties, Immutable requires that all collections of ERC-721/1155s deployed on Immutable zkEVM implement the Operator Allowlist. Not implementing will have these effects for your collection (i.e. ERC-721/1155s):

1. You may forfeit any token grants you may have received.
2. Passport users will receive a warnings that your collection is likely to be counterfeit.
3. Your collection will not appear on any of the 3rd party marketplaces in our ecosystem.

For more information on the Operator Allowlist, please see this guide.