"EVM-compatible" might be the single most common technical claim in crypto marketing. It's on the landing page of nearly every new chain, and it's meant to communicate one reassuring idea: everything you already use on Ethereum will work here. The problem is that the phrase has no standard definition, no certification body, and no test you can point to. Two chains can both call themselves EVM-compatible while differing in ways that break deployed contracts. The previous post in this series covered EVM equivalence — the strict end of the claim, where behavior matches Ethereum's specification exactly. This one covers everything below that bar, which is where most chains actually live.
EVM compatibility means a blockchain can run smart contracts written for the Ethereum Virtual Machine, with some degree of fidelity to how Ethereum itself would run them. That "some degree" is doing a lot of work in the sentence, and unpacking it is the whole point of this post.
The Levels Compatibility Actually Spans
Compatibility isn't one property. In practice it's at least three, and chains mix and match them.
Bytecode-level compatibility is the strongest form: the compiled contract — the actual bytes deployed on Ethereum — runs unmodified. Chains built on forks of Ethereum's own client software sit here. BNB Chain, Polygon PoS, and Avalanche's C-Chain all descend from Geth, Ethereum's dominant execution client, which is why contracts redeploy onto them so cleanly. This is adjacent to equivalence but not identical to it; a Geth fork can still diverge on gas costs, precompiles, or how quickly it adopts Ethereum's upgrades.
Source-level compatibility is weaker: your Solidity code compiles and runs, but it's compiled for a different virtual machine. The chain executes something that behaves like the EVM at the level of your source code while working differently underneath. zkSync Era is the clearest example — Solidity in, custom ZK-friendly bytecode out. Your contract logic survives the trip. Its compiled artifact, its exact gas behavior, and some of its edge cases don't.
Interface-level compatibility is the layer most users actually touch: the chain speaks Ethereum's JSON-RPC API, so MetaMask connects, ethers.js works, addresses start with 0x, and transactions look familiar. This is cheap to provide and easy to mistake for the deeper forms. A chain can be interface-compatible while running a substantially different VM — Tron is a reasonable example, EVM-derived but diverged enough that porting isn't trivial.
Marketing pages almost never say which of these they mean. That's not an accident — "EVM-compatible" is self-declared, and the vagueness is useful.
Where Compatibility Quietly Breaks
The failures aren't dramatic. They're small mismatches that surface late, usually in production, which is what makes them worth cataloguing.
Gas costs are the classic one. Ethereum has repriced opcodes multiple times over its history, and any contract with hardcoded gas assumptions — the 2,300-gas stipend that Solidity's transfer forwards is the famous case — behaves differently on a chain whose gas schedule diverges. The contract doesn't error in an obvious way. It just fails under conditions that never occurred in testing.
Missing opcodes are the more recent one, and there's a concrete story here. Ethereum's Shanghai upgrade in 2023 added a trivial opcode called PUSH0. Solidity's compiler started emitting it by default from version 0.8.20. Suddenly, freshly compiled contracts failed to deploy on every "EVM-compatible" chain that hadn't implemented Shanghai yet — which, for months, was most of them. Nothing about those chains had changed. Ethereum's spec had moved, and their compatibility silently aged.
That example generalizes into the point I'd most want a reader to keep: compatibility is a treadmill, not a checkbox. The EVM isn't frozen — Ethereum hard-forks roughly yearly, adding opcodes, repricing operations, changing edge-case behavior. A chain that was faithfully compatible in 2023 and then stopped tracking upgrades is measurably less compatible today without having touched anything. When you evaluate the claim, the question isn't "is this chain EVM-compatible?" It's "how quickly does it track Ethereum's forks, and what's the current gap?"
Beyond gas and opcodes: precompiles may be missing or live at different addresses, block times and finality differ (contracts that use block numbers as clocks miscount), and JSON-RPC implementations disagree on small things that break indexers and monitoring in ways that take a while to notice.
Where the Constraints Live
The hard constraint is that the specification belongs to Ethereum. Compatible chains don't get a vote on where the EVM goes — they inherit decisions made in Ethereum's core-development process and choose how fast to follow. The soft constraints are incentives: claiming compatibility is free, verifying it is work, and no authority polices the term. Ethereum's execution-spec test suites exist and serious teams run them, but nothing forces a marketing page to disclose the results. The gap between claim and behavior persists because nothing structural closes it.
What's Changing
Two currents run in opposite directions. The EVM keeps spreading: chains with no architectural relationship to Ethereum keep adding EVM execution layers because that's where the developers, audited code, and tooling already are. The network effect is the product. At the same time, the assumption that the EVM is the terminal state is weakening at the edges — Solana's VM has held real developer share, Move-based chains persist, and even inside the EVM camp, projects are adding alternative VMs alongside (Arbitrum's Stylus supports Wasm next to the EVM rather than instead of it). Vitalik Buterin's zkEVM taxonomy, covered in the equivalence post, has also given the market sharper language — "Type 2," "Type 4" — which slowly crowds out the vaguest uses of "compatible."
What Would Confirm This Direction
More chains tracking Ethereum hard forks within weeks rather than quarters. Conformance-test results becoming something chains publish rather than something researchers dig for. Taxonomy-style labels displacing the bare "EVM-compatible" claim in how projects describe themselves.
What Would Invalidate or Change It
The EVM losing its default status would be the structural break — if alternative VMs pull a decisive share of new deployments, compatibility with the EVM stops being the claim that matters. A faster Ethereum upgrade cadence would stress the treadmill in the other direction: if forks land more often than compatible chains can track them, the compatible set fragments and the term degrades further. And if Type 1 and Type 2 systems become cheap to build, "compatibility" collapses upward into equivalence and this whole middle ground shrinks.
Timing Perspective
Now: Compatibility claims are self-declared and unevenly true. If you're deploying or depending on a compatible chain, the current fork gap and gas-schedule differences are checkable facts — check them.
Next: Watch fork-tracking lag as the differentiator. The chains that follow Ethereum upgrades promptly are making a different (and more expensive) commitment than the ones that don't, and the gap between those two groups is where the next PUSH0-style breakages will happen.
Later: A multi-VM landscape where EVM compatibility is one interoperability target among several — plausible, unscheduled, and dependent on developer migration that hasn't decisively happened yet.
Boundary Statement
This post maps what the compatibility claim covers and where it breaks. It says nothing about whether any given chain is secure, decentralized, or well-operated — a chain can be perfectly compatible and poorly run, or loosely compatible and excellent. Compatibility describes a relationship to a specification, not the quality of the system implementing it. No chain named here is being recommended or warned against.
