EVM compatible vs. equivalent: where to deploy your dApp in 2026

You deploy a Solidity contract on Optimism, and it works identically to Ethereum. You deploy it on zkSync, and compilation fails. You deploy it on Moonbeam, and it works — but your account address changes in another Substrate pallet. You deploy it on Scroll, and it works — but the COINBASE opcode returns a contract address, not the miner's. These differences seem minor until a cross-chain call fails in production with $10M in TVL. This technical guide breaks down why each modern EVM deviates from the standard in different ways — and how to choose a network without surprises.

What is the difference between EVM compatible and EVM equivalent?

The EVM (Ethereum Virtual Machine) is Ethereum's execution engine: a stack-based machine, 256-bit words, specific opcodes. Since Ethereum's success, dozens of networks have copied or adapted this model. But "compatible" and "equivalent" are not the same:

• EVM equivalent: strictly adheres to the Ethereum Yellow Paper. Your Solidity contract executes identically, byte by byte, opcode by opcode. Tools like Hardhat, Foundry, or Tenderly work without modification. Examples: Optimism, Base, Arbitrum One, Scroll (Type 2).
• EVM compatible: executes Solidity contracts, but the underlying architecture, storage model, or consensus are different. Some opcodes have different semantics; account addresses may be generated differently. Examples: Polygon PoS, Moonbeam, Avalanche subnets, BSC, zkSync Era, Tron.

The difference seems academic until you deploy. A contract that calls SELFDESTRUCT works on Ethereum and Optimism. It fails on Scroll. It doesn't compile on zkSync. And here the problem begins.

Why is Ethereum L1 the canonical standard?

Ethereum L1 executes the EVM monolithically and unified with consensus and data availability. The model is:

• Stack-based execution: PUSH, POP, ADD, MUL, etc. instructions. Each opcode occupies 1 byte. There are ~140 defined opcodes.
• 256-bit words: everything is manipulated as U256 integers. Same size as a Keccak-256 hash.
• Byte-addressable volatile memory, with quadratic gas cost for expansion. This makes large memory operations expensive to prevent DoS.
• 256/256 key-value storage persisted in the Merkle-Patricia tree.
• H160 addresses (20 bytes), derived with Keccak-256 on the secp256k1 public key.
• Evolution by EIPs coordinated in hard forks (Cancun, Pectra, etc.). Geth, Nethermind, Besu, Reth clients.

Any divergence from this model is an architectural decision with consequences. Let's go network by network.

How do optimistic rollups achieve EVM equivalence?

Optimistic rollups (Optimism, Arbitrum, Base) execute transactions off the Ethereum L1 chain but publish the data on L1. They inherit security by assuming transactions are valid, with a dispute period (7 days) during which anyone can challenge.

OP Stack — strict equivalence + deposit transactions

The OP Stack framework (Optimism Mainnet, Base, Zora, Mode, World Chain) pursues absolute EVM equivalence. But it introduces an alien concept: deposit transactions to communicate L1 ↔ L2.

When an L1 contract calls its L2 counterpart, OP Stack applies address aliasing: the sender's address is transformed by a fixed offset to prevent a malicious L1 contract from acting with the privileges of its homologous L2 address:

EOAs (external accounts) do maintain identical addresses; only contracts are aliased. Additionally, OP Stack eliminates the public mempool (only the sequencer sees it) and introduces differentiated finality states: Unsafe, Safe, Finalized.

Arbitrum Nitro + Stylus — Geth at the core + parallel WASM

Arbitrum Nitro (securing >$12,000M TVL) takes a different approach: it runs a modified version of the canonical Geth client for native execution. If there is a dispute, it compiles the state transition function to WebAssembly and resolves the conflict on L1 through multi-round interactive fraud proofs (BOLD).

The most radical innovation is Stylus: a second virtual machine based on WASM that shares storage with the traditional EVM, allowing contracts to be deployed in Rust, C, or C++. Its gas pricing uses a unit called ink which is converted to EVM gas:

How do zkEVM Type 2 vs Type 4 differ?

ZK-Rollups use cryptographic proofs (SNARKs/STARKs) to certify the legitimacy of transactions. L1 mathematically verifies thousands of executions in seconds. Withdrawal finality is quasi-instantaneous (vs 7 days in optimistic rollups). Vitalik's taxonomy classifies zkEVMs by equivalence level:

Scroll — Type 2 (bytecode equivalence)

Scroll is Type 2: the compiled Solidity bytecode executes identically. But it introduces modifications forced by the cost of proving certain opcodes in Halo2 circuits:

• COINBASE does not return the validator's address, but rather the fee vault contract's address (0x5300...0005)
• DIFFICULTY and PREVRANDAO always return 0
• SELFDESTRUCT is completely disabled: any call reverts
• EIP-1559 calculates basefee but does not burn ETH

