zkEVM Types 1-4 Explained: Vitalik's Classification

Vitalik Buterin's zkEVM classification sorts zero-knowledge rollups into four types based on a trade-off: Type 1 is fully equivalent to Ethereum itself but slow to prove, while Type 4 is fastest to prove but requires the most changes from standard Ethereum execution, with Types 2 and 3 sitting in between.

Why this classification exists

Building a zkEVM means designing a system that can both execute EVM-style smart contracts and generate a cryptographic validity proof of that execution. These two goals pull in opposite directions: Ethereum's actual execution environment includes design choices (specific hash functions, state trie structures, precompiled contracts) that are expensive to represent in the circuits a ZK prover uses. The more faithfully a zkEVM copies Ethereum exactly, the harder its prover has to work. Vitalik's classification, published in 2022, gives the ecosystem shared language for describing where a given project sits on that spectrum.

The four types

Type 1: Fully Ethereum-equivalent. No changes to Ethereum at all — not even to data structures like the Merkle Patricia Trie or obscure gas cost quirks. The goal is that Ethereum itself could theoretically become a Type 1 zkEVM rollup one day. This is the hardest to build and slowest to prove, because none of Ethereum's harder-to-prove design choices get simplified away.

Type 2: EVM-equivalent. Fully compatible with existing Ethereum applications and tooling at the bytecode level, but with minor changes to underlying data structures (for example, a simpler state tree) that make proving more efficient without breaking compatibility for developers or their contracts.

Type 2.5: EVM-equivalent except gas costs. A variant of Type 2 that keeps bytecode-level compatibility but adjusts gas costs for certain expensive-to-prove opcodes, making those operations pricier to reflect their real proving cost.

Type 3: Almost EVM-equivalent. Compatible with the vast majority of existing contracts, but with a handful of exceptions — certain precompiled contracts or edge-case opcodes might not be supported or might behave slightly differently. Most contracts deploy without modification, but a small number may need tweaks.

Type 4: High-level-language equivalent. Instead of proving EVM bytecode execution directly, the rollup compiles higher-level source code (Solidity, Vyper) into a custom instruction set built specifically for efficient proving. Contracts behave the same at the source-code level, but the underlying bytecode and gas metering are different, meaning bytecode-level tools (some debuggers, certain low-level tricks) may not carry over.

Comparison table

Type	Ethereum equivalence	Prover speed	Developer friction	Example use case
Type 1	Full	Slowest	None	Long-term goal, closest to "Ethereum itself as a rollup"
Type 2	Bytecode-level	Slow-moderate	Minimal	Chains prioritizing maximum compatibility
Type 2.5	Bytecode-level, different gas	Moderate	Minimal	Balances compatibility with prover efficiency
Type 3	Near-complete	Faster	Small, edge cases only	Common transitional stage for newer zkEVMs
Type 4	Source-code level	Fastest	Higher (bytecode tools may break)	Chains prioritizing performance over tooling parity

Why the spectrum keeps shifting

Most zkEVM projects don't stay in one type forever. It's common for a new zkEVM to launch as a Type 3 or Type 4 — accepting some compatibility trade-offs to ship faster with efficient proving — and then progressively move toward Type 2 or even Type 1 equivalence as proving technology and hardware improve (specialized proving hardware, better circuit design, recursive proof aggregation). Treat a project's "type" as a snapshot, not a permanent label, and check its own documentation or roadmap for the current status.

What this means if you're choosing where to build or deposit

For developers, a lower-numbered type (closer to 1) means less risk of hitting an edge case where your contract behaves unexpectedly, but potentially higher gas costs and slower finality due to prover load. A higher-numbered type (closer to 4) usually means cheaper, faster proving, but you should specifically test contracts that rely on precompiles, low-level opcode tricks, or exact gas cost assumptions before deploying.

For users, the type mostly matters indirectly — through which DeFi protocols choose to deploy there and how mature that ecosystem becomes. A highly compatible zkEVM tends to attract established DEXs and lending protocols faster, since their code needs little to no modification. You can compare live protocol counts and activity across different L2s and zkEVMs on /chains and /defi.

Bottom line

The zkEVM type classification is a useful shorthand for understanding a specific trade-off: exact Ethereum compatibility versus proving efficiency. No type is objectively "better" — Type 1 offers the strongest compatibility guarantee, while Type 4 offers the best current performance. When evaluating a zkEVM, check its current type, understand what compatibility gaps (if any) exist, and watch its roadmap for how it plans to move toward fuller equivalence over time.