Search
Search for projects by name or address
Lighter
There are impactful changes and part of the information might be outdated.
Badges
About
Lighter is an application-specific zk rollup on a mission to revolutionize trading by building provably fair, secure, and scalable infrastructure for finance.
- 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.
Badges
About
Lighter is an application-specific zk rollup on a mission to revolutionize trading by building provably fair, secure, and scalable infrastructure for finance.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to; previously it posted toEthereum.
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
Last 30 day anomalies
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No Proof submissions were performed for 2h 1m (from 2026 Sep 20, 11:21 UTC until 2026 Sep 20, 13:22 UTC). These typically occur every 3m 44s on average.
No Tx data submissions were performed for 2h 11m (from 2026 Sep 20, 11:08 UTC until 2026 Sep 20, 13:20 UTC). These typically occur every 3m 43s on average.
No Proof submissions were performed for 1h 49m (from 2026 Sep 13, 11:18 UTC until 2026 Sep 13, 13:08 UTC). These typically occur every 3m 44s on average.
No Tx data submissions were performed for 1h 54m (from 2026 Sep 13, 11:12 UTC until 2026 Sep 13, 13:06 UTC). These typically occur every 3m 43s on average.
No State updates were performed for 4h 9m (from 2026 Sep 08, 16:41 UTC until 2026 Sep 08, 20:51 UTC). These typically occur every 6m 49s on average.
Lighter experiences 4.5h of downtime
2025 Oct 10th
Lighter experiences 4.5 hours of downtime due to DB growth issues.
Lighter launches public mainnet
2025 Oct 2nd
Lighter launches public mainnet after 8 months of private beta.
Funds can be stolen if
Funds can be lost if
MEV can be extracted if
Users can force the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. to include a transaction by submitting a request through L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. If the sequencer censors or is down for for more than 14d, users can use the exit hatch to withdraw their funds.
SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
All of the data (SD = state diffs) needed for proof construction is published onchain.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Users are able to trustlessly exit by submitting a zero knowledge proof of funds.
Data published onchain
Account delta data is published onchain as blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. A proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. migration (gnark/MIMC → plonky2/Poseidon2) at blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. 23,711,820 left pre-migration blobs undecodable, but Lighter published a full state snapshot at batch #166859 (blobs.zip) that closes the gap. L2BEAT reproduced the snapshot state rootA cryptographic hash succinctly representing a state using a Merkle tree. from blobs and verified the roll-forward to chain head, confirming the live state is reconstructable from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..
- Lighter Prover v0.0.1 (first public release, Dec 2025)
- StateRootUpdate event — gnark to plonky2 migration
- Desert exit circuit + state snapshot (blobs.zip)
EthereumEach 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 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups., 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.
This repo contains the circuits and proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. code for both normal and desert operation mode of Lighter. It includes the logic to generate and verify proofs of valid state transition according to the Lighter matching engine.
Lighter transition is proven with custom Plonky2 circuits, compiled into ZK Lighter VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. and Desert Verifier. ZK Lighter verifier implements the perp DEX and spot trading logic and could be found in this prover repo. Desert verifier consists of circuits proving valid L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. -> L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. withdrawals in the desert mode. More details in ZK Catalog.
Lighter wraps its validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed. into a PlonkA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup.-based proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. which requires a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits.. The verification keys are hardcoded in the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract on-chain. Lighter proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. repo contains a script that regenerates circuits and verification keys.
Trusted Setups
Onchain verifier
Used in
Onchain verifier | Used in |
Regular upgrades are initiated by the “networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor” and executed with a 21d delay. The “security councilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.” 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 validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier.
2026 September 15, 09:31 UTCHigh severity17changesNew verifier deployed (no sources published yet). Upgraded the main contract: https://disco.l2beat.com/diff/eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e/eth:0xb9B30C7Ac4eCBf756bc68D7b12c842E415A9cA8e. Added functionality to conveniently change pubkey for master account, minor refactoring.
New verifier deployed (no sources published yet). Upgraded the main contract: https://disco.l2beat.com/diff/eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e/eth:0xb9B30C7Ac4eCBf756bc68D7b12c842E415A9cA8e. Added functionality to conveniently change pubkey for master account, minor refactoring.
| contract Lighter (eth:0x3B4D794a66304F130a4Db8F2551B0070dfCf5ca7) [lighter/ZkLighterWithSpot] { | |
| +++ description: The main rollup contract. It processes L2 batches, manages token deposits and withdrawals, allows users to submit censorship-resistant L2 transactions and controls desert mode (escape hatch). Logic is split between two contracts because of code-size limits, many operations are delegated to AdditionalZKLighter. | |
| sourceHashes.1: | |
| - | "0xb4dce2f15590894c57a91457428ad19b912efa03f6198f09e308f82518d33234" |
| + | "0x2c7c54c7dbae18fe5dd08d3aa5ccf1890e97148735d1d4a7768fe8fe9a67d6a3" |
| values.$implementation.0: | |
| - | "eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e" |
| + | "eth:0xb9B30C7Ac4eCBf756bc68D7b12c842E415A9cA8e" |
| values.$implementation.1: | |
| - | "eth:0xaA5e1aaa81a39F828248ffFeaDC77CcEC8eC3906" |
| + | "eth:0x1b2Fd2341cdC9d4F00CE5488A0db172d8C8a98E4" |
| values.additionalZkLighter: | |
| - | "eth:0xaA5e1aaa81a39F828248ffFeaDC77CcEC8eC3906" |
| + | "eth:0x1b2Fd2341cdC9d4F00CE5488A0db172d8C8a98E4" |
| values.getTarget: | |
| - | "eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e" |
| + | "eth:0xb9B30C7Ac4eCBf756bc68D7b12c842E415A9cA8e" |
| values.MAX_PUBLIC_MARKET_INDEX: | |
| + | 281474976710655 |
| values.NIL_PUBLIC_MARKET_INDEX: | |
| + | 255 |
| implementationNames.eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e: | |
| - | "ZkLighter" |
| implementationNames.eth:0xaA5e1aaa81a39F828248ffFeaDC77CcEC8eC3906: | |
| - | "AdditionalZkLighter" |
| implementationNames.eth:0xb9B30C7Ac4eCBf756bc68D7b12c842E415A9cA8e: | |
| + | "ZkLighter" |
| implementationNames.eth:0x1b2Fd2341cdC9d4F00CE5488A0db172d8C8a98E4: | |
| + | "AdditionalZkLighter" |
| } | |
| contract UpgradeGatekeeper (eth:0x94da8A995D0D82Ef0fE7E509C6D76c22603B6f67) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by eth:0x92b12c9d85BF7bd2EF5d2F53F4cd4Ce0BE432045. | |
| values.versionId: | |
| - | 69 |
| + | 71 |
| } | |
| contract ZkLighterVerifier (eth:0xac3Ce44B6ff4E402858C99D5699ff63131572BaA) [lighter/ZkLighterVerifier] { | |
| +++ description: The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation. | |
| sourceHashes.1: | |
| - | "0xd6bd16e71487e79b2b73fdcd4ac6274826c2eea864e60a68d0527898b6aa449e" |
| + | "0xb7e4318fc7163594c3382febfcafc104afdbd2e77905ca0c7b2d26c8ff527538" |
| values.$implementation: | |
| - | "eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A" |
| + | "eth:0x21B036c441C2E3aeD710526189Cd6F5b3151AfbE" |
| values.getTarget: | |
| - | "eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A" |
| + | "eth:0x21B036c441C2E3aeD710526189Cd6F5b3151AfbE" |
| implementationNames.eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A: | |
| - | "ZkLighterVerifier" |
| implementationNames.eth:0x21B036c441C2E3aeD710526189Cd6F5b3151AfbE: | |
| + | "ZkLighterVerifier" |
| } | |
2026 September 10, 12:07 UTCHigh severity6changesNew verifier deployed (no sources published yet).
New verifier deployed (no sources published yet).
| contract UpgradeGatekeeper (eth:0x94da8A995D0D82Ef0fE7E509C6D76c22603B6f67) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by eth:0x92b12c9d85BF7bd2EF5d2F53F4cd4Ce0BE432045. | |
| values.versionId: | |
| - | 68 |
| + | 69 |
| } | |
| contract ZkLighterVerifier (eth:0xac3Ce44B6ff4E402858C99D5699ff63131572BaA) [lighter/ZkLighterVerifier] { | |
| +++ description: The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation. | |
| sourceHashes.1: | |
| - | "0x6a9f25dcb10a9155c210780fa3cb38f68ba814f2a1c593ce45855a2ad56d10b1" |
| + | "0xd6bd16e71487e79b2b73fdcd4ac6274826c2eea864e60a68d0527898b6aa449e" |
| values.$implementation: | |
| - | "eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C" |
| + | "eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A" |
| values.getTarget: | |
| - | "eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C" |
| + | "eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A" |
| implementationNames.eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C: | |
| - | "ZkLighterVerifier" |
| implementationNames.eth:0x4E6505D3AE8Aa910e5d35557c76F567077622a6A: | |
| + | "ZkLighterVerifier" |
| } | |
2026 September 03, 10:44 UTCHigh severity9changesNew verifier deployed (no sources published yet). Also, 7702 EOA delegation.
New verifier deployed (no sources published yet). Also, 7702 EOA delegation.
| EOA (eth:0x06eD0b0bD3A9e0C517B6cD7C8B851Cc1e8e1a90A) { | |
| +++ description: None | |
| proxyType: | |
| - | "EOA" |
| + | "EIP7702 EOA" |
| sourceHashes: | |
| + | ["0x1f44812af62d28f019e30e8eb2af596fb36c7db9d34576972c0405e110a6ef45"] |
| values: | |
| + | {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0x06eD0b0bD3A9e0C517B6cD7C8B851Cc1e8e1a90A","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0x0d8be483cc5fa59dfb77bb3b3858ff01fb2ff458dc1e441e34f79ecc6c95858a","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"} |
| } | |
| contract UpgradeGatekeeper (eth:0x94da8A995D0D82Ef0fE7E509C6D76c22603B6f67) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by eth:0x92b12c9d85BF7bd2EF5d2F53F4cd4Ce0BE432045. | |
| values.versionId: | |
| - | 67 |
| + | 68 |
| } | |
| contract ZkLighterVerifier (eth:0xac3Ce44B6ff4E402858C99D5699ff63131572BaA) [lighter/ZkLighterVerifier] { | |
| +++ description: The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation. | |
| sourceHashes.1: | |
| - | "0x2bdf2a91d1eee5475a67f9eacc65aa114fe720836d91f4ec076ef9e1e19c9675" |
| + | "0x6a9f25dcb10a9155c210780fa3cb38f68ba814f2a1c593ce45855a2ad56d10b1" |
| values.$implementation: | |
| - | "eth:0xB1386c4266974D81256afB9908e104B00587112A" |
| + | "eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C" |
| values.getTarget: | |
| - | "eth:0xB1386c4266974D81256afB9908e104B00587112A" |
| + | "eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C" |
| implementationNames.eth:0xB1386c4266974D81256afB9908e104B00587112A: | |
| - | "ZkLighterVerifier" |
| implementationNames.eth:0xA437933830d65a61F8Beaa7D4C65f424bBe90b4C: | |
| + | "ZkLighterVerifier" |
| } | |
2026 August 26, 09:55 UTCHigh severity6changesNew verifier deployed (no sources published yet).
New verifier deployed (no sources published yet).
| contract UpgradeGatekeeper (eth:0x94da8A995D0D82Ef0fE7E509C6D76c22603B6f67) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by eth:0x92b12c9d85BF7bd2EF5d2F53F4cd4Ce0BE432045. | |
| values.versionId: | |
| - | 66 |
| + | 67 |
| } | |
| contract ZkLighterVerifier (eth:0xac3Ce44B6ff4E402858C99D5699ff63131572BaA) [lighter/ZkLighterVerifier] { | |
| +++ description: The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation. | |
| sourceHashes.1: | |
| - | "0xb74e656664c529e0a1c04288f9e2e470923d276a463dcdb7e85e47c2c95336c8" |
| + | "0x2bdf2a91d1eee5475a67f9eacc65aa114fe720836d91f4ec076ef9e1e19c9675" |
| values.$implementation: | |
| - | "eth:0x9Ca512d2F131134972EB95515325F69812395332" |
| + | "eth:0xB1386c4266974D81256afB9908e104B00587112A" |
| values.getTarget: | |
| - | "eth:0x9Ca512d2F131134972EB95515325F69812395332" |
| + | "eth:0xB1386c4266974D81256afB9908e104B00587112A" |
| implementationNames.eth:0x9Ca512d2F131134972EB95515325F69812395332: | |
| - | "ZkLighterVerifier" |
| implementationNames.eth:0xB1386c4266974D81256afB9908e104B00587112A: | |
| + | "ZkLighterVerifier" |
| } | |
2026 August 24, 11:17 UTCHigh severity6changesNew verifier deployed (no sources published yet).
New verifier deployed (no sources published yet).
| contract UpgradeGatekeeper (eth:0x94da8A995D0D82Ef0fE7E509C6D76c22603B6f67) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by eth:0x92b12c9d85BF7bd2EF5d2F53F4cd4Ce0BE432045. | |
| values.versionId: | |
| - | 64 |
| + | 66 |
| } | |
| contract ZkLighterVerifier (eth:0xac3Ce44B6ff4E402858C99D5699ff63131572BaA) [lighter/ZkLighterVerifier] { | |
| +++ description: The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation. | |
| sourceHashes.1: | |
| - | "0x3bf884449870657809fb4cf5310746aa4313a80425fbc69bfc45706017c63607" |
| + | "0xb74e656664c529e0a1c04288f9e2e470923d276a463dcdb7e85e47c2c95336c8" |
| values.$implementation: | |
| - | "eth:0xf7b964eD0C05a7aA12fdC54865295531C9D2AEC1" |
| + | "eth:0x9Ca512d2F131134972EB95515325F69812395332" |
| values.getTarget: | |
| - | "eth:0xf7b964eD0C05a7aA12fdC54865295531C9D2AEC1" |
| + | "eth:0x9Ca512d2F131134972EB95515325F69812395332" |
| implementationNames.eth:0xf7b964eD0C05a7aA12fdC54865295531C9D2AEC1: | |
| - | "ZkLighterVerifier" |
| implementationNames.eth:0x9Ca512d2F131134972EB95515325F69812395332: | |
| + | "ZkLighterVerifier" |
| } | |
Centralized operators
Only the centralized operators can submit batches and verify them with a ZK proof, i.e. advance the state of the protocol.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force their transactions on L1
If the centralized operators fail to include user transactions, users can force them themselves through L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. 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.
Regular exit
The user initiates the withdrawal by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled the funds become available for withdrawal on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. ZK proofs are required to settle blocks. Finally the user submits an L1 transaction to claim the funds.
Escape hatch through ZK proofs
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. The desert exit circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. and a full state snapshot at batch #166859 are public, and the deployed DesertVerifier matches a rebuild from that circuit. L2BEAT reproduced the snapshot state rootA cryptographic hash succinctly representing a state using a Merkle tree. from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. and verified the roll-forward to chain head.
External oracles used for index prices
Lighter uses a combination of oracles to determine index prices, with Stork as the primary source. External signatures are currently not verified and the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. must be trusted to truthfully report data.
Funds can be lost if the oracle prices are manipulated.
Ethereum
Actors:
A Multisig with 4/7 threshold.
- Can interact with UpgradeGatekeeper
- can reduce the upgrade delay to zero seconds
A Multisig with 3/5 threshold.
- Can upgrade with 21d delay
- Lighter UpgradeGatekeeper with 21d delay
- Governance UpgradeGatekeeper with 21d delay
- ZkLighterVerifier UpgradeGatekeeper with 21d delay
- Can interact with Governance
- manage validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier, update the address that manages the insurance fund, update the treasury address that collects fees from markets, add and update markets and assets
A Multisig with 3/5 threshold.
Ethereum
Verifies the zk proofs that let users exit their funds directly on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. while the system is in desert mode (escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1.).
Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by Lighter Multisig. In practice every upgrade so far has been fast-tracked: the security councilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. zeroes the notice period right before each upgrade is finished.
- Roles:
- getMaster: Lighter Multisig 2
- securityCouncilAddress: Lighter Multisig
Manages the list of validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor.
- Roles:
- admin: UpgradeGatekeeper; ultimately Lighter Multisig 2
- networkGovernor: Lighter Multisig 2
- validators: EOA 1, EOA 2, EOA 3
The main rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. contract. It processes L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. batches, manages token deposits and withdrawals, allows users to submit censorship-resistant L2 transactions and controls desert mode (escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1.). Logic is split between two contracts because of code-size limits, many operations are delegated to AdditionalZKLighter.
- Roles:
- admin: UpgradeGatekeeper; ultimately Lighter Multisig 2
The main ZK verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of Lighter, settles the proofs of correct L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. state transition in the case of normal rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. operation.
- Roles:
- admin: UpgradeGatekeeper; ultimately Lighter Multisig 2
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
Lighter