Technical Architecture

Lighter EVM is an EVM-equivalent execution environment that runs as a sidecar to Lighter Core, the high-performance order matching engine at the heart of the Lighter protocol. Together, they form a unified rollup that settles on Ethereum L1 with zero-knowledge proofs.

This page provides a high-level overview of the system architecture and how its components fit together. For detailed specifications, see the linked pages throughout.

Design principles

The architecture is built around four goals:

• Non-custodial execution. Users retain full control of their assets at all times. The protocol enforces this through on-chain escrow, deterministic bridging, and an escape hatch mechanism that allows withdrawals even if the sequencer goes offline.
• Verifiable state transitions. Every state update, across both EVM and Core, is proven with zero-knowledge proofs before being accepted on L1. No trusted operator can forge state.
• Native interoperability. EVM smart contracts can read Core state synchronously and write to Core asynchronously, enabling DeFi applications to compose directly with Lighter's order book liquidity.
• Scalability. The dual-execution model separates general-purpose smart contract execution from the optimized order matching engine, allowing each to scale independently.

System overview

The system spans three domains that interoperate through a shared protocol:

• Ethereum (L1) serves as the settlement and data availability layer. The L1 bridge contract verifies ZK proofs and finalizes batches, and L1 smart contracts manage the priority queue and token escrow for cross-chain operations.
• Lighter EVM is an EVM-equivalent chain that executes general-purpose smart contracts. It supports standard Ethereum transaction types and exposes a system precompile for synchronous reads into Core state.
• Lighter Core is the specialized execution engine that handles order matching, account management, and derivatives trading with low latency.

Key components

Sequencer

The sequencer orchestrates both execution environments. It ingests transactions from separate Core and EVM mempools, maintains the write streams, pairs EVM blocks with Core blocks, and periodically bundles state diffs into batches for L1 submission.

Witness node

The witness node ingests data from L1 and re-executes both Core and EVM transactions to materialize the execution traces needed for proving. It serves as the data pipeline between the sequencer and the prover.

Prover

The prover generates ZK proofs that verify every state transition in the protocol. It contains three classes of circuits:

• EVM circuits are OpenVM programs that verify the EVM state transition function, including reads from Core and write stream updates.
• Core circuits verify the Core state transition function, including write fulfillment.
• Aggregation circuits are OpenVM programs that combine the EVM and Core proofs into a single batch proof submitted to L1.

Smart contracts

Smart contracts on both L1 and EVM enforce the protocol rules. On L1, the bridge contract accepts batch commitments, verifies ZK proofs, and finalizes state. Additional L1 contracts manage the priority queue, cross-domain asset registration, and token escrow. On the EVM side, a set of predeploy contracts provide the entry points for interop writes, withdrawals, L1 message relay, and fee collection.

Rollup state

The protocol maintains a unified global state across both execution environments:

Each EVM block is paired with exactly one Core block, called its parent Core block. This pairing establishes a causal ordering: the EVM block has synchronous read access to the Core block's post-state, and re-orgs in Core automatically propagate to dependent EVM blocks.

Native EVM and Core Interoperability

EVM and Core communicate through two complementary channels.

Synchronous reads from EVM to Core

A system precompile allows EVM smart contracts to query Core state within a single transaction. Supported queries include account info, balances, positions, and market metadata. Since reads target the pinned Core block's state, they are deterministic and require no cross-chain messaging.

Asynchronous writes

State-modifying operations between domains flow through write streams.

• EVM to Core: An EVM transaction calls the EvmToCoreEntrypoint or EvmInteropManager predeploy, which appends a request to the Core write stream. The Core sequencer picks up the request and fulfills it in a subsequent Core block. Supported operations include canceling orders and sending tokens to Core.
• Core to EVM: A Core transaction enqueues a write to the EVM write stream. The EVM sequencer derives an exogenous transaction to fulfill it, minting or transferring tokens on the EVM side.

This design decouples execution, neither chain blocks on the other, while maintaining protocol-level safety through the write stream commitments verified in the ZK proofs.

Batch lifecycle and finalization

The protocol periodically groups Core and EVM state changes, including cross-domain writes, into batches. The associated diffs are published in blobs, and their commitments are recorded on L1. Each batch then advances through three ordered stages.

1. Commit. The batch metadata and blob commitments are submitted to the L1 bridge. This records the proposed batch on L1 without proving that it is correct.
2. Verify. A zero-knowledge proof establishes the correctness of the committed batch, asserting the committed state roots and DA represent the outcomes of a valid state transition.
3. Execute. The bridge finalizes the verified batch and advances the canonical state. Withdrawals (from either Core or EVM) included in the batch become claimable on L1.

Governance can revert a committed or verified batch until it is executed. An executed batch cannot be reverted.

Token bridging

Assets can move freely between L1, EVM, and Core. Each token has exactly one canonical domain where the real token lives. On other domains, a 1:1 wrapped representation is minted, backed by tokens locked in an escrow contract on the canonical chain.

Escape hatch

If the sequencer or prover becomes unavailable, the protocol includes a permissionless escape mechanism named desert mode. Anyone can activate it once a priority request or a pending cross-domain write remains unfulfilled past a timeout. From that point on:

• Core freezes. L1-controlled Core accounts exit their balances directly on L1 by submitting ZK proofs of their balances against the frozen Core state commitment.
• EVM keeps running. Users continue to force-include transactions through the L1 priority queue, and proving becomes fully permissionless: anyone can advance the chain by submitting a proof for one batch at a time. This lets users unwind DeFi positions and surface withdrawable balances. EVM-controlled Core accounts can still move their balances to EVM.

This ensures that users can always recover their assets, regardless of operator liveness.