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:
- 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
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):
- You may forfeit any token grants you may have received.
- Passport users will receive a warnings that your collection is likely to be counterfeit.
- 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.