Search for projects by name or address
Lighter on Robinhood is an application-specific ZK rollup deployed on Robinhood Chain. It is a fork of Lighter adapted to use Global Dollar (USDG) as its quote and margin asset.
Lighter on Robinhood is an application-specific ZK rollup deployed on Robinhood Chain. It is a fork of Lighter adapted to use Global Dollar (USDG) as its quote and margin asset.
Consequence: projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds.
Learn more about the recategorisation here.
Robinhood launches Lighter perpetuals integration
2026 Jul 1st
Robinhood announces Lighter perpetual futures in Robinhood Wallet on public mainnet.
Lighter contracts deployed on Robinhood Chain
2026 Jun 26th
The USDG-based Lighter fork is deployed on Robinhood Chain.
| SEQUENCER FAILURE | STATE VALIDATION | DATA AVAILABILITY | EXIT WINDOW | PROPOSER FAILURE | |
| Robinhood Chain L2 | No mechanism | Fraud proofs (INT) | Onchain | None | Self propose |
| Lighter on Robinhood L3 • Individual | Force via L1 | Validity proofs (SN) | Onchain (SD) | None | Use escape hatch |
| Lighter on Robinhood L3 • Combined | No mechanism | Fraud proofs (INT) | Onchain | None | Use escape hatch |
There is no guaranteed mechanism to have transactions included if 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. is down or censoring. Although users can enqueue messages in the 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. delayed inbox and call forceInclusion on the SequencerInbox, the chain runs ArbOS 61 transaction filtering: an authorized filterer can register any transaction hashA fixed-length fingerprint of variable-size input, produced by a hash function. in the ArbFilteredTransactionsManager precompile (0x00…0074), after which the state transition function forcibly fails that transaction, including force-included ones, without delay.
Fraud proofs only allow 2 WHITELISTED actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. The challenge protocol can be subject to delay attacks. There is a 6d 8h challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled..
All of the data needed for proof construction is published on the base chain, which ultimately gets published on Ethereum.
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.
The state differences required to reconstruct and prove the Lighter state are included directly in commitBatch calldata on Robinhood Chain. Unlike the Ethereum deployment, the Lighter contract does not read EIP-4844 blobThe 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. hashes. Robinhood Chain subsequently batches its own transaction data to Ethereum blobs.
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. These proofs are verified on Robinhood Chain by a smart contract. In desert mode, users can provide proofs of their balances to exit, which is validate by the DesertVerifier.
Lighter uses 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. The 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. repository contains a script that regenerates circuits and verification keys, but it does not reproduce the verification keys used by this deployment.
State updates are verified by the ZkLighterVerifier contract. Desert verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.
Onchain verifier
Onchain verifier |
Upgraded lighter verifier on robinhood. The new version is not yet reproduced from the sources. The .sol sources were missing from the blockscout and sourcify, I reconstructed and submitted them.
Upgraded lighter verifier on robinhood. The new version is not yet reproduced from the sources. The .sol sources were missing from the blockscout and sourcify, I reconstructed and submitted them.
| contract UpgradeGatekeeper (robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by robinhood:0x4972E0CaCb2AC45644BA054838e96fF4f6f7eFDb. | |
| values.versionId: | |
| - | 5 |
| + | 6 |
| } | |
| contract ZkLighterVerifier (robinhood:0xe1aFBE2D670eFF0e7C8A41F080792C011916ac31) [N/A] { | |
| +++ description: None | |
| template: | |
| - | "lighter/ZkLighterVerifier" |
| sourceHashes.1: | |
| - | "0xe9918698c11cc35630c3cd99d564142087c3968ded02116451208d19007b069a" |
| + | "0xa54f86e01624213bae74fb0e5155537807b948cb043a804c3b2acb905aa631d1" |
| description: | |
| - | "The main ZK verifier of Lighter, settles the proofs of correct L2 state transition in the case of normal rollup operation." |
| values.$implementation: | |
| - | "robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa" |
| + | "robinhood:0xCBF92533F5816c6Ee0e4250F4E138b3f49962EF2" |
| values.getTarget: | |
| - | "robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa" |
| + | "robinhood:0xCBF92533F5816c6Ee0e4250F4E138b3f49962EF2" |
| implementationNames.robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa: | |
| - | "ZkLighterVerifier" |
| implementationNames.robinhood:0xCBF92533F5816c6Ee0e4250F4E138b3f49962EF2: | |
| + | "ZkLighterVerifier" |
| } | |
New verifier deployed (no sources published yet). Also, upgraded Lighter contract to add PricedOnly asset margin mode (the same diff as this Lighter upgrade: https://disco.l2beat.com/diff/eth:0xE67606837D3d68a679B25B49b8abE5cB4B0Ae483/eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e).
New verifier deployed (no sources published yet).
Also, upgraded Lighter contract to add PricedOnly asset margin mode (the same diff as this Lighter upgrade: https://disco.l2beat.com/diff/eth:0xE67606837D3d68a679B25B49b8abE5cB4B0Ae483/eth:0x8D692294a4824d868e35B3CEcd734aCf41B2342e).
| contract UpgradeGatekeeper (robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by robinhood:0x4972E0CaCb2AC45644BA054838e96fF4f6f7eFDb. | |
| values.versionId: | |
| - | 4 |
| + | 5 |
| } | |
| contract Lighter (robinhood:0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d) [N/A] { | |
| +++ description: None | |
| sourceHashes.1: | |
| - | "0x7ce2f744c6d607ee57b68b69025659533ae352619bab2cea5c26e5cc9175d95d" |
| + | "0x3a35ceb50e1870902c0afbda8de806932d6a7168c2e27af00ca755fc5db60b93" |
| values.$implementation.0: | |
| - | "robinhood:0xE470e41Cacc197EA07f879577765A8c81234ED7B" |
| + | "robinhood:0x82DE5B1161C93afDFE21bA0D5343f01Cd7401d90" |
| values.$implementation.1: | |
| - | "robinhood:0x1be72833f96e47366610CCFb9Bec081FE69EECf5" |
| + | "robinhood:0xDa2B59fFB41485a6f21E14e479AE7B7AB29a997c" |
| values.additionalZkLighter: | |
| - | "robinhood:0x1be72833f96e47366610CCFb9Bec081FE69EECf5" |
| + | "robinhood:0xDa2B59fFB41485a6f21E14e479AE7B7AB29a997c" |
| values.getTarget: | |
| - | "robinhood:0xE470e41Cacc197EA07f879577765A8c81234ED7B" |
| + | "robinhood:0x82DE5B1161C93afDFE21bA0D5343f01Cd7401d90" |
| implementationNames.robinhood:0xE470e41Cacc197EA07f879577765A8c81234ED7B: | |
| - | "ZkLighter" |
| implementationNames.robinhood:0x1be72833f96e47366610CCFb9Bec081FE69EECf5: | |
| - | "AdditionalZkLighter" |
| implementationNames.robinhood:0x82DE5B1161C93afDFE21bA0D5343f01Cd7401d90: | |
| + | "ZkLighter" |
| implementationNames.robinhood:0xDa2B59fFB41485a6f21E14e479AE7B7AB29a997c: | |
| + | "AdditionalZkLighter" |
| } | |
| contract ZkLighterVerifier (robinhood:0xe1aFBE2D670eFF0e7C8A41F080792C011916ac31) [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: | |
| - | "0x59e0ec2f0ddd3e5e201753df9c0d5acf7b63eaeffcef7037e926b825152d4278" |
| + | "0xe9918698c11cc35630c3cd99d564142087c3968ded02116451208d19007b069a" |
| values.$implementation: | |
| - | "robinhood:0xA3c70B197AcE329D9e09C753DA7874B78F1D00f4" |
| + | "robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa" |
| values.getTarget: | |
| - | "robinhood:0xA3c70B197AcE329D9e09C753DA7874B78F1D00f4" |
| + | "robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa" |
| implementationNames.robinhood:0xA3c70B197AcE329D9e09C753DA7874B78F1D00f4: | |
| - | "ZkLighterVerifier" |
| implementationNames.robinhood:0x61CA82e45F5a57d00E66b522Be72D8bA41e634Aa: | |
| + | "ZkLighterVerifier" |
| } | |
Verified all contracts and removed spam.
Verified all contracts and removed spam.
| contract Lighter (robinhood:0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d) [N/A] { | |
| +++ description: None | |
| unverified: | |
| - | true |
| implementationNames.robinhood:0x1be72833f96e47366610CCFb9Bec081FE69EECf5: | |
| - | "" |
| + | "AdditionalZkLighter" |
| sourceHashes: | |
| + | ["0x317a8c60bf36af0b293fad7aaf9ae5d178a0c2ea316b493b5c8b962d4daea6f6","0x7ce2f744c6d607ee57b68b69025659533ae352619bab2cea5c26e5cc9175d95d"] |
| } | |
Network governor and upgrade master changed from an EOA to a 3/5 ms (old EOA is one of the members). Also, many lighter contract fields got discovered, probably due to one of the contracts becoming verified.
Network governor and upgrade master changed from an EOA to a 3/5 ms (old EOA is one of the members).
Also, many lighter contract fields got discovered, probably due to one of the contracts becoming verified.
| EOA Lighter Governor (robinhood:0x42cDb51c23D03c69c05Fa691c3B5517Ace876213) { | |
| +++ description: None | |
| receivedPermissions: | |
| - | [{"permission":"interact","from":"robinhood:0xf6F6Bd6eEA2b9A2041328732CcAe4c5e1DD278B7","description":"manage validators, update the address that manages the insurance fund, update the treasury address that collects fees from markets, add and update markets and assets.","role":".networkGovernor"},{"permission":"upgrade","from":"robinhood:0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d","role":"admin","via":[{"address":"robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716","delay":1814400}]},{"permission":"upgrade","from":"robinhood:0xe1aFBE2D670eFF0e7C8A41F080792C011916ac31","role":"admin","via":[{"address":"robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716","delay":1814400}]},{"permission":"upgrade","from":"robinhood:0xf6F6Bd6eEA2b9A2041328732CcAe4c5e1DD278B7","role":"admin","via":[{"address":"robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716","delay":1814400}]}] |
| directlyReceivedPermissions: | |
| - | [{"permission":"act","from":"robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716","delay":1814400,"role":".getMaster"}] |
| eoaWithUpgradePermissions: | |
| - | true |
| } | |
| contract UpgradeGatekeeper (robinhood:0x43CfF77CD060A155dCe5deb12B93b875f69F2716) [lighter/UpgradeGatekeeper] { | |
| +++ description: Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by robinhood:0x4972E0CaCb2AC45644BA054838e96fF4f6f7eFDb. | |
| +++ severity: HIGH | |
| values.getMaster: | |
| - | "robinhood:0x42cDb51c23D03c69c05Fa691c3B5517Ace876213" |
| + | "robinhood:0x8Caf9FF9392F39E87cBC65A130c026caaCD321ef" |
| } | |
| contract Lighter (robinhood:0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d) [N/A] { | |
| +++ description: None | |
| values.lastVerifiedStateRoot: | |
| - | "0x7bb3507766d0a6cf31a2fcc1e3185206f797ce0fac1126dc276e1be5de9a8135" |
| + | "0x0baaad506ee8ac901c9464f0aa869df325e25c5720ebaf12fe0088652a908c88" |
| values.lastVerifiedValidiumRoot: | |
| - | "0x479fc285e15020f8af391a5de57116592c83633d7a7384a93df0261bee1042d7" |
| + | "0x941b1cc85a411f5ce91565555a0778cdd701e5299f2abda7e1dc31353f8dbfc9" |
| values.stateRoot: | |
| - | "0x7bb3507766d0a6cf31a2fcc1e3185206f797ce0fac1126dc276e1be5de9a8135" |
| + | "0x0baaad506ee8ac901c9464f0aa869df325e25c5720ebaf12fe0088652a908c88" |
| values.validiumRoot: | |
| - | "0x479fc285e15020f8af391a5de57116592c83633d7a7384a93df0261bee1042d7" |
| + | "0x941b1cc85a411f5ce91565555a0778cdd701e5299f2abda7e1dc31353f8dbfc9" |
| } | |
| contract Governance (robinhood:0xf6F6Bd6eEA2b9A2041328732CcAe4c5e1DD278B7) [lighter/Governance] { | |
| +++ description: Manages the list of validators and the network governor. | |
| +++ severity: HIGH | |
| values.networkGovernor: | |
| - | "robinhood:0x42cDb51c23D03c69c05Fa691c3B5517Ace876213" |
| + | "robinhood:0x8Caf9FF9392F39E87cBC65A130c026caaCD321ef" |
| } | |
| + | Status: CREATED |
| contract SafeL2 (robinhood:0x8Caf9FF9392F39E87cBC65A130c026caaCD321ef) [GnosisSafe] | |
| +++ description: None | |
Verified the source code of desert verifier. It is equivalent to the one in Lighter deployment on Ethereum.
Verified the source code of desert verifier. It is equivalent to the one in Lighter deployment on Ethereum.
| contract DesertVerifier (robinhood:0x56aeED6920DBB9E198C2C0072147A45684A06E10) [N/A] { | |
| +++ description: None | |
| unverified: | |
| - | true |
| implementationNames.robinhood:0x56aeED6920DBB9E198C2C0072147A45684A06E10: | |
| - | "" |
| + | "DesertVerifier" |
| sourceHashes: | |
| + | ["0xcedbddf6ef097d451ba200328780c0cc492b65383f8dc44e760ec70eee4f8850"] |
| } | |
Only the centralized operators can submit batches and verify them with a ZK proof, i.e. advance the state of the protocol. 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 can 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.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can submit priority requests directly to the Lighter contract on Robinhood Chain. If the operators leave the oldest request unprocessed for more than 14d, anyone can activate desert mode.
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.
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.
Unlike the Ethereum deployment, this fork uses Global Dollar (USDG) instead of USDC as the quote and margin asset.
Lighter uses external oracles to determine index prices. External signatures are not verified by the settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. contract 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.

A Multisig with 3/5 threshold.


Governance contract functioning like an upgrade timelock for downstream contracts. The current delay is 21d and can be entirely skipped by 0x4972E0CaCb2AC45644BA054838e96fF4f6f7eFDb. 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.
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.).


























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.
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).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).