Almost every new chain's homepage carries the same line: fully EVM compatible. Those three words sound like a technical guarantee, but in practice they're closer to a marketing claim that deserves follow-up questions. What exactly is being promised — that contract code can be deployed unchanged, that wallets and explorers can connect without writing a single line of custom code, or just that the chain has a low enough bar that you can "write it in Solidity"? These three scenarios differ enormously in engineering terms, yet they routinely get compressed into the same sentence when a chain markets itself.
For a chain that chooses to keep EVM compatibility while also redesigning its execution model around parallelism, this isn't a rhetorical exercise — it's a daily engineering constraint. Once you've changed execution ordering and bolted on conflict detection and multi-engine scheduling, how do you guarantee that behavior at the bytecode level still matches Ethereum mainnet exactly?
The smallest unit of compatibility is bytecode, not syntax
The strictest definition of EVM compatibility lives at the bytecode level. The Ethereum Virtual Machine never executes Solidity source code — it executes a compiled sequence of opcodes, an instruction set built around a stack, memory, and storage, plus an account model where every address carries a nonce, a balance, a code hash, and its own storage tree. As long as opcode semantics, the gas price of every instruction, stack-depth limits, and the read/write rules for account state all match Ethereum mainnet exactly, a piece of bytecode that hasn't been recompiled should produce identical results on another chain.
This standard matters because it sets the floor for migration cost. True bytecode-level compatibility means contracts already deployed on Ethereum can, in principle, move over without recompilation — audited code doesn't need to be re-audited, and contracts that depend on CREATE2 address computation or that build reentrancy protection around a specific opcode's gas cost won't misbehave just because the underlying pricing rules changed. Conversely, if a chain only "supports writing contracts in Solidity," what a developer actually gets is syntactic familiarity — the moment a contract touches a specific gas-pricing assumption or an uncommon opcode, its behavior can drift.
The most systematic treatment of this gradient in the Ethereum ecosystem is Vitalik Buterin's 2022 piece on classifying zkEVMs. He ranked compatibility from high to low as Type 1 through Type 4: Type 1 changes nothing about Ethereum's existing system, so it can directly reuse existing block explorers and execution clients — Taiko is the representative project. Type 2 preserves a high degree of EVM equivalence with only minor low-level optimizations; Scroll and Linea fall into this category. Type 2.5 makes small modifications to details like gas costs and precompile support. Type 3 implements only a subset of opcodes, with some opcodes merged or replaced by versions more friendly to the proving system — meaning unmodified Ethereum bytecode isn't guaranteed to run as-is. Type 4 abandons bytecode-level compatibility entirely, compiling Solidity or Vyper to a custom virtual machine designed specifically for efficient proof generation; zkSync Era and StarkNet represent this end of the spectrum.
This classification was originally designed for zkEVM rollup schemes, but the underlying issue it exposes is universal: compatibility isn't a binary yes-or-no — it's a continuous spectrum running from bytecode equivalence at one end to mere source-level resemblance at the other. The further right you move on that spectrum, the more freedom you have to change the underlying system, but the higher the risk that a migrated contract behaves differently than expected.
Precompiles: the piece of a compatibility claim that's easiest to overlook
Beyond bytecode, another factor that determines how much a compatibility claim is really worth is precompiled contracts. Ethereum has built a set of cryptographic operations — ones that would be prohibitively expensive to implement in ordinary bytecode — into fixed addresses from 0x01 through 0x09: 0x01 is ecrecover, used to recover an address from a signature; 0x02 and 0x03 are the sha256 and ripemd160 hash functions; 0x05 is bigModExp, big-integer modular exponentiation; 0x06 through 0x08 handle addition, scalar multiplication, and pairing operations on the alt_bn128 elliptic curve, serving zk-SNARK verification; 0x09 is blake2F, added under EIP-152 to verify certain cross-chain transaction claims. After the Cancun-Deneb upgrade, 0x0a added a precompile for KZG commitment verification, serving data-availability verification for blob transactions.
These precompiles get singled out because they directly determine which applications can run on a chain at a reasonable gas cost. Without the alt_bn128-related precompiles, the on-chain verification cost for most zk applications becomes prohibitively expensive. If bigModExp's pricing doesn't match Ethereum mainnet, contracts that depend on RSA verification or certain cryptographic protocols will behave differently as a result. This isn't a hypothetical concern. The TRON ecosystem has actually run into underpriced ModExp precompile calls — the official proposal TIP-7883 explicitly notes that underpricing gave attackers room to trigger computationally expensive MODEXP calls at low cost, constituting a potential denial-of-service vector. Filecoin's EVM runtime has a similar detail-level discrepancy: its documentation explicitly states that, unlike Ethereum, precompile calls typically don't enforce a gas cap, meaning a single precompile call can, in theory, consume all of the remaining gas a caller supplied. These are real cases of "claims compatibility, drifts on the details" — not theoretical edge cases.
For any new chain claiming full EVM compatibility, whether its precompile list is complete and whether its pricing lines up with mainnet is a more worthwhile question to ask than "can it run a Hello World contract."
Tooling compatibility: the layer developers actually deal with every day
One layer further up is tooling compatibility. The development efficiency of the Ethereum ecosystem is built on an entire tooling ecosystem organized around the Solidity compiler, the standard JSON-RPC interface, and local development environments. Standard RPC methods like eth_call, eth_sendRawTransaction, and eth_getTransactionReceipt are the interfaces that wallets, block explorers, indexing services, and nearly all middleware call by default. As long as a chain precisely replicates the behavior of this interface at the RPC layer, infrastructure like MetaMask and The Graph can connect without any custom development.
At the development-framework level, the competitive landscape has shifted noticeably over the past two years. According to the 2024 Solidity developer survey, Foundry's usage share has flipped from trailing to leading, reaching 51.1%, versus 32.9% for Hardhat — though that doesn't mean Hardhat has been phased out; roughly 60% of existing projects still use it, it's just that new projects and security-focused development now default to Foundry as the primary framework almost as a matter of course. Foundry's core components are Forge, which handles compiling and testing; Cast, a command-line tool for on-chain interaction; and Anvil, which provides a local simulated node for quickly forking mainnet state to run integration tests. Hardhat has been catching up too — Hardhat 3, released in late 2025, introduced a Rust-based execution layer that substantially closed the testing-speed gap, and for the first time natively supports the Solidity-based test-writing style that had previously been exclusive to Foundry. Plenty of teams with high reliability requirements now run a hybrid strategy: Foundry for speed-sensitive unit tests and invariant tests, and Hardhat for deployment scripts and contract-verification workflows that need the TypeScript ecosystem and plugin system.
This tooling ecosystem matters because it determines developers' actual productivity, not just whether a contract compiles. According to Electric Capital's developer report, Ethereum's ecosystem added 16,181 active developers in the first nine months of 2025 alone, bringing its total active developer count to 31,869 — the fastest-growing and largest camp among all public-chain ecosystems. That scale effect means any new chain that genuinely plugs into this tooling ecosystem, rather than building its own from scratch, can directly draw on a developer base an order of magnitude larger, along with an already-proven auditing, testing, and monitoring apparatus — without needing to convince developers to learn a new language or an entirely new toolchain.
The cost of fake compatibility, and the extra difficulty parallel execution adds
Looking at bytecode, precompiles, and tooling together, "fake compatibility" typically shows up wherever one of these layers gets quietly simplified: a bytecode layer that implements only a subset of opcodes, causing some contracts to fail to run once compiled; an incomplete precompile list or pricing that deviates from mainnet, causing contracts that depend on cryptographic operations to incur abnormal costs or even carry security risks; a tooling layer that only supports the most commonly used RPC methods, so an indexer or explorer errors out the moment it calls an uncommon endpoint. These problems usually don't surface when the first contract gets deployed — they show up later, as application complexity grows and code starts calling cryptographic precompiles or relying on precise gas semantics for security design. For developers, the cost is that audited assumptions quietly stop holding on the new chain.
For a chain that changes its execution model from single-threaded serial execution to optimistic parallel execution, this problem gets a layer harder. Multi-engine parallel execution means transaction execution order and scheduling are entirely different from a native Ethereum client, and conflict detection and re-execution are newly introduced components altogether — yet opcode semantics, gas-pricing rules, and the resulting state root must match single-threaded execution exactly, or the result can't be called compatible; it can only be called a new chain that "looks like the EVM." That means the parallelization work can't stop at the scheduling layer — precompile pricing and execution results, and the account model's read/write semantics, all have to be verified line-by-line against a mainnet client after the redesign. That's exactly why so few projects manage to achieve full EVM compatibility while retaining parallel execution capability, and it's why every developer evaluating a new chain should seriously check whether its compatibility claim actually holds up at the bytecode and precompile level.
Further Reading
- Previous: "Positioning Bitroot: A High-Performance Layer 1 Built on Optimistic Parallel EVM"
- Next: "Who Should Read About Parallel EVM: Three Paths for Contract Developers, Client Engineers, and Researchers"
Sources: Vitalik Buterin, "The different types of ZK-EVMs" (vitalik.ca, 2022); EVM precompiled contract list (evm.codes, RareSkills); 2024 Solidity developer survey (Foundry vs. Hardhat usage data); Hardhat 3 release information; TRON TIP-7883 (ModExp precompile pricing issue); Filecoin EVM Runtime official documentation (precompile gas-limit discrepancy notes); Electric Capital 2025 developer report (Ethereum active developer data).