{
"message": {
"type": "underReview",
"text": "The requirement for available node software is under review"
},
"missing": {
"nextStage": "Stage 1",
"requirements": [
"Users' withdrawals can be censored by the permissioned operators.",
"Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.",
"The Security Council is not properly set up."
],
"principle": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
},
"stage": "Stage 0",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "A complete and functional proof system is deployed."
},
{
"satisfied": true,
"description": "The project calls itself a rollup."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "Inputs for the state transition function are posted to Ethereum L1."
},
{
"satisfied": "UnderReview",
"description": "A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code."
}
]
},
{
"stage": "Stage 1",
"requirements": [
{
"satisfied": true,
"description": "Users are able to exit without the help of the permissioned operators."
"satisfied": false,
"description": "Users' withdrawals can be censored by the permissioned operators."
},
{
"satisfied": false,
"description": "Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring."
},
{
"satisfied": false,
"description": "The Security Council is not properly set up."
},
{
"satisfied": true,
"description": "The proof system meets the minimum trusted setup requirements defined in the L2BEAT [trusted setup assessment framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381).",
"upcoming": true
},
{
"satisfied": true,
"description": "Prover source code is published.",
"upcoming": true
},
{
"satisfied": false,
"description": "Not all onchain verifiers' smart contracts can be independently regenerated from the verifier source code.",
"upcoming": true
}
],
"principle": {
"satisfied": false,
"description": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": false,
"description": "Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
},
{
"satisfied": false,
"description": "The Security Council's actions are not confined to onchain provable bugs."
}
]
}
]
}
scalingTechnology+14-5
{
"dataAvailability": [
{
"name": "All data required for forced exits is published onchain",
"description": "All the data needed to recover the latest accounts state (represented by the Account Tree) and construct the zk proof necessary for forced exits is published onchain in the form of blobs. Only data that leads to state changes is posted.",
"name": "Data published onchain, but state reconstruction is blocked",
"description": "Account delta data is published onchain in the form of blobs. However, a prover migration (gnark/MIMC → plonky2/Poseidon2) occurred at block 23,711,820 without publishing a state snapshot. The old gnark circuit was never open-sourced, so ~60k pre-migration blobs cannot be decoded. Without this snapshot, users cannot reconstruct the latest accounts state required for forced exits.",
"risks": [],
"references": []
"references": [
{
"title": "Lighter Prover v0.0.1 (first public release, Dec 2025)",
"url": "https://github.com/elliottech/lighter-prover"
},
{
"title": "StateRootUpdate event — gnark to plonky2 migration",
"url": "https://etherscan.io/tx/0x6a50b2b00444914e5c53df2fb48404078a098f93fc3911e6fcbde1c7b6418225"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exit",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is settled the funds become available for withdrawal on L1. ZK proofs are required to settle blocks. Finally the user submits an L1 transaction to claim the funds.",
"risks": [],
"references": []
},
{
"name": "Escape hatch through ZK proofs",
"description": "If the centralized operators fail to process forced transactions after the deadline, the system can be frozen (desert mode) and users can exit by reconstructing the latest settled state using the data available on L1 and providing a ZK proof of balance.",
"description": "If the centralized operators fail to process forced transactions after the deadline, the system can be frozen (desert mode) and users are expected to exit by reconstructing the latest settled state and providing a ZK proof of balance. In practice, this is not currently possible: the desert mode circuit source code is not public, and pre-migration blob data cannot be decoded (see data availability note). Users must rely on operator cooperation to exit.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force their transactions on L1",
"description": "If the centralized operators fail to include user transactions, users can force them themselves through L1. The possible transaction types that users can force are: deposits, withdrawals, order creation, order cancellation, and burning of pool shares. If the operators do not process forced transactions within 14d, the system can be frozen (desert mode) and users can exit using the latest settled state. All open positions are settled using the latest index price.",
"risks": [],
"references": []
},
"operator": {
"name": "Centralized operators",
"description": "Only the centralized operators can submit batches and verify them with a ZK proof, i.e. advance the state of the protocol.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "External oracles used for index prices",
"description": "Lighter uses a combination of oracles to determine index prices, with Stork as the primary source. External signatures are currently not verified and the sequencer must be trusted to truthfully report data.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the oracle prices are manipulated."
}
],
"references": [
{
"title": "Lighter docs - Fair Price Marking",
"url": "https://docs.lighter.xyz/perpetual-futures/fair-price-marking"
}
]
}
],
"stateValidation": {
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid transactions to the previous state. This includes user transactions originating from L1 and L2, as well as internal transactions created by L2 operators. In the desert mode, valid proofs of exit must be generated. These proofs are then verified on Ethereum by a smart contract.",
"categories": [
{
"title": "Prover Architecture",
"description": "[This repo](https://github.com/elliottech/lighter-prover/tree/main) contains the circuits and prover code for normal (i.e. non-desert) operation mode of Lighter. It includes the logic to generate and verify proofs of valid state transition according to the Lighter [matching engine](https://github.com/elliottech/lighter-prover/blob/d0ff2304aea516b22f3a5223881006b6a9af1cc9/circuit/src/matching_engine.rs)."
},
{
"title": "ZK Circuits",
"description": "Lighter transition is proven with custom Plonky2 circuits, compiled into ZK Lighter Verifier and Desert Verifier. ZK Lighter verifier implements the perp DEX and spot trading logic and could be found in this [prover repo](https://github.com/elliottech/lighter-prover/tree/main/circuit/src). Desert verifier consists of circuits proving valid L2 -> L1 withdrawals in the desert mode. More details in [ZK Catalog](https://l2beat.com/zk-catalog/lighterprover#proof-system)."
},
{
"title": "Verification Keys Generation",
"description": "Lighter wraps its validity proof into a Plonk-based proof system which requires a trusted setup. The verification keys are hardcoded in the verifier contract on-chain. Lighter prover repo contains a [script](https://github.com/elliottech/lighter-prover/blob/main/build_circuits.sh) that regenerates circuits and verification keys.",
"references": [
{
"title": "ZK Lighter verifier verification keys",
"url": "https://etherscan.io/address/0xb20De28D78b63bc0c94eef89Db53F6338af17825#code#F1#L54"
},
{
"title": "Desert verifier verification keys",
"url": "https://etherscan.io/address/0xd4460475F00307845082d3a146f36661354FBc67#code#F1#L39"
}
]
}
]
},
"upgradesAndGovernance": "Regular upgrades are initiated by the \"network governor\" and executed with a 21d delay. The \"security council\" is allowed to reduce the upgrade delay to zero in case of an emergency. The security council does not currently satisfy the Stage 1 requirements. The network governor also retains the ability to add or remove validators.",
"warning": "Jan 5 2026: at the moment of writing, the desert mode circuits source code is not publicly available and therefore it is not possible to fully verify the escape hatch logic."
"warning": "Apr 9 2026: the desert mode circuit source code is not publicly available, and L2BEAT research found that full state reconstruction from L1 data alone is not currently feasible. A prover migration (gnark → plonky2) occurred at block 23,711,820 without publishing a state snapshot, leaving pre-migration accounts unreconstructable. Users cannot exit without operator cooperation."
}