{
"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.",
"risks": [],
"references": []
}
],
"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.",
"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/0x7ddad28962571f77fe5e9cb2fe74a896300eeed4#code#F1#L41"
"url": "https://etherscan.io/address/0x05f8176860955d94f974db0ce8bb4f160ae425a2#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."
}
{
"creator": "Lighter",
"projectsForTvs": [
{
"projectId": "lighter",
"sinceTimestamp": 1759356000
}
],
"proofSystemInfo": "\n## Description\n\nLighter prover is a zk proving system for Lighter L2 based on [Plonky2](https://github.com/0xPolygonZero/plonky2/tree/main) circuits. It verifies the logic for regular state transition of Lighter L2, as well as state transitions in the “desert mode” when L2 is shut down and users exit, using different sets of circuits. The circuits are proven with a STARK which is wrapped into a Plonk SNARK before settling onchain.\n\n## Proof system\n\n[Plonky2](https://github.com/0xPolygonZero/plonky2) implements a circuit aritmetization based on TurboPlonk over Goldilocks field, but it replaces KZG polynomial commitment scheme with a FRI-based polynomial testing scheme. In this way proving Plonky2 circuits requires no trusted setup, i.e. it is a STARK. \n\nHowever Lighter wraps these STARK in a [gnark](https://github.com/Consensys/gnark) implementation of Plonk over BN254 curve, which requires a trusted setup.\n\n### Circuits\n\nThe proof system operates on Lighter STF circuits and desert mode circuits. All published circuits are available [here](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit), note that the Lighter team has not published the desert circuits yet. \n\nLighter proof system defines circuits for proving all transactions, including internal, L1 and L2 transactions. The full list of available transactions that define Lighter STF can be seen [here](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/transactions). \n\nTransaction circuits use custom implementations for arithmetic operations ([bigint](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/bigint), [uint](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/uint)), cryptographic primitives ([ecdsa](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/ecdsa) on the Secp256k1 curve, [eddsa](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/eddsa) on the ECgFp5 curve, [keccak](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/keccak), [poseidon_bn128](https://github.com/elliottech/lighter-prover/tree/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/poseidon_bn128)) and other helper circuits.\n\n### Recursion\n\nLighter prover implements recursive aggregation of transaction proofs to make the whole pipeline more efficient and parallelizable. First, fixed-size blocks of consecutive transactions are processed and proven by [BlockTx circuit](https://github.com/elliottech/lighter-prover/blob/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/block_tx_constraints.rs), which can be done on separate machines. Next, arbitrary number of BlockTx proofs are aggregated into a single proof by [BlockTxChain circuit](https://github.com/elliottech/lighter-prover/blob/053ceda7c59a9a0e05997661ca5a1bb7a92bb267/circuit/src/block_tx_chain_constraints.rs), which includes continuity checks across all BlockTx proofs.\n",
"techStack": {
"snark": [
{
"id": "Plonky2",
"type": "Plonk",
"name": "Plonky2",
"description": "Toolkit for developing transparent SNARKs based on PLONK and FRI developed by Polygon Zero team."
},
{
"id": "Goldilocks",
"type": "Field",
"name": "Goldilocks",
"description": "Prime field of order p = 2**64 - 2**32 + 1."
},
{
"id": "CustomCircuits",
"type": "Other",
"name": "App-specific circuits",
"description": "This project uses custom app-specific ZK circuits."
}
],
"finalWrap": [
{
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"risk": "green",
"shortDescription": "Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.",
"longDescription": " \n Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \n It included 176 participants and was publicly open for participation.\n \n - Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n - Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n - Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition).\n "
}
],
"verifierHashes": [
{
"hash": "0x4a5c9d5981ae8f323f0ce7f93733b6b1b66e502e035768a8f3e4f1a23a287338",
"hash": "0x9e4384e13903411340a32aba01d77482c0d2d7b8ae91ef4fcc8725db2a85683b",
"proofSystem": {
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
"knownDeployments": [
{
"address": "0x7ddAD28962571F77fE5E9cB2fE74A896300EEed4",
"address": "0x05F8176860955D94F974dB0CE8BB4F160AE425a2",
"chain": "ethereum"
}
],
"verificationStatus": "notVerified",
"description": "Custom verifier ID: SHA256 hash of all VK_... values from the smart contract, abi packed in the same order they are defined."
},
{
"hash": "0xc3d58029fabf2a93d6cb9b96315c484e4bea2e238aaa081460c9027863c650e7",
"proofSystem": {
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
"knownDeployments": [
{
"address": "0xd4460475F00307845082d3a146f36661354FBc67",
"chain": "ethereum"
}
],
"verificationStatus": "notVerified",
"description": "Custom verifier ID: SHA256 hash of all VK_... values from the smart contract, abi packed in the same order they are defined."
}
]
}