Search

Search for projects by name or address

SummaryValue SecuredVolume and flowsActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisStageData availabilityState validationUpgrades & GovernanceUpdatesOperatorSequencingWithdrawalsOther considerationsPermissionsSmart contracts

Robinhood Chain logo
Robinhood Chain

1 recent update

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
    $632.16 M38.7%
  • Past day UOPSDaily UOPS
    86.72889%
  • Gas token
    ETH
  • Type
    Other
  • Purposes
    Universal, RWA
  • Chain ID
    4663

    • Tokens breakdown

    Last 24h cross-chain volume$128.81 M
    Last 24h cross-chain transfers277.45 K

    Interop protocols used

    RelayLayerZeroChainlink CCIP
    +4 more

    Tokens by volume

    USDGETHsyrupUSDG
    +429 more
    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
    Volume and flowsExplore Interop
    Chain stats · Canonical bridge
    Transfer size
    Under $100
    $100-$1K
    $1K-$10K
    $10K-$100K
    Over $100K
    Transfer type distribution
    Explore Interop
    Activity

    2026 Apr 30 — Jul 15

    Past Day UOPS
    86.72889%
    Past Day Ops count
    7.49 M
    Total Ops
    66.97 M
    since 2026 Apr 30
    Max. UOPS
    116.65
    2026 Jul 10
    Past day UOPS/TPS Ratio
    1.01
    Onchain costs

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

    2026 Apr 30 — Jul 15

    Total cost
    $8.02 K
    Avg cost per L2 UOP
    $0.000135
    Avg cost per day
    $105.63
    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 15

    Data posted
    7.34 GiB
    Avg size per day
    97.67 MiB
    Avg size per L2 UOP
    132.39 B
    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 15 — Jul 15

    Avg. tx data subs. interval
    1 minute
    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
    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. no whitelisted challenger disputes an invalid state root before the challenge window expires (CRITICAL),
    3. an attacker successfully performs a resource exhaustion attack.

    Users can be censored if

    1. the operator registers their transaction hash in the ArbFilteredTransactionsManager precompile, causing the state transition function to fail it even when it is force-included via the L1 delayed inbox.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.
    Risk analysis
    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
    No mechanism

    There is no guaranteed mechanism to have transactions included if the sequencer is down or censoring. Although users can enqueue messages in the L1 delayed inbox and call forceInclusion on the SequencerInbox, the chain runs ArbOS 61 transaction filtering: an authorized filterer can register any transaction hash 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 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
    Github
    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
    1
    Last upgrade
    15d 2h ago
    Avg upgrade interval
    1mo 8d
    Updates
    2026 July 14, 15:53 UTC
    32changes

    The ArbFilteredTransactionsManager now reports 278 added filtered transaction hashes, up from 2 in the previous discovery. No filtered transaction hash has been deleted. Transaction filtering is active: an authorized filterer can register a transaction hash and make the state transition fail that transaction, including one force-included from L1. Governance was restructured on both L1 and L2: - The single 2-of-3 admin multisig was replaced by a 7-of-8 multisig and a 7-day timelock. The 7-of-8 multisig remains a direct executor, so upgrades can still bypass the timelock delay. - A separate 6-of-8 multisig can propose and cancel timelock actions. - The timelock and its admin contracts are now verified on Etherscan and Blockscout.

    The ArbFilteredTransactionsManager now reports 278 added filtered transaction hashes, up from 2 in the previous discovery. No filtered transaction hash has been deleted. Transaction filtering is active: an authorized filterer can register a transaction hash and make the state transition fail that transaction, including one force-included from L1.

    Governance was restructured on both L1 and L2:

    • The single 2-of-3 admin multisig was replaced by a 7-of-8 multisig and a 7-day timelock. The 7-of-8 multisig remains a direct executor, so upgrades can still bypass the timelock delay.
    • A separate 6-of-8 multisig can propose and cancel timelock actions.
    • The timelock and its admin contracts are now verified on Etherscan and Blockscout.
    contract Safe (eth:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5) [GnosisSafe] {
    +++ description: None
    receivedPermissions:
    - [{"permission":"interact","from":"eth:0x23A19d23e89166adedbDcB432518AB01e4272D94","description":"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.","role":".owner","via":[{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x23A19d23e89166adedbDcB432518AB01e4272D94","role":"admin","via":[{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x6a2E3a1e16FC29f27Ce61429746D558d656975bB","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x6f38FC91105Fc9a43931DcA33450ab3315E3D4Fa","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0xBd0D173EEb87D57A09521c24388a12789F33ba96","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0xc34f4907822d1cDC6aE3038Be22e6f12DEa35bd4","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]},{"permission":"upgrade","from":"eth:0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B","role":"admin","via":[{"address":"eth:0x1232813BDd40aa9d53066A880dE78a4Be70B90FD"},{"address":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf"}]}]
    directlyReceivedPermissions:
    - [{"permission":"act","from":"eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf","role":".executors"}]
    }
    contract UpgradeExecutor (eth:0x552603b4bc1f5E896AF2854548D6380f45f1B4bf) [orbitstack/UpgradeExecutor] {
    +++ description: Central contract defining the access control permissions for upgrading the system contract implementations.
    values.accessControl.EXECUTOR_ROLE.members.0:
    + "eth:0x7Ae50886c7EA0394613aa7Dcc287a5c9650784b6"
    values.accessControl.EXECUTOR_ROLE.members.0:
    - "eth:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5"
    + "eth:0xE1e825D15192457d05a251715C3e2Cab0F8CF465"
    values.executors.0:
    + "eth:0x7Ae50886c7EA0394613aa7Dcc287a5c9650784b6"
    values.executors.0:
    - "eth:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5"
    + "eth:0xE1e825D15192457d05a251715C3e2Cab0F8CF465"
    directlyReceivedPermissions.2:
    + {"permission":"interact","from":"eth:0xE1e825D15192457d05a251715C3e2Cab0F8CF465","description":"manage all access control roles.","role":".defaultAdminAC"}
    }
    contract ArbFilteredTransactionsManager (robinhood:0x0000000000000000000000000000000000000074) [N/A] {
    +++ description: ArbOS 61 transaction-filtering precompile. An authorized filterer registers tx hashes here; the state transition function then forcibly fails those transactions, including force-included ones, without delay.
    values.filteredTransactionsAdded:
    - 2
    + 278
    }
    - Status: DELETED
    contract SafeL2 (robinhood:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5) [GnosisSafe]
    +++ description: None
    contract L2UpgradeExecutor (robinhood:0x2A153c6A1B66DBc930a8d7017230ab0253005C09) [orbitstack/UpgradeExecutor] {
    +++ description: ArbOS chain owner (UpgradeExecutor). Manages the ArbOwner chain-owner set and the transaction-filterer set, and can upgrade ArbOS configuration without delay.
    values.accessControl.EXECUTOR_ROLE.members.1:
    + "robinhood:0x6b9F63817F1442e40Bb9c3C2207758934C323FdC"
    values.accessControl.EXECUTOR_ROLE.members.1:
    - "robinhood:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5"
    + "robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173"
    values.executors.1:
    + "robinhood:0x6b9F63817F1442e40Bb9c3C2207758934C323FdC"
    values.executors.1:
    - "robinhood:0x1F3Bdec08A161Ca9e5480feF33A3B2278c2931C5"
    + "robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173"
    directlyReceivedPermissions.0:
    + {"permission":"act","from":"robinhood:0x672Da8B43058D1bC78956d71d9A208E168E2a3EF","role":".owner"}
    directlyReceivedPermissions.3:
    + {"permission":"interact","from":"robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173","description":"manage all access control roles.","role":".defaultAdminAC"}
    }
    EOA (robinhood:0x663703B4bC1F5e896Af2854548d6380F45F1C5D0) {
    +++ description: None
    receivedPermissions.1:
    + {"permission":"interact","from":"robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173","description":"manage all access control roles.","role":".defaultAdminAC","via":[{"address":"robinhood:0x2A153c6A1B66DBc930a8d7017230ab0253005C09"}]}
    receivedPermissions.3:
    + {"permission":"upgrade","from":"robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173","role":"admin","via":[{"address":"robinhood:0x672Da8B43058D1bC78956d71d9A208E168E2a3EF"},{"address":"robinhood:0x2A153c6A1B66DBc930a8d7017230ab0253005C09"}]}
    }
    + Status: CREATED
    contract Safe (eth:0x0fc5c64074641e677Fb86bCE80303a2eE64344Ac) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract ProxyAdmin (eth:0x4e393071053C5d95771b1B716857d65cdf5B1839) [N/A]
    +++ description: None
    + Status: CREATED
    contract Safe (eth:0x7Ae50886c7EA0394613aa7Dcc287a5c9650784b6) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract Safe (eth:0xbFc2b53552513174A0B006D4799B39871fe0CA1d) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract TimelockController (eth:0xE1e825D15192457d05a251715C3e2Cab0F8CF465) [global/TimelockController]
    +++ description: A timelock with access control. The current minimum delay is 7d.
    + Status: CREATED
    contract SafeL2 (robinhood:0x3A0C507Cc7F8785C877359ad49d0476966d17a1C) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract SafeL2 (robinhood:0x4C0360aFedD31e53718e4343F95E40b692402462) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract TimelockController (robinhood:0x560C81fe78FcC276e460524428f1a62057Ca8173) [global/TimelockController]
    +++ description: A timelock with access control. The current minimum delay is 7d.
    + Status: CREATED
    contract ProxyAdmin (robinhood:0x672Da8B43058D1bC78956d71d9A208E168E2a3EF) [global/ProxyAdmin]
    +++ description: None
    + Status: CREATED
    contract SafeL2 (robinhood:0x6b9F63817F1442e40Bb9c3C2207758934C323FdC) [GnosisSafe]
    +++ description: None
    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

    Force inclusion can be nullified by transaction filtering

    Users can enqueue messages in the L1 delayed inbox and, after the sequencing delay, call forceInclusion on the SequencerInbox to include them. However, the chain runs ArbOS 61 transaction filtering: an authorized filterer can register any transaction hash in the ArbFilteredTransactionsManager precompile (0x00…0074), after which the state transition function forcibly fails that transaction, including one force-included via L1, without delay. Force inclusion is therefore not a reliable censorship escape hatch.

    • Users can be censored if the operator registers their transaction hash in the ArbFilteredTransactionsManager precompile, causing the state transition function to fail it even when it is force-included via the L1 delayed inbox.

    1. Transaction screening - Robinhood Chain documentation
    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:

    Safe0x7Ae5…84b6

    A Multisig with 7/8 threshold.

    • Can upgrade with no delay
      • Inbox
      • RollupProxy
      • UpgradeExecutor
      • L1GatewayRouter
      • EdgeChallengeManager
      • L1ERC20Gateway
      • SequencerInbox
      • RollupEventInbox
      • Bridge
      • Outbox
      • L1WethGateway
    • 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
    • Can interact with TimelockController
      • manage all access control roles

    Participants (8):

    0x640B…73930x7957…21DDSafe0x54Fa…E4770xb89C…f31c0x2963…Fa170x2584…8b2c0xe94a…8d6A
    TimelockController0xE1e8…F465

    A timelock with access control. The current minimum delay is 7d.

    • Can upgrade with no delay
      • Inbox
      • RollupProxy
      • UpgradeExecutor
      • L1GatewayRouter
      • EdgeChallengeManager
      • L1ERC20Gateway
      • SequencerInbox
      • RollupEventInbox
      • Bridge
      • Outbox
      • L1WethGateway
    • 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
    • Can interact with TimelockController
      • manage all access control roles
    ProxyAdmin0x4e39…1839
    • Can upgrade with no delay
      • TimelockController
    Safe0xbFc2…CA1d

    A Multisig with 6/8 threshold.

    • Can interact with TimelockController
      • cancel queued transactions
      • propose transactions

    Participants (8):

    0x640B…73930x7957…21DDSafe0x54Fa…E4770xb89C…f31c0xd857…7bB10xC951…93530xe94a…8d6A
    Safe0x0fc5…44Ac

    A Multisig with 3/7 threshold. Member of Safe, Safe.

    Participants (7):

    0xBa86…9ecA0x582B…050F0xFA67…45620x499b…41B40x90a0…70290x026F…e5260x9b64…740C
    Safe0x1F3B…31C5

    A Multisig with 2/3 threshold.

    Participants (3):

    0x2963…Fa170x2584…8b2c0xb89C…f31c
    2 EOAs
    EOA 3EOA 4
    • Can interact with RollupProxy
    EOA 50xDaa5…87F4
    • Can interact with SequencerInbox
      • Can submit transaction batches or commitments to the SequencerInbox contract on the host chain

    Robinhood Chain

    Actors:

    SafeL20x6b9F…3FdC

    A Multisig with 7/8 threshold.

    • Can upgrade with no delay
      • L2UpgradeExecutor
      • TimelockController
    • Can interact with L2UpgradeExecutor
      • Can add or remove transaction filterers and change ArbOS configuration on the L2, without delay
    • Can interact with TimelockController
      • manage all access control roles

    Participants (8):

    0x640B…73930x7957…21DDSafeL20x686c…F6eA0xb89C…f31c0x2963…Fa170x2584…8b2c0xe94a…8d6A
    SafeL20x4C03…2462

    A Multisig with 6/8 threshold.

    • Can interact with TimelockController
      • cancel queued transactions
      • propose transactions

    Participants (8):

    0x640B…73930x7957…21DDSafeL20x686c…F6eA0xb89C…f31c0xd857…7bB10xC951…93530xe94a…8d6A
    SafeL20x3A0C…7a1C

    A Multisig with 3/7 threshold. Member of SafeL2, SafeL2.

    Participants (7):

    0x582B…050F0xBa86…9ecA0xFA67…45620x499b…41B40x90a0…70290x026F…e5260x9b64…740C
    EOA 10x0000…0000
    • Can upgrade with 7d delay
      • L2UpgradeExecutor
      • TimelockController
    • Can interact with L2UpgradeExecutor
      • Can add or remove transaction filterers and change ArbOS configuration on the L2, without delay with 7d delay
    • Can interact with TimelockController
      • execute transactions that are ready
      • manage all access control roles with 7d delay or with 7d delay
    EOA 20x6637…C5D0
    • Can upgrade with no delay
      • L2UpgradeExecutor
      • TimelockController
    • Can interact with L2UpgradeExecutor
      • Can add or remove transaction filterers and change ArbOS configuration on the L2, without delay
    • Can interact with TimelockController
      • manage all access control roles
    TransactionFilterer0xebDc…24b7
    • Can interact with ArbFilteredTransactionsManager
      • Can register/remove transaction hashes in the ArbFilteredTransactionsManager precompile, causing the state transition function to forcibly fail those transactions, including force-included ones, without delay
    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, TimelockController
      • getValidators: EOA 3, EOA 4
      • owner: UpgradeExecutor; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController with no delay
    EdgeChallengeManager0x6f38…D4FaImplementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController with no delay
    SequencerInbox0xBd0D…ba96Implementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Safe, TimelockController
      • batchPosters: EOA 5
    Can be upgraded by:
    Safe with no delayTimelockController 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; ultimately Safe, TimelockController
    The following tokens are included in the value secured calculation:
    ETH token logo
    Can be upgraded by:
    Safe with no delayTimelockController with no delay
    UpgradeExecutor0x5526…B4bfImplementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Safe, TimelockController
      • executors: Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController with no delay
    Inbox0x1A07…7a2DImplementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController 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; ultimately Safe, TimelockController

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

    Can be upgraded by:
    Safe with no delayTimelockController 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; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController 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; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController with no delay
    Implementation used in:
    ProxyAdmin0x1232…90FD
    • Roles:
      • owner: UpgradeExecutor
    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; ultimately Safe, TimelockController
    Can be upgraded by:
    Safe with no delayTimelockController 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; ultimately Safe, TimelockController

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

    Can be upgraded by:
    Safe with no delayTimelockController with no delay

    Robinhood Chain

    L2UpgradeExecutor0x2A15…5C09Implementation (Upgradable)Admin

    ArbOS chain owner (UpgradeExecutor). Manages the ArbOwner chain-owner set and the transaction-filterer set, and can upgrade ArbOS configuration without delay.

    • Roles:
      • admin: ProxyAdmin; ultimately EOA 1, EOA 2, SafeL2
      • chainOwners: L2UpgradeExecutor; ultimately EOA 1, EOA 2, SafeL2
      • executors: EOA 2, SafeL2, TimelockController
    Can be upgraded by:
    EOA 1 with 7d delayEOA 2 with no delaySafeL2 with no delay
    ArbFilteredTransactionsManager0x0000…0074

    ArbOS 61 transaction-filtering precompile. An authorized filterer registers tx hashes here; the state transition function then forcibly fails those transactions, including force-included ones, without delay.

    • Roles:
      • transactionFilterers: TransactionFilterer
    1. Source Code
    TimelockController0x560C…8173Implementation (Upgradable)Admin

    A timelock with access control. The current minimum delay is 7d.

    • Roles:
      • admin: ProxyAdmin; ultimately EOA 1, EOA 2, SafeL2
      • canceller: SafeL2
      • defaultAdmin: L2UpgradeExecutor, TimelockController; ultimately EOA 1, EOA 2, SafeL2
      • executor: EOA 1
      • proposer: SafeL2
    Can be upgraded by:
    EOA 1 with 7d delayEOA 2 with no delaySafeL2 with no delay
    ProxyAdmin0x672D…a3EF
    • Roles:
      • owner: L2UpgradeExecutor
    ProxyAdmin0xa3Ac…67dF
    • Roles:
      • owner: L2UpgradeExecutor

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

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xc10c...dc97
    Github
    Robinhood Chain logo