EVM differences on Lumia

You're porting a contract written for Ethereum (or another EVM chain) to Lumia and need to know where the zkEVM's behavior diverges from what you're used to.

Who this is for: developers deploying existing Solidity contracts on Lumia, especially anything using low-level opcodes, SELFDESTRUCT, or a hash/pairing precompile. Prerequisites: Smart Contracts on Lumia. Time: 5 minutes to read; longer if you need to rewrite affected code.

The short version

Lumia's zkEVM supports the EVM instruction set with a small number of modified opcodes and three unsupported ones, plus a reduced precompile set. The full, current table lives at /reference/evm-opcodes. This page explains why it matters and doesn't repeat the table.

What to check before you deploy

Modified opcodes: these still work, but don't behave the way they do on Ethereum L1:

• SELFDESTRUCT is removed and replaced by SENDALL. If your contract (or an inherited library) relies on SELFDESTRUCT to reclaim funds or as an upgrade/kill-switch mechanism, that code path needs rewriting, not just redeploying.

• EXTCODEHASH reads from the zkEVM state tree, not raw bytecode the way you may be assuming.

• DIFFICULTY always returns 0. If any code branches on difficulty (rare, but seen in old randomness hacks), it will behave differently.

• BLOCKHASH returns all previous block hashes, not just the last 256. Do not assume the Ethereum L1 256-block window applies.

• NUMBER returns the number of processable transactions, not a conventional block number in the way some contracts assume. Check any logic that does arithmetic on block.number.

Unsupported opcodes: using these will fail, full stop. SHA256, BLAKE, PAIRINGS are not supported. A contract or an imported library (some ZK/aggregate-signature libraries call these) that touches any of the three will not deploy or will revert at call time.

Precompiles: only ecRecover and identity are supported; every other precompile address reverts. This affects anything relying on modexp, the bn256/alt_bn128 pairing precompiles (common in some ZK-verifier and BLS-signature libraries), or ripemd160.

Verify it worked

Compile and deploy on Beam testnet first (see /build/smart-contracts/deploy-with-hardhat). If deployment or a specific call reverts with no clear reason, check whether the reverting code path touches one of the opcodes/precompiles above before assuming it's a logic bug.

Troubleshooting

Deployment reverts with no revert reason

Search your contract and its imports for selfdestruct, sha256(, or a pairing-precompile call; these are the most common cause on a straight L1 port.

A library you didn't write yourself fails

Some audited libraries (older BLS/ZK-verification code) call bn256Pairing/modexp internally. Check the library's source, not just your own contract.