{
"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"
}
]
}
],
"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": "Oct 8 2025: at the moment of writing, the circuits source code is not publicly available and therefore it is not possible to fully verify the business logic of the protocol. The team communicated to us that they plan to release them in the next 1-2 weeks."
"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."
}