Affected precompiles: RIPEMD-160, blake2f, point evaluation (EIP-4844 blobs) and BLS12 curves — all N/A. modexp has input limited to 8192 bits. Native 0p256Verify is added for secp256r1 signatures (EIP-7951).

zkSync Era — Type 4 (compiler equivalence)

zkSync Era does not interpret EVM bytecode. It uses zksolc (LLVM-based) to translate Solidity/Vyper directly to EraVM, a register-based virtual machine optimized for zk circuits. This causes deep discrepancies:

• Deployment: child contracts must be declared in the factoryDeps field of an EIP-712 transaction. CREATE and CREATE2 do not accept dynamic initialization code. type(T).runtimeCode throws a compilation error.
• Memory gas: constant linear (1 erg per byte), not quadratic. msize() reports bytes instead of 32-bit words.
• Forbidden opcodes: SELFDESTRUCT, CALLCODE, EXTCODECOPY are hard compilation errors.
• Native Ether: transfers are simulated via the MsgValueSimulator system contract — EraVM does not support passing balances in internal calls.
• Immutable variables: stored in ImmutableSimulator, not modifying the constructor's bytecode.

zkSync offers an optional EVM interpreter to execute standard bytecode without recompiling — useful for quick integrations but loses optimizations.

Why do Moonbeam and Astar have dual accounts?

Polkadot parachains operate on Substrate (Parity's modular framework). The EVM is not the core: it is added as an optional module via Frontier (pallet-evm and pallet-ethereum pallets).

The clash of formats is structural:

• Substrate SS58: 32-byte keys, sr25519 signatures, Base58Check format
• Ethereum H160: 20 bytes, secp256k1 signatures, hex

Frontier resolves addressing with a unidirectional mapping:

This generates a virtual SS58 account without a known private key, where balances accessible from EVM are stored. The hash function is unidirectional: it's impossible to deduce H160 from an arbitrary SS58.

Moonbeam broke this dualism: it reconfigured the entire Substrate runtime to use only H160 and secp256k1 natively. It allows using MetaMask to sign both EVM transactions and Substrate extrinsics. Astar maintains dual accounts but adds pallet-unified-accounts to manage explicit bidirectional mapping.

For the EVM to access the parachain's native state (staking, governance), Frontier uses precompiled contracts as translators: when the dApp invokes a precompile, Frontier internally executes Substrate pallet functions. This allows native staking or voting in referendums from Solidity code.

When is a sidechain better than a rollup?

Sidechains are sovereign chains parallel to Ethereum: their own validators, their own consensus, without security inheritance. The connection with L1 goes through bridge contracts with their own trust model. Four architectural models of bridges:

Gnosis Chain — stable xDAI gas

Gnosis Chain is a PoS sidechain secured by >200,000 validators. The most useful technical difference: gas is paid in xDAI, not its native GNO token. xDAI is a 1:1 USD stablecoin bridged from L1. Result: transactions that cost $0.001-$0.01 predictably, without volatility. Ideal for commercial apps requiring stable fees.

Polygon PoS — migrating to Validium

Polygon PoS publishes checkpoints on L1 every 30 minutes, but operational finality is local (DPoS validators with stake in POL). It is in architectural transition towards Validium L2: ZK validity proofs sent to Ethereum to certify state transitions without losing low cost. Migration driven by competitive pressure post-Kelp DAO.

Other cases

• SKALE Network: "free gas" model using sFUEL with no economic value. Breaks cross-chain protocols like LayerZero that require gas payment at destination — requires secondary ERC-20.
• Avalanche Subnets: customized EVM with gas in the subnet's native token or specific ERC-20.
• Tron VM: Solidity yes, but different API (TronWeb instead of Web3.js/Ethers). Gas paid in TRX.

What about SELFDESTRUCT, COINBASE, and other rare opcodes?

Summary of which network breaks which opcode:

If your contract depends on any of these, testing it on each network before migrating is mandatory. It's not enough to verify that it compiles.

How do I decide where to deploy my dApp?

Four questions in order:

1. Do you need maximum Ethereum security? → L2 rollup. Optimism, Arbitrum, Base if you want strict equivalence. Scroll if you need fast finality with zk.
2. Do you have heavy computational logic (proof verification, on-chain AI, big data)? → Arbitrum Stylus for WASM. zkSync EraVM if you accept losing standard tools in exchange for performance.
3. Do you need complex governance or native staking? → Parachain (Moonbeam, Astar). You accept account dualism in exchange for access to the Polkadot ecosystem.
4. Is your app commercial and needs predictable gas? → Gnosis Chain (xDAI). You pay with trust in the bridge; you gain fee stability.

The uncomfortable conclusion: there is no universal "best" network. There are networks optimized for specific use cases. EVM equivalence solves development friction, not necessarily operational friction. Acceptable EVM compatibility breaks tools but opens up capabilities impossible on L1.

Related guides