# 77 - Shedding the Light(er): the Fine Prints of ZK
A deep dive into Lighter’s verifiable perp-rollup design, explaining what ZK proofs actually enforce and what they don't
Stanford Blockchain Review
Volume 8, Article No. 7
✍🏻 Author: Billy Gao — Stanford Blockchain Club
Lighter, X
⭐️ Technical Prerequisite: Intermediate
Lighter is an application-specific zk-rollup built on Ethereum for perp trading. Unlike general-purpose Layer 2 solutions, Lighter generates SNARK proofs for every order match and liquidation event, claiming to deliver centralized-exchange-level performance with millisecond level latency while maintaining cryptographic verifiability.
Architecture Overview
At the heart of the architecture sits the sequencer that consumes transactions from the mempool and executes them sequentially against the orderbook state. The sequencer determines transaction ordering, integrates with oracle networks for price feeds, and structures executed transactions into blocks and batches. The sequencer provides “soft finality” within milliseconds, but true settlement only occurs after proof verification on Ethereum.
The prover receives execution data from parallelized witness generator services, which transform sequencer output into circuit-friendly inputs. The proving system employs a multi-layer aggregation approach where hundreds of thousands of individual execution proofs are combined into a single batch proof.
This aggregation is what makes verification on Ethereum economically feasible. Once the Ethereum smart contracts verify the batch proof against the stored commitment, the canonical state root advances and any onchain messages like withdrawal transfers would execute. The sequencer also posts compressed state deltas to Ethereum blobs, ensuring sufficient data exists onchain for users to reconstruct their state and exit independently if necessary.
State Tree Structure
The entire Lighter state is encapsulated in a merkleized data structure, using Poseidon2 for hashing. The root hash of this tree serves as a cryptographic commitment to the complete protocol state. This is what gets stored and verified on Ethereum. When a proof “verifies”, it demonstrates that a claimed state transition correctly transforms one valid root into another according to the protocol rules.
The tree contains several specialized sub-trees optimized for different operations. The account tree stores all user-related data, with each account leaf containing enough information to reconstruct a user’s complete state for exit purposes.
Another subtree is the orderbook tree which directly enables the price-time priority guarantee by encoding both price and time-priority into the leaf index itself. The encoding means that traversing the tree naturally encounters orders in price-time order. This design enables O(log N) operations for order insertion, removal, and quote retrieval while requiring only a single leaf access for matching operations. When a taker order arrives, the circuit can prove the correct maker was selected by verifying the Merkle path to that specific leaf.
Transaction Flow
When a user submits an order through the API, it enters the Sequencer’s mempool. The sequencer then determines the ordering of transactions.
After ordering, the sequencer executes transactions against the current orderbook state, generating execution receipts broadcast back to users via the API within approximately 5 milliseconds. However, this confirmation is not yet settled on Ethereum. The sequencer has committed to a particular execution, but that commitment is not yet cryptographically bound.
In parallel, execution data flows to the witness generator services, which prepare inputs for the Prover. The Prover generates SNARK proofs for the batch execution. Once the proof is ready, it is submitted to Ethereum smart contracts along with the batch commitment. The contracts verify the proof and, if valid, update the canonical state root. At this point, and only at this point, is the execution truly final in the Ethereum security model.
What Lighter’s ZK Proofs Actually Guarantee
The cryptographic guarantees provided by Lighter’s SNARK proofs are real and significant, but they have precise boundaries that are often misunderstood.
Execution Integrity
The most fundamental guarantee is execution integrity: given a sequence of transactions and oracle inputs, the resulting state is computed correctly according to the protocol rules. The prover cannot produce a valid proof for an arbitrary state transition. If the protocol specifies that a limit order at price P should execute against the best available counterparty, the proof ensures this actually happened. This ensures that the sequencer cannot modify account balances arbitrarily, or fabricate positions out of thin air.
This guarantee extends to all protocol operations encoded in the circuits. The circuits effectively act as a deterministic state machine where the sequencer provides the input ordering and oracle data, and the output state is uniquely determined. Any deviation from correct execution will cause proof generation to fail or produce an invalid proof that Ethereum contracts will reject. This is what “verifiable execution” actually means—not that the inputs are fair, but that the computation on those inputs is correct.
Price-Time Priority Within Batches
Lighter’s matching engine enforces price-time priority at the proof level, which is a stronger guarantee than most competing designs. To understand why this matters, consider how many zk-rollup orderbooks work: the sequencer performs matching offchain and the proof merely confirms that two orders intersected at a valid price. In such designs, when multiple makers have orders at the same price level, the sequencer can choose which maker gets the fill. As such, a sequencer could systematically favor a market maker, and the proof would still verify since “maker A and taker B traded at price P” is a true statement regardless of whether maker A was first in line.
Lighter’s circuit actually verifies that the correct maker determined by time priority was selected. By encoding time priority into the leaf index alongside price, the tree naturally orders makers at each price level. The matching operation requires accessing only a single leaf to find the best counterparty, and the circuit verifies that this leaf was correctly identified given the tree structure. This means within a given batch, once orders are included, a friendly market maker cannot be secretly prioritized over an older order at the same price.
However, the limitation that “within a given batch, once orders are included” is crucial. The proof verifies correct matching against the orderbook state at proof time, but the sequencer controls which orders enter that state and when.
Data Sufficiency for Self-Custodial Exits
The proofs attest that the data posted to Ethereum blobs is sufficient to reconstruct user states, which can be cryptographically verified. The account delta tree tracks all state changes during a batch, and its serialization to blobs is part of what the proof verifies. A valid proof cannot be generated if the blob data is incomplete or inconsistent with the state transition.
This guarantee underpins the escape hatch mechanism. If the sequencer fails to process priority transactions within 14 days, the rollup freezes and users can exit by proving their balance against the frozen state root using only Ethereum-posted data. The exit circuit verifies Merkle membership proofs against the state root, allowing users to withdraw without any cooperation from the sequencer. This is a meaningful improvement over other designs which lack a forced withdrawal path entirely. In those scenarios the users would have no onchain recourse if the validators stopped cooperating.
What Lighter’s ZK Proofs Do NOT Guarantee
The Ordering Problem
The Lighter whitepaper explicitly states that the sequencer’s core function is to determine transaction ordering. The proofs verify that execution was correct given the ordering, not that the ordering itself was fair. This is a crucial distinction.
Consider a concrete attack scenario. A user submits a large market buy order. The sequencer observes this order in its mempool before deciding on transaction ordering. Nothing prevents the sequencer from: (1) inserting its own buy order first at a lower price, (2) including the user’s order next, which moves the price up due to its size, and (3) inserting its own sell order at the higher price. This is a classic sandwich attack.
Every individual execution in this sequence is “correct” and will produce a valid proof. The user received correct execution at the price available after the sequencer’s front-running order, but that price just happened to be worse because the sequencer moved it. The proof verifies exactly what it claims: correct execution of the ordered transactions. It says nothing about whether that ordering was fair or whether the sequencer extracted value from the user.
Preventing this type of MEV extraction would require additional mechanisms entirely outside the proof system. Threshold encryption could commit orders before their contents are revealed to the sequencer. Commit-reveal schemes could separate order submission from execution. Enforced arrival-time ordering based on external timestamps could constrain sequencer discretion. The claim that “ZK makes front-running cryptographically impossible” is factually false. The proofs guarantee execution integrity, not ordering fairness.
The Inclusion Problem
The proofs verify correctness for transactions that are included in a batch. They cannot prove anything about transactions that were not included. If a user submits an order and the sequencer simply doesn’t include it in the current batch, no proof violation occurs. The sequencer might delay an order for seconds, minutes, or indefinitely. It might drop the order entirely.
The priority transaction queue and escape hatch mechanism address a specific subset of this problem in censorship of exit operations. Users can submit withdrawals, position closures, and other priority operations directly on Ethereum L1, and the sequencer must process them within 14 days or the rollup freezes. This provides exit liveness, such that users can always get your money out eventually. But it does not address general trading inclusion since there is no mechanism forcing the sequencer to include your limit order within any particular timeframe.
This creates a form of soft censorship that doesn’t trigger the escape hatch. A sequencer could systematically delay orders from certain addresses, or orders above certain sizes, or orders that would move the market against the sequencer’s own positions. Users would experience poor execution without any protocol-level recourse, because their orders are eventually included and all included executions verified correctly.
The Oracle Problem
Another subtle limitation concern comes from oracle data. The circuits prove that liquidations, funding calculations, and mark price applications were computed correctly using the supplied oracle data. They cannot prove that the oracle data reflects actual market conditions.
If the sequencer supplies a mark price of $100 when the true market price is $95, and this causes a user to be liquidated, the proof will verify that the liquidation was correctly executed at the supplied price. The liquidation was “correct” in the cryptographic sense where the circuit logic for liquidations was faithfully executed. But it was economically unjust because the input was wrong.
Lighter uses Stork as the primary oracle provider and constructs mark prices as a median of three values: orderbook impact prices, EMA-capped premiums, and CEX median marks. This is more robust than single-source oracles, but each input has potential manipulation vectors, and the median requires corrupting only two out of three sources.
Conclusion
Lighter represents an advancement in verifiable exchange design. The ZK architecture provides genuine guarantees absent in most competitors. These properties are cryptographically enforced and represent real security improvements over trust-based alternatives.
However, engineers and traders must understand the precise fine prints. The ZK proofs do not prevent MEV extraction since the sequencer controls ordering and can front-run at will. They do not guarantee prompt order inclusion with soft censorship through selective delay produces valid proofs. They do not verify oracle accuracy and they do not provide privacy with orderflow being visible to the sequencer.