Eita
Seeblock · Zürich  ·  hello@eita.run
LiveArc mainnet, replayed in real time →
Formal methods · Execution layer

A provably-correct EVM.

Eita is an Ethereum Virtual Machine specified in Lean 4 and derived from its proof — correct by construction, not by audit. The correctness layer for financial software.

Ethereum mainnet from genesis through the Merge  ·  15.5M blocks  ·  every block checked against the chain  ·  0 divergences ∎
What’s proved
  • Ethereum mainnet from genesis through the Merge, replayed bit-exact. every block’s gas, logs bloom, receipts and transactions roots match · the full state root every 250,000 blocks · over 170M accounts and 690M storage slots verified ∎
  • Sixteen forks, Frontier through Amsterdam — one Lean specification. EELS-tracked, clause by clause · the executable is generated from the spec verified ∎
  • The state transition itself — calls, creates, storage, transactions, blocks — derived from Lean. ten effect-layer proofs · gas formulas emitted from the spec · native ARM64 and x86-64 backends verified ∎
  • A parallel transaction schedule, proven to produce exactly the state of running the block in order. Block-STM refinement theorem · validation proven necessary · executor derived next verified ∎
In production · Arc

Arc mainnet, every block, as it lands.

Eita replays Circle’s Arc chain from genesis and follows it live. Every number on the Arc pages is folded from the fact log that replay writes — USDC supply, holders, fees, protocols and lending — and each window states its block range, the state roots checked in it, and the fact-log shards behind it.

Architecture

One specification. One streaming engine.

The Lean specification is the only place the EVM’s rules are written. Everything that executes is generated from it, and everything the engine produces is checked against the chain as it runs.

Specification

Lean 4, clause by clause

The Ethereum execution specs, ported fork by fork. Gas, state effects, and the parallel schedule are theorems, not comments.

Derivation

Emitted, not hand-written

The host effect layer and gas formulas are emitted from the spec; a gate re-checks every proof on each change.

Backends

Native code

Opcode handlers for ARM64 and x86-64, a JIT for hot contracts, and a Common Lisp host you can open up while it runs.

the engine, one stage per core  →
1 · decode

Block input

Blocks, receipts and uncles decoded straight from bytes into typed values, ahead of execution.

2 · execute

Replay

Transactions run in order against an in-memory hot set; cold state is read from the snapshot through an in-memory index.

3 · verify

Every block

Gas, bloom, receipts and transactions roots recomputed and compared. Nothing durable claims an unverified block.

4 · record

Fact log

Every call, log, transfer and state change into a binary columnar log with a history index — one encoder lane per table.

5 · persist

Layered snapshots

The hot set freezes into a delta layer in 0 ms; layers compact into a new base in the background, where the full state root is checked.

Current numbers

Fast enough to follow the chain — and getting faster.

15.5M
Ethereum mainnet blocks replayed from genesis, all verified
810
Mgas/s sustained on 2022 blocks, one replay on a 30-core cloud VM
0 ms
replay pause at a snapshot; the state root is checked in the background
~7 GB
working memory for the replay, with over 170M accounts and 690M storage slots in the snapshot
  • DoneThe Merge — block 15,537,394, the first proof-of-stake block.Crossed on 28 October, by the same engine and the same specification.
  • DaysThe chain tip, about 26.3 million blocks.Then the replay follows new blocks as they arrive, each checked before it is recorded.
  • Next1.2–1.5 Ggas/s, still executing in order.Per-transaction cost fell 57 % this week, from 28.4 to 12.3 µs on our 2018 benchmark; the remaining serial costs are measured and queued.
  • ThenParallel execution, from the proof.The Block-STM schedule is already proven equivalent to running the block in order; the executor is derived from that theorem.

As of 28 October 2026.

The idea

Vibecoding is fast, but unproven. Put a machine-checked specification between the AI and the code, and you keep the speed — with a proof underneath.

The model writes the implementation; a formal proof in Lean is the gate. The result is correct by construction, not correct by hope. Eita is the existence proof that this works at the scale of a whole EVM — built by one engineer and the verification loop.

Why it matters

When the code moves money, correctness can’t be a hope.

For programmable money, a single execution or accounting bug is a consensus split, a frozen settlement, or a regulatory event. Today that risk is held back by audits and testing — best effort, not proof. Eita turns “trust us” into “here’s the proof”: a verified execution and state engine that indexers, block builders, and searchers can all build on, knowing the state they see is exactly the state the chain produced.

From the EVM outward
01 · now

Verified execution

A formally-verified reference client, conformance harness, and differential oracle — the correctness backstop for a chain and the state substrate beneath its tooling.

02 · next

Verified contracts

AI-generated stablecoin-finance contracts — paymasters, FX, upgrades — written against machine-checked specs and shipped with their proofs.

03 · horizon

The platform

Correct-by-construction financial software beyond the EVM: ledgers, settlement, compliance as code. How regulated financial systems get built.