Skip to content

Runtime Modes

ZEVM has exactly two runtime modes:

Normative sources: docs/specs/prd.md and docs/specs/json-rpc-contract.md.

  • trusted: writable local development node
  • light: proof-backed, consensus-anchored read-only runtime

Forking is configuration inside trusted mode, not a third mode.

Mode is selected from startup inputs in this order:

  • explicit CLI selector: --mode trusted or --mode light
  • otherwise, the config mode branch (mode.trusted or mode.light)
  • otherwise, the trusted-mode default

Light-mode operator-facing startup inputs are network, consensusRpcUrl, and executionRpcUrl, with optional checkpoint controls (checkpoint, checkpointDir, maxCheckpointAgeSeconds, strictCheckpointAge). If operators want persisted checkpoint-source behavior, they must manage checkpointDir/checkpoint themselves; ZEVM does not auto-populate it. Proof-source internals are not user-configurable in the public contract.

Phase 1 names the current public runtime/RPC scope in this docs set. GA posture here is source-build contract only (not packaged distribution channels). Within that scope, delivery remains trusted-first:

  • trusted mode carries the primary local dev-node surface (writes, simulation, mining, snapshots, and fork overlay controls)
  • light mode currently exposes readiness-gated proof-backed reads plus zevm_lightSyncStatus
  • deferred or unsupported light-mode methods are tracked in Unsupported And Deferred
  • deferred-surface promotion and phase-1 boundary/graduation criteria are canonicalized in Specs And Process
SurfaceTrusted modeLight mode
Core reads (eth_chainId, eth_blockNumber, account/code/storage/nonce reads)yesyes (limited to eth_chainId, eth_blockNumber, and proof-backed account/code/storage/nonce reads)
Simulation (eth_call, eth_estimateGas)yesno (-32010; both are trusted-only in phase 1, and eth_call remains a deferred light-mode proof-backed target)
Transaction submission and miningyesno
Canonical block, receipt, and log queries (including eth_getLogs)yesno
ZEVM trusted controls (zevm_* except zevm_lightSyncStatus)yesno
Trusted compatibility aliases (anvil_*, selected hardhat_*, selected evm_*)yesno
Light readiness/status (zevm_lightSyncStatus)noyes

Methods unavailable in the active mode fail with -32010.

Compatibility alias acceptance is closed-world: accepted aliases are exactly those listed in the Accepted aliases columns on ZEVM Controls, Submission Methods, Mining And Txpool Methods, Time And Block-Environment Methods, and Fork-Source Methods.

Tag or selectorTrusted modeLight mode
latestcurrent local headlatest verified optimistic execution head
pendingalias of latestunsupported
safealias of latestconsensus-anchored safe head
finalizedalias of latestconsensus-finalized head
earliestblock 0block 0
numeric quantityexact local block numberblock 0, or an exact block inside the retained verified-history window

Trusted-mode pending, safe, and finalized are compatibility aliases only.

In light mode:

  • eth_chainId is always callable
  • ready = true can be reached only after status transitions to synced and ZEVM has accepted verified optimistic (latest), safe (safe), and finalized (finalized) heads
  • while ready = true, verified-head ordering must hold: finalized <= safe <= latest
  • if status leaves synced or slot coherence no longer holds (finalizedSlot <= safeSlot <= optimisticSlot), ZEVM sets ready = false in the same transition before serving the next readiness-gated RPC call
  • while ready = false, proof-backed reads fail with -32011
  • while ready = false, eth_blockNumber also fails with -32011
  • once ready, eth_blockNumber returns the latest light-mode head number
  • numeric selectors are bounded to block 0 and retained verified-history blocks
  • numeric selectors outside that retained window fail with -32602