Almost every new chain's homepage says "fully EVM compatible." That phrase sounds like a technical guarantee and behaves more like a claim that needs follow-up questions: can contracts deploy without changing bytecode? Can wallets and explorers switch only the RPC endpoint? Or does "compatible" merely mean "you can write Solidity"? These are three very different engineering promises that marketing routinely compresses into one sentence.
For a chain that keeps EVM compatibility while redesigning execution around parallelism, this is a daily constraint, not rhetoric. After reordering schedules and adding conflict detection and multi-engine execution, what matters is whether behavior visible to contract authors still matches Ethereum. Positioning Bitroot explained why Bitroot insists on full EVM compatibility; this article breaks "full" into four checkable layers.
Bytecode: the smallest unit of compatibility is the opcode, not the syntax
The EVM never runs Solidity source. It runs compiled opcodes — an instruction set built around stack, memory, and storage — plus an account model where each address has a nonce, balance, code hash, and its own storage tree. Strict compatibility means opcode semantics, gas metering, stack-depth limits, and account read/write rules align with a target Ethereum hard fork. Under that bar, unrecompiled bytecode should, in principle, produce the same state transition on another chain.
That standard sets the floor for migration cost. Bytecode-level compatibility means audited contracts need not be fully re-audited for silent syntax-layer drift; contracts that depend on CREATE2 address derivation or on a specific opcode's gas cost for reentrancy defenses should not misbehave because pricing changed under the hood. If a chain only "supports writing contracts in Solidity," developers get familiarity of syntax — and drift the moment they touch uncommon opcodes or gas assumptions.
Also check hard-fork alignment: the legal opcode set is not identical across Shanghai, Cancun, and later upgrades. A compatibility claim should name the Ethereum upgrade it tracks, rather than waving at a vague "EVM." Migration teams can redeploy mainnet runtime bytecode and compare code hashes plus return values on critical call paths.
Parallel execution adds pressure. Optimistic parallelism may speculate concurrently and later roll back, but for contract authors the committed state transition must still be equivalent to some definite serial order (usually the in-block transaction order). If scheduling changes the visible final state, that is not compatibility — it is a different virtual machine. For correctness boundaries and serializability, see Optimistic Concurrency Control (OCC) Primer. To place parallelism in a wider scaling map, compare A Map of Blockchain Scaling and The EVM Single-Thread Bottleneck: compatibility must preserve deterministic semantics contract authors rely on, not the single-threaded interpreter itself.
Precompiles: same address, different implementation is incompatibility
Ethereum implements expensive operations as precompiled contracts at fixed addresses such as 0x01–0x0a — elliptic-curve pairing, modular exponentiation, hashing, and more. Applications and libraries hard-code those addresses and gas costs. If a chain changes the precompile set, address mapping, or return semantics, Solidity may still compile while compatibility is already broken: audited libraries can fail on-chain or return wrong results.
Common "fake compatibility" patterns include implementing only popular precompiles, adding custom precompiles on reserved Ethereum addresses, or changing gas without documenting it. Migration teams should not trust the whitepaper's "EVM compatible" line; they should diff against the target fork's precompile table: same input and calldata, same return value and gas on mainnet versus the target chain. Pairing and modexp paths especially deserve coverage because they are expensive and often depended on by bridges, proof verification, and crypto libraries.
Parallel EVM does not require changing precompile semantics. The real risk is the temptation to specialize "for speed." Any precompile change for throughput should be an explicit protocol difference, not smuggled into a compatibility narrative. If a team adds custom precompiles for specialized computation, they should use clearly unreserved address space and document the diff so Ethereum-reserved addresses stay untouched.
JSON-RPC: tooling lives or dies on the interface, not the slogan
Deployable contracts are not the same as a usable ecosystem. Wallets, explorers, indexers, and monitors depend on JSON-RPC: eth_call, eth_getLogs, eth_estimateGas, eth_getTransactionReceipt, and the rest. If field meanings, error codes, log indexing, or pending-versus-latest semantics diverge from Ethereum client habits, frontends and infrastructure need adapters — and migration cost expands from "swap the RPC" to "rebuild the ops path."
eth_estimateGas and trace-style APIs deserve special attention. Under parallel execution, gas estimates that do not simulate final serial semantics can be systematically low or high; without mainnet-isomorphic traces, Foundry fork tests and incident forensics get harder. JSON-RPC compatibility is therefore not "MetaMask connects," but whether everyday develop and operate paths remain reusable. Filter subscriptions, eth_feeHistory, and EIP-1559-related fields often decide whether existing SDKs can go live with little more than a config change.
Indexers and explorers also need stable log ordering and receipt fields. If parallel execution changes when intermediate state is visible but final receipts stay isomorphic to mainnet, applications can usually cope; if receipt fields are missing or error codes are proprietary, ecosystem tools need forked maintenance. Compatibility acceptance should treat "read call + send tx + pull logs + estimate gas" as one closed loop, not only a successful deploy.
Tooling: Foundry and Hardhat are the court of last resort
For most teams, compatibility is judged locally: whether forge test, Hardhat scripts, OpenZeppelin contracts, and common verification plugins run against the target RPC with little or no change. Foundry (Forge / Cast / Anvil) is the default test stack for many new projects; Hardhat still covers a large installed base. Both assume compiler output, on-chain precompiles, and RPC behavior are close enough to Ethereum.
A short, repeatable acceptance checklist:
- Compile with the same Solidity version and optimizer settings; check whether deployed bytecode hashes match mainnet deployments (or differ only for explainable immutables).
- Diff critical precompiles.
- Fork target-chain state with Anvil / Hardhat Network and run existing integration tests.
- Change only chainId and RPC in a wallet and complete sign → send → receipt.
- Run invariant tests on core contracts: balance conservation, access control, and reentrancy defenses still hold on the target chain.
Any failure means "compatible" still has gaps. Bitroot puts complexity in runtime parallel scheduling rather than asking developers to rewrite Solidity or switch toolchains, so the paths above can stay intact; see also Bitroot Parallelised EVM Explained and Multi-Engine Parallel Execution Design. Compared with Three Approaches to Parallel Execution, insisting on bytecode compatibility means giving up some parallelism ceiling available via new account models, in exchange for a wider migration radius for the developer ecosystem.
How to read an "EVM compatible" claim
Turn the marketing sentence into four yes/no questions: Do bytecode semantics match the target hard fork? Is the precompile table identical? Does JSON-RPC cover common mainnet methods with isomorphic semantics? Can existing Foundry / Hardhat projects run with little or no change? Four yeses approach strict compatibility; any no should be an explicit diff document, not hidden behind a slogan.
Parallelism can change throughput and latency under conflict, but it should not rewrite the deterministic semantics contract authors rely on. User-visible retries and latency shifts under hot workloads are performance and workload questions, separate from "are the semantics compatible" — see later Conflict Hotspots and Workloads and Performance Metrics Glossary. A chain that buys a faster benchmark while making tooling and bytecode behavior unpredictable spends long-term ecosystem capital for a short-term poster — and the network effects of the EVM path are exactly what that poster is trying to purchase.
The next article gives role-based reading paths that point only to already published posts, so different backgrounds are not mashed into one article nobody can finish.