Search

Search for projects by name or address

Lighter on Robinhood logo
Lighter on Robinhood

Badges

About

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.


  • Total Value SecuredTVS
    $97.15 M11.3%
  • Past day UOPSDaily UOPS
    No data
  • Type
    Other
  • Purpose
    Exchange

  • Host chain
    Robinhood Chain

  • Tokens breakdown

    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    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.

    Why is the project listed in others?

    There are less than 5 external actors that can submit challenges

    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.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    Compare with other projects

    Robinhood launches Lighter perpetuals integration

    2026 Jul 1st

    Robinhood announces Lighter perpetual futures in Robinhood Wallet on public mainnet.

    Learn more

    Lighter contracts deployed on Robinhood Chain

    2026 Jun 26th

    The USDG-based Lighter fork is deployed on Robinhood Chain.

    Learn more
    The L3 risks depend on the individual properties of L3 and those of the host chain combined.
    SEQUENCER
    FAILURE
    STATE
    VALIDATION
    DATA
    AVAILABILITY
    EXIT WINDOWPROPOSER
    FAILURE
    Robinhood Chain
    L2
    No mechanismFraud proofs (INT)OnchainNoneSelf propose
    Lighter on Robinhood
    L3 • Individual
    Force via L1Validity proofs (SN)Onchain (SD)NoneUse escape hatch
    Lighter on Robinhood
    L3 • Combined
    No mechanismFraud proofs (INT)OnchainNoneUse escape hatch
    L2 & L3 individual risks
    Sequencer failureState validationData availabilityExit windowProposer failure
    L3 combined risks
    Sequencer failureState validationData availabilityExit windowProposer failure

    L3 combined risks
    The information below reflects combined L2 & L3 risks.
    Sequencer failure
    No mechanism

    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.

    State validation
    Fraud proofs (INT)

    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..

    Data availability
    Onchain

    All of the data needed for proof construction is published on the base chain, which ultimately gets published on Ethereum.

    Exit window
    None

    There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

    Proposer failure
    Use escape hatch

    Users are able to trustlessly exit by submitting a zero knowledge proof of funds.

    Lighter on Robinhood
    Lighter on Robinhood is not even a
    Stage 0
    Appchain
    project.
    There is no available nodeA software client that participates in the network. software that can reconstruct the state 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. data, hence there is no way to verify that this system is a 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..

    Learn more about Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

    State differences posted on Robinhood Chain

    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.

    1. Example commitBatch transaction on Robinhood Chain
    2. Robinhood Chain architecture documentation
    Learn more about the DA layer here: Robinhood Chain logoRobinhood Chain

    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.


    Verification Keys Generation

    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.

    1. ZK Lighter verifier verification keys
    Validity proofs

    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.

    1. Deployed DesertVerifier implementation
    PROVER

    Trusted Setups

    Used in

    Lighter logoLighter on Robinhood logo

    Used in

    Lighter logoLighter on Robinhood logo
    2026 September 18, 10:17 UTC
    High severity
    8changes

    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"
    }
    2026 August 24, 11:23 UTC
    High severity
    15changes

    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"
    }
    2026 August 19, 10:52 UTC
    3changes

    Verified all contracts and removed spam.

    New and verified contracts

    contract Lighter (robinhood:0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d) [N/A] {
    +++ description: None
    unverified:
    - true
    implementationNames.robinhood:0x1be72833f96e47366610CCFb9Bec081FE69EECf5:
    - ""
    + "AdditionalZkLighter"
    sourceHashes:
    + ["0x317a8c60bf36af0b293fad7aaf9ae5d178a0c2ea316b493b5c8b962d4daea6f6","0x7ce2f744c6d607ee57b68b69025659533ae352619bab2cea5c26e5cc9175d95d"]
    }
    2026 August 13, 10:10 UTC
    High severity
    10changes

    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
    2026 August 03, 14:31 UTC
    3changes

    Verified the source code of desert verifier. It is equivalent to the one in Lighter deployment on Ethereum.

    New and verified contracts

    contract DesertVerifier (robinhood:0x56aeED6920DBB9E198C2C0072147A45684A06E10) [N/A] {
    +++ description: None
    unverified:
    - true
    implementationNames.robinhood:0x56aeED6920DBB9E198C2C0072147A45684A06E10:
    - ""
    + "DesertVerifier"
    sourceHashes:
    + ["0xcedbddf6ef097d451ba200328780c0cc492b65383f8dc44e760ec70eee4f8850"]
    }
    The section considers only the L3 properties. For more details please refer to Robinhood Chain logoRobinhood Chain

    Centralized operators

    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.

    Priority requests can be submitted on Robinhood Chain

    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.

    1. Lighter contract on Robinhood Chain
    The section considers only the L3 properties. For more details please refer to Robinhood Chain logoRobinhood Chain

    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.

    1. Deployed DesertVerifier on Robinhood Chain

    USDG is the quote and margin asset

    Unlike the Ethereum deployment, this fork uses Global Dollar (USDG) instead of USDC as the quote and margin asset.

    1. Robinhood Chain token contracts
    2. Robinhood Wallet perpetual futures documentation

    External oracles used for index prices

    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.

    1. Lighter docs - Fair Price Marking
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Robinhood Chain

    Actors:

    A Multisig with 3/5 threshold.

    • Can upgrade with 21d delay
      • Lighter
      • ZkLighterVerifier
      • Governance
    • 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
    • Can interact with Governance
      • can commit, verify, execute batches, and revert committed but not yet executed batches
    Lighter Security Council0x4972…eFDb
    • Can interact with UpgradeGatekeeper
      • can reduce the upgrade delay to zero seconds
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Robinhood Chain

    UpgradeGatekeeper0x43Cf…2716

    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.

    DesertVerifier0x56ae…6E10

    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.).

    • Roles:
      • admin: UpgradeGatekeeper; ultimately SafeL2 The source code of this contract is not verified on Etherscan.
    The following tokens are included in the value secured calculation:
    ETH token logoUSDG token logoAAPL token logoAMZN token logoGOOGL token logoMETA token logoMSFT token logoNVDA token logoTSLA token logoORCL token logoSPCX token logoBABA token logoUSAR token logoUSO token logoCOIN token logoCRCL token logoQQQ token logoSPY token logoSGOV token logoSLV token logoAMD token logoINTC token logoMU token logoSNDK token logoCRWV token logoPLTR token logo
    Can be upgraded by:
    • Roles:
      • admin: UpgradeGatekeeper; ultimately SafeL2
    Can be upgraded by:

    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.

    Can be upgraded by:

    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).