Open Source · MIT Licensed · Written in Zig

Parallel EVM
you can embed

A high-performance Ethereum Virtual Machine in Zig that runs independent transactions in parallel — a measured 5-6x throughput gain over sequential execution. An execution core, not a chain: link it into your L2 sequencer, agent runtime, or simulator via native bindings for Python, Rust, JavaScript, and C.

96+
EVM opcodes
arithmetic → environmental
5-6×
parallel throughput
independent transactions
4
FFI languages
Python · Rust · JS · C
256-bit
integer words
4 × 64-bit BigInt

Why this matters in 2026

Single-threaded execution is the bottleneck.

The workloads pushing hardest on the EVM are new: agentic payments and machine-initiated, high-frequency transactions; on-chain and verifiable AI settling results; and RWA settlement that needs deterministic, auditable execution. Parallel EVM is the answer — but it almost always ships as a whole new chain. Zig EVM ships the parallel execution core as an embeddable library instead.

Agent-driven throughput

Headroom for high-frequency, machine-initiated transaction floods that saturate sequential engines.

An engine, not a chain

No consensus, networking, or token to adopt. Link the core into the stack you already run.

Honest about limits

The 5-6x gain holds for independent transactions; shared-state contention reduces it. We say so.

How it compares

Qualitative positioning — Zig EVM is an embeddable engine; the others are mostly chains or full clients. Cross-project performance varies by hardware and workload; this is directional, not a benchmark.

Project What it is Parallel execution Embeddable as a library
Zig EVMEmbeddable EVM engine (Zig)Wave-based, 5-6x measured on independent txYes — stable C ABI + 4 bindings
MonadFull L1 chain / clientOptimistic parallel executionNo — you run/join the chain
reth (revm)Full Ethereum execution clientSequential by default; parallel via extensionsPartially — revm embeddable in Rust
gethFull Ethereum execution clientSequentialNo — client, not a library
Solana SVMNon-EVM runtime (Sealevel)Parallel via declared access listsPartially; not EVM-compatible

Quick Start

terminal
$ git clone https://github.com/cryptuon/zig-evm.git
$ cd zig-evm
$ zig build run
# EVM initialized with 96 opcodes
# Gas used: 21000
# Execution complete

New here? Read how it works or open the playground.

What is Zig EVM?

An embeddable, parallel Ethereum Virtual Machine — written from scratch in Zig.

Zig EVM is an open-source (MIT) implementation of the Ethereum Virtual Machine — an execution core, not a chain. It executes EVM bytecode with accurate, spec-matching gas metering across 96+ opcodes, runs independent transactions in parallel for a measured 5-6x throughput gain over sequential execution, and exposes native FFI bindings so you can embed it in Python, Rust, JavaScript, or C.

It is built for the 2026 workloads that break single-threaded engines — agentic payments, on-chain and verifiable AI, RWA settlement, high-frequency execution — by giving engineers a fast, understandable parallel EVM they can link into an L2 sequencer, agent runtime, prover, or simulator, without adopting a new network. Zig's zero-overhead abstractions and manual memory management sit underneath.

  • Spec-accurate. 96+ opcodes with per-opcode gas costs matching Ethereum, and out-of-gas protection.
  • Parallel by design. Wave-based dependency analysis and a work-stealing thread pool run independent transactions concurrently — throughput headroom for agent-driven, high-frequency workloads.
  • An engine, not a chain. A stable C ABI powers bindings for Python, Rust, JavaScript, and C — link it in, no consensus or token to adopt.

Problem → Solution

Why build another EVM?

Four gaps in the existing tooling — and how Zig EVM closes each one.

Parallel EVM usually means adopting a new chain

The problem

The parallel-EVM wave — Monad, MegaETH, Sei — mostly ships as a whole new L1 or client. Getting the throughput means migrating your network, consensus, and token, not just your execution.

Zig EVM's approach

Zig EVM ships the parallel execution core as an embeddable library. Link it into your L2 sequencer, agent runtime, prover, or simulator over a stable C ABI — from Zig, Python, Rust, JavaScript, or C — no network to adopt.

See the FFI bindings →

Sequential execution caps agent-driven throughput

The problem

Agentic payments and high-frequency, machine-initiated transactions flood the EVM with work. Sequential engines run it one transaction at a time — even when transactions touch entirely different accounts and could safely run together.

Zig EVM's approach

Wave-based dependency analysis groups independent transactions and runs them on a work-stealing thread pool — a measured 5-6x throughput gain over sequential execution on independent workloads, scaling to 8 threads. (Shared-state contention reduces the gain; we are honest about that.)

How parallel execution works →

Gas and opcode behaviour are easy to get subtly wrong

The problem

An EVM that is off by a little on gas costs or edge-case opcode semantics is worse than useless for testing and analysis.

Zig EVM's approach

Per-opcode gas costs match Ethereum specifications, memory-expansion gas is computed dynamically, and gas is charged before execution with out-of-gas protection.

Understanding EVM gas →

Black-box execution is hard to learn from

The problem

When bytecode runs inside an opaque engine, understanding what actually happened — the stack, memory, gas at each step — is painful.

Zig EVM's approach

An interactive playground disassembles bytecode and visualises the stack and execution trace, and the blog documents the internals opcode by opcode.

Open the playground →

Built for performance

Everything you need to execute, embed, analyse and debug EVM bytecode at speed.

How it works

Bytecode in. State out.

Each transaction runs through opcode dispatch, gas accounting and the stack machine. Independent transactions are grouped into waves and executed in parallel.

Bytecode + calldata, gas EVM core Opcode dispatch (HashMap) Gas metering Stack 1024 × 256-bit Memory 32-byte words Storage persistent KV State updates accounts + return Parallel: wave-based dependency analysis · work-stealing pool → 5-6× throughput

Performance benchmarks

The headline result is a measured 5-6x throughput gain over sequential execution on independent-transaction batches, scaling linearly to 8 threads. Absolute figures below are representative and depend on hardware and the transaction conflict rate.

Operation Ops/sec Avg latency
Simple Transfer 45,000 22µs
Token Transfer 38,000 26µs
Complex Contract 12,000 83µs
Parallel (8 threads) 250,000 4µs

See the methodology in Benchmarking EVM implementations.

Use from any language

Native FFI bindings let you embed Zig EVM in your existing projects. See embedding use cases →

Zig

const evm = EVM.init(allocator);
evm.execute(bytecode);

Python

from zigevm import EVM
evm = EVM()
evm.execute(bytecode)

Rust

let evm = ZigEVM::new();
evm.execute(&bytecode)?;

JavaScript

const { EVM } = require('zigevm');
const evm = new EVM();
evm.execute(code);

Learn EVM development

Deep dives into EVM internals, Zig systems programming, parallel execution, and blockchain infrastructure.

Zig EVM is part of Cryptuon Research.