Search

Search for projects by name or address

SummaryValue SecuredActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisStageData availabilityState validationUpgrades & GovernanceUpdatesOperatorSequencingWithdrawalsOther considerationsPermissionsSmart contracts

Robinhood Chain logo
Robinhood Chain

1 recent update

This project is under review.

Badges

About

Robinhood Chain is an Arbitrum Orbit Layer 2 operated by Robinhood, focused on tokenized real-world assets (such as stocks and ETFs) and onchain financial services including 24/7 trading, lending, and borrowing. Robinhood Chain is part of Robinhood's...

  • Total Value SecuredTVS
    $8.77 M>1K%
  • Past day UOPSDaily UOPS
    0.21308%
  • Gas token
    ETH
  • Type
    Other
  • Purposes
    Universal, RWA
  • Chain ID
    4663

    • Tokens breakdown

    Sequencer failureState validationData availabilityExit windowProposer failure
    Explore more in Discovery UI

    Badges

    About

    Robinhood Chain is an Arbitrum Orbit Layer 2 operated by Robinhood, focused on tokenized real-world assets (such as stocks and ETFs) and onchain financial services including 24/7 trading, lending, and borrowing. Robinhood Chain is part of Robinhood's...

    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.

    Value SecuredView TVS breakdown
    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal
    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    View TVS breakdown
    Activity

    2026 Apr 30 — Jul 03

    Past Day UOPS
    0.21308%
    Past Day Ops count
    18.17 K
    Max. UOPS
    0.21
    2026 Jun 17
    Past day UOPS/TPS Ratio
    No data
    Onchain costs

    The section shows the operating costs that L2s pay to Ethereum.

    2026 Apr 30 — Jul 03

    Total cost
    $1.82 K
    Avg cost per L2 UOP
    $0.014459
    Avg cost per day
    $28.58
    Data posted

    This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereum.

    2026 Apr 30 — Jul 03

    Data posted
    721.25 MiB
    Avg size per day
    11.10 MiB
    Avg size per L2 UOP
    5.84 KiB
    Liveness

    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.

    No ongoing anomalies detected

    2026 Jun 03 — Jul 03

    Avg. tx data subs. interval
    14 minutes
    Avg. state updates interval
    32 minutes
    Past 30 days anomalies
    100% normal uptime
    Milestones & Incidents

    Mainnet launch

    2026 Jul 1st

    Robinhood Chain opens to the public, removing the transaction-access whitelist.

    Learn more

    Public testnet launch

    2026 Feb 10th

    Robinhood Chain opens its public testnet.

    Learn more
    Risk summary
    This project includes unverified contracts.
    (CRITICAL)
    Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted.

    Funds can be stolen if

    1. a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
    2. the source code of unverified contracts contains malicious code (CRITICAL),
    3. no whitelisted challenger disputes an invalid state root before the challenge window expires (CRITICAL),
    4. an attacker successfully performs a resource exhaustion attack.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.
    Risk analysis
    This project includes unverified contracts.
    (CRITICAL)
    Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted.
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Self sequence

    In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There can be up to a 4d delay on this operation.

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

    Data availability
    Onchain

    All of the data needed for proof construction is published on Ethereum L1.

    Exit window
    None

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

    Proposer failure
    Self propose

    Anyone can become a Proposer after 28d of inactivity from the currently whitelisted Proposers.

    Stage
    Robinhood Chain
    Robinhood Chain is not even a
    Stage 0
    project.
    The requirement for available node software is under review
    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.
    Data availability

    All data required for proofs is published on chain

    All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.

    1. Sequencing followed by deterministic execution - Arbitrum documentation
    2. SequencerInbox.sol - source code, addSequencerL2BatchFromOrigin function
    Learn more about the DA layer here: Ethereum logoEthereum
    State validation
    A diagram of the state validation
    A diagram of the state validation

    Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.

    State root proposals

    Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as “assertions” within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the stakeOnNewAssertion function. The stake is currently set to 1.0 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without “rivals” can be confirmed after the challenge period has passed, currently set to 6d 8h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.

    • Funds can be stolen if no whitelisted challenger disputes an invalid state root before the challenge window expires (CRITICAL).

    1. BoLD paper
    Challenges

    A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the createLayerZeroEdge function in the ChallengeManager contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent “history root” that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 6d 8h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 12d 17h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.000000000000000001 ETH, level 2 requires a stake of 0.000000000000000001 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.

    • Funds can be stolen if an attacker successfully performs a resource exhaustion attack.

    1. Fraud Proof Wars: Arbitrum BoLD

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xc10c...dc97
    		Code unknown
    None
    Robinhood Chain logo
    Upgrades & Governance

    Past upgrades

    The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

    Count of upgrades
    No upgrades
    Last upgrade
    N/A
    Avg upgrade interval
    N/A
    Updates
    2026 July 02, 10:37 UTC
    19changes

    Initial discovery. The chain uses ArbOS 61 core contracts, newer builds of standard Orbit contracts. - SequencerInbox — diff Adds an owner-only setFeeTokenPricer (inert here: isUsingFeeToken=false , feeTokenPricer=0x0 ), a custom-DA header flag ( 0x01 , unused — chain posts blobs), and delay-proof paths. No new actors beyond the existing owner/batchPoster. - RollupProxy (RollupAdminLogic) — diff ArbOS 61 admin logic; all setters (allowlist, fee-token, batch-poster mgr, AFK-whitelist) stay owner-gated — covered by the template owner permission. - RollupProxy (RollupUserLogic) — diff ArbOS 61 user logic; BoLD assertion/force-inclusion flow and getValidators proposer set unchanged. - RollupEventInbox — diff BoLD event inbox; only initialize is rollup-gated, no standing permissions. - OneStepProofEntry — diff Proof dispatcher (ArbOS 61 opcode set); immutable constructor-set prover addresses, no mutable state, no permissions. - OneStepProver0 — diff Stateless one-step WASM verifier; ArbOS 61 opcode updates only, no state/permissions. - OneStepProverMath — diff Stateless math-opcode verifier; ArbOS 61 opcode updates only, no state/permissions. - OneStepProverMemory — diff Stateless memory-opcode verifier; ArbOS 61 opcode updates only, no state/permissions. - OneStepProverHostIo — diff Host-io verifier (ArbOS 61 host-io/opcode updates); immutable customDAValidator ( 0x0 here, so custom-DA proof paths revert), no mutable state, no permissions.

    Initial discovery.

    The chain uses ArbOS 61 core contracts, newer builds of standard Orbit contracts.

    • SequencerInbox — diff Adds an owner-only setFeeTokenPricer (inert here: isUsingFeeToken=false, feeTokenPricer=0x0), a custom-DA header flag (0x01, unused — chain posts blobs), and delay-proof paths. No new actors beyond the existing owner/batchPoster.
    • RollupProxy (RollupAdminLogic) — diff ArbOS 61 admin logic; all setters (allowlist, fee-token, batch-poster mgr, AFK-whitelist) stay owner-gated — covered by the template owner permission.
    • RollupProxy (RollupUserLogic) — diff ArbOS 61 user logic; BoLD assertion/force-inclusion flow and getValidators proposer set unchanged.
    • RollupEventInbox — diff BoLD event inbox; only initialize is rollup-gated, no standing permissions.
    • OneStepProofEntry — diff Proof dispatcher (ArbOS 61 opcode set); immutable constructor-set prover addresses, no mutable state, no permissions.
    • OneStepProver0 — diff Stateless one-step WASM verifier; ArbOS 61 opcode updates only, no state/permissions.
    • OneStepProverMath — diff Stateless math-opcode verifier; ArbOS 61 opcode updates only, no state/permissions.
    • OneStepProverMemory — diff Stateless memory-opcode verifier; ArbOS 61 opcode updates only, no state/permissions.
    • OneStepProverHostIo — diff Host-io verifier (ArbOS 61 host-io/opcode updates); immutable customDAValidator (0x0 here, so custom-DA proof paths revert), no mutable state, no permissions.

    Initial discovery

    + Status: CREATED
    contract ProxyAdmin (eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD) [N/A]
    +++ description: None
    + Status: CREATED
    contract Inbox (eth:0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D) [orbitstack/Inbox]
    +++ description: Facilitates sending L1 to L2 messages like depositing ETH, but does not escrow funds.
    + Status: CREATED
    contract Safe (eth:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract RollupProxy (eth:0x23A19d23e89166adedbDcB432518AB01e4272D94) [orbitstack/RollupProxyBoLD]
    +++ description: Central contract for the project's configuration like its execution logic hash (`wasmModuleRoot`) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called Validators).
    + Status: CREATED
    contract OneStepProverMath (eth:0x4B15E064d5d55705E89080bDEA4BFe4cF20D6114) [orbitstack/OneStepProverMath]
    +++ description: One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
    + Status: CREATED
    contract OneStepProofEntry (eth:0x5087a6fD526eFD5c6770d94D0c325de0e2A2c44D) [orbitstack/OneStepProofEntry]
    +++ description: One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
    + Status: CREATED
    contract UpgradeExecutor (eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf) [orbitstack/UpgradeExecutor]
    +++ description: Central contract defining the access control permissions for upgrading the system contract implementations.
    + Status: CREATED
    contract OneStepProverMemory (eth:0x665CEA1cA6C36aB701f4C6AE895b156f79C51c35) [orbitstack/OneStepProverMemory]
    +++ description: One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
    + Status: CREATED
    contract L1GatewayRouter (eth:0x6a2E3a1e16FC29f27Ce61429746D558d656975bB) [orbitstack/GatewayRouter]
    +++ description: This routing contract maps tokens to the correct escrow (gateway) to be then bridged with canonical messaging.
    + Status: CREATED
    contract EdgeChallengeManager (eth:0x6f38FC91105Fc9a43931DcA33450ab3315E3D4Fa) [orbitstack/EdgeChallengeManager]
    +++ description: Contract that implements the main challenge protocol logic of the fraud proof system.
    + Status: CREATED
    contract OneStepProver0 (eth:0x6fE84aC811EBEcd888Eca93757fEa378Bb03b00c) [orbitstack/OneStepProver0]
    +++ description: One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
    + Status: CREATED
    contract L1ERC20Gateway (eth:0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0) [orbitstack/ERC20Gateway]
    +++ description: Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.
    + Status: CREATED
    contract SequencerInbox (eth:0xBd0D173EEb87D57A09521c24388a12789F33ba96) [orbitstack/SequencerInbox]
    +++ description: A sequencer (registered in this contract) can submit transaction batches or commitments here.
    + Status: CREATED
    contract Wrapped Ether Token (eth:0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) [N/A]
    +++ description: None
    + Status: CREATED
    contract RollupEventInbox (eth:0xc34f4907822d1cDC6aE3038Be22e6f12DEa35bd4) [orbitstack/RollupEventInbox]
    +++ description: Helper contract sending configuration data over the bridge during the systems initialization.
    + Status: CREATED
    contract Bridge (eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3) [orbitstack/Bridge]
    +++ description: Escrow contract for the project's gas token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridge messaging.
    + Status: CREATED
    contract OneStepProverHostIo (eth:0xe1aAfAfBde42f043495B39d1a15a58E91c894Fbf) [orbitstack/OneStepProverHostIo]
    +++ description: One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
    + Status: CREATED
    contract Outbox (eth:0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9) [orbitstack/Outbox]
    +++ description: Facilitates L2 to L1 contract calls: Messages initiated from L2 (for example withdrawal messages) eventually resolve in execution on L1.
    + Status: CREATED
    contract L1WethGateway (eth:0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B) [N/A]
    +++ description: None
    Operator

    The system has a centralized sequencer

    While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    1. Sequencer - Arbitrum documentation

    Users can force any transaction

    Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 4d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.

    1. SequencerInbox.sol - source code, forceInclusion function
    2. Sequencer Isn't Doing Its Job - Arbitrum documentation
    Sequencing

    Buffered forced transactions

    To force transactions from the host chain, users must first enqueue “delayed” messages in the “delayed” inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the sendMessage or sendMessageFromOrigin functions. If the centralized sequencer doesn’t process the request within some time bound, users can call the forceInclusion function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 4d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn’t timely process a message. Only messages processed with a delay greater than 1634y 3mo consume the buffer. The buffer is capped at 1634y 3mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 1634y 3mo.

    1. Sequencer and censorship resistance - Arbitrum documentation
    Withdrawals

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.

    1. Transaction lifecycle - Arbitrum documentation
    2. L2 to L1 Messages - Arbitrum documentation
    3. Mainnet for everyone - Arbitrum Blog

    Autonomous exit

    Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.

    Other considerations

    EVM compatible smart contracts are supported

    Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.

    1. Inside Arbitrum Nitro
    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Actors:

    ProxyAdmin0x1232…90FD
    • Can upgrade with no delay
      • Inbox
      • UpgradeExecutor
      • L1GatewayRouter
      • EdgeChallengeManager
      • L1ERC20Gateway
      • SequencerInbox
      • RollupEventInbox
      • Bridge
      • Outbox
      • L1WethGateway
    Safe0x1F3B…31C5

    A Multisig with 2/3 threshold.

    • Can upgrade with no delay
      • RollupProxy
    • Can interact with RollupProxy
      • Pause and unpause and set important roles and parameters in the system contracts: Can delegate Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes

    Participants (3):

    0x2963…Fa170x2584…8b2c0xb89C…f31c
    2 EOAs
    EOA 1EOA 2
    • Can interact with RollupProxy
    EOA 30xDaa5…87F4
    • Can interact with SequencerInbox
      • Can submit transaction batches or commitments to the SequencerInbox contract on the host chain
    Smart contracts
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    RollupProxy0x23A1…2D94Implementation #1 (Upgradable)Implementation #2 (Upgradable)Admin

    Central contract for the project’s configuration like its execution logic hash (wasmModuleRoot) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called Validators).

    • Roles:
      • admin: UpgradeExecutor; ultimately Safe
      • getValidators: EOA 1, EOA 2
      • owner: UpgradeExecutor; ultimately Safe The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    Safe with no delay
    EdgeChallengeManager0x6f38…D4FaImplementation (Upgradable)Admin

    Contract that implements the main challenge protocol logic of the fraud proof system.

    • Roles:
      • admin: ProxyAdmin The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    SequencerInbox0xBd0D…ba96Implementation (Upgradable)Admin

    A sequencer (registered in this contract) can submit transaction batches or commitments here.

    • Roles:
      • admin: ProxyAdmin
      • batchPosters: EOA 3 The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    Bridge
    Escrow
    0xDf87…64b3Implementation (Upgradable)Admin

    Escrow contract for the project’s gas token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridge messaging.

    • Roles:
      • admin: ProxyAdmin The source code of this contract is not verified on Etherscan.
    The following tokens are included in the value secured calculation:
    ETH token logo
    Can be upgraded by:
    ProxyAdmin with no delay
    UpgradeExecutor0x5526…B4bfImplementation (Upgradable)Admin

    Central contract defining the access control permissions for upgrading the system contract implementations.

    • Roles:
      • admin: ProxyAdmin
      • executors: Safe The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    Inbox0x1A07…7a2DImplementation (Upgradable)Admin

    Facilitates sending L1 to L2 messages like depositing ETH, but does not escrow funds.

    • Roles:
      • admin: ProxyAdmin The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    L1ERC20Gateway
    Escrow
    0x8500…6da0Implementation (Upgradable)Admin

    Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.

    • Roles:
      • admin: ProxyAdmin

    All supported tokens in this escrow are included in the value secured calculation.

    Can be upgraded by:
    ProxyAdmin with no delay
    Implementation used in:
    Outbox0xf0ce…3DE9Implementation (Upgradable)Admin

    Facilitates L2 to L1 contract calls: Messages initiated from L2 (for example withdrawal messages) eventually resolve in execution on L1.

    • Roles:
      • admin: ProxyAdmin The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    L1GatewayRouter0x6a2E…75bBImplementation (Upgradable)Admin

    This routing contract maps tokens to the correct escrow (gateway) to be then bridged with canonical messaging.

    • Roles:
      • admin: ProxyAdmin
    Can be upgraded by:
    ProxyAdmin with no delay
    Implementation used in:
    OneStepProverMath0x4B15…6114

    One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.

    OneStepProofEntry0x5087…c44D

    One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.

    OneStepProverMemory0x665C…1c35

    One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.

    OneStepProver00x6fE8…b00c

    One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.

    Wrapped Ether Token0xC02a…6Cc2
    Implementation used in:
    RollupEventInbox0xc34f…5bd4Implementation (Upgradable)Admin

    Helper contract sending configuration data over the bridge during the systems initialization.

    • Roles:
      • admin: ProxyAdmin The source code of this contract is not verified on Etherscan.
    Can be upgraded by:
    ProxyAdmin with no delay
    OneStepProverHostIo0xe1aA…4Fbf

    One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.

    L1WethGateway
    Escrow
    0xF7e1…Cf1BImplementation (Upgradable)Admin
    • Roles:
      • admin: ProxyAdmin

    All supported tokens in this escrow are included in the value secured calculation.

    Can be upgraded by:
    ProxyAdmin with no delay

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

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xc10c...dc97
    		Code unknown
    None
    Robinhood Chain logo