# Robinhood Chain: what the project's own docs say (second source behind L2BEAT)

Snapshot taken 2026-10-27. Sources: Robinhood's own docs at https://docs.robinhood.com/chain (the "Docs" link on L2BEAT's project page; the website https://robinhood.com/chain/ links to it as "Start building"), plus Arbitrum's upstream docs (https://docs.arbitrum.io) wherever Robinhood's docs say the chain is "an Arbitrum Chain running Arbitrum Nitro" and the mechanism comes from Nitro. I did not use L2BEAT, news sites or memory as evidence for any fact below.

## 2. Proof system

- **Optimistic, with fraud proofs (BoLD).** "Robinhood Chain uses BoLD (Bounded Liquidity Delay) for dispute resolution, secured by a permissioned set of validators." Validators "monitor on-chain assertions and are capable of detecting and submitting fraud-proof challenges". — https://docs.robinhood.com/chain/governance
- **Validators are permissioned (allowlisted), not open to anyone.** "Robinhood Chain utilizes BoLD for dispute resolution through a permissioned set of validators." "Operating a validator necessitates being included in the allowlist and staking a 1 WETH bond" ("defensive validators are highly encouraged"). — https://docs.robinhood.com/chain/run-a-full-node
- **Who runs validation today:** two validators, run by Offchain Labs and Alchemy. — https://docs.robinhood.com/chain/governance
- **Upstream context:** Arbitrum's docs describe BoLD as "a new dispute protocol for optimistic Rollups that enables permissionless validation for Arbitrum chains", and add that it "allows anyone to participate in validating chain state". So BoLD *can* run permissionlessly, but Robinhood's docs say its deployment uses an allowlist. — https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction
- **Challenge period:** withdrawals through the canonical bridge are "subject to a 7-day challenge period". The docs call this "a requirement of Arbitrum's fraud-proof system, separate from transaction finality." — https://docs.robinhood.com/chain/transaction-finality. The bridging page says the same ("Wait for the 7-day challenge period, a standard requirement of Arbitrum's fraud proof system"; "Withdrawal ~7 days (challenge period)"). — https://docs.robinhood.com/chain/bridging. L2→L1 messages are likewise "Subject to the 7-day challenge period". — https://docs.robinhood.com/chain/cross-chain-messaging
- **L1 contracts (from the project):** Rollup `0x23A19d23e89166adedbDcB432518AB01e4272D94`, Sequencer Inbox `0xBd0D173EEb87D57A09521c24388a12789F33ba96`, CoreProxyAdmin `0x1232813BDd40aa9d53066A880dE78a4Be70B90FD`, Delayed Inbox `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D`, Bridge `0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3`, Outbox `0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9` (mainnet). — https://docs.robinhood.com/chain/protocol-contracts
- **When proofs went live on mainnet:** NOT FOUND. No page I read gives a date for BoLD or fraud proofs going live on Robinhood Chain.
- **Node software (for item 6 of the goal):** the docs contradict each other, so both are given here.
  - The "Run a full node" page uses the image `offchainlabs/nitro-node:v3.11.2-3599aca`, says "Robinhood Chain runs ArbOS 61", and tells operators to confirm the current version. — https://docs.robinhood.com/chain/run-a-full-node
  - The Notices & Upgrades page, dated **2026-09-14**, says "Nitro v3.11.4 is available on Docker Hub". It is a node-software-only release with "no consensus changes", and "A full source release is expected in the coming business days". — https://docs.robinhood.com/chain/notices-and-upgrades

## 3. Exit window and upgrades

- **Governance body:** "Robinhood Chain's protocol is governed by a Security Council of eight signers." "Robinhood holds two of the eight seats, and the remaining six seats are held by independent institutions". The seats are held by BitGo, Chainlink Labs, Fireblocks Trust Company, Offchain Labs, Paxos, Robinhood (two seats) and Talos. — https://docs.robinhood.com/chain/governance
- **Thresholds and timelock:**
  - "Routine actions require approval from six of the eight signers" (**6 of 8**), and these actions pass through a **seven-day** on-chain timelock before they execute.
  - "Emergency actions bypass the timelock but require approval from seven of eight signers" (**7 of 8**, no delay).
  - Source for both: https://docs.robinhood.com/chain/governance
- **Signers:** "Every signer is required to maintain secure signing infrastructure", with key rotation and institutional-grade key management. — https://docs.robinhood.com/chain/governance
- **Upgrade mechanics:** the docs list `CoreProxyAdmin` / `L1 Proxy Admin` at `0x1232813BDd40aa9d53066A880dE78a4Be70B90FD` and `L2 Proxy Admin` at `0xa3Acd31AFb851B4eB9DAD00F5204c01D924267dF`. They do not name the owner of those proxy admins (no UpgradeExecutor or multisig address). — https://docs.robinhood.com/chain/protocol-contracts. The notices page says only: "These upgrades activate onchain at a scheduled time." — https://docs.robinhood.com/chain/notices-and-upgrades
- **What the docs do not say:** that the Security Council's 6-of-8 / 7-of-8 powers are, in so many words, the power to upgrade the L1 contracts. The governance page says the council "governs" the protocol and does not use the word "upgrade". — https://docs.robinhood.com/chain/governance
- **Exit window before an upgrade:** NOT FOUND. The docs give a 7-day timelock for routine actions and a ~7-day withdrawal challenge period. They never say whether users can finish a withdrawal before a timelocked upgrade takes effect, and emergency 7-of-8 actions skip the timelock. I have not derived an exit window from these two figures.

## 4. Data availability

- **Ethereum, as a rollup.** "Because Robinhood Chain posts its data to Ethereum, your node needs access to an Ethereum (L1) endpoint." — https://docs.robinhood.com/chain/run-a-full-node
- **Blobs (EIP-4844) are used:** node operators need "An L1 beacon (consensus) endpoint — required to read blob data". — https://docs.robinhood.com/chain/run-a-full-node
- **Calldata is also mentioned:** fees include "an L1 data (calldata) fee for posting the transaction to Ethereum". — https://docs.robinhood.com/chain/differences-from-ethereum. The "L1 data fee" is "the cost of posting your transaction's data to Ethereum for data availability" and is "proportional to the size of your transaction's calldata". — https://docs.robinhood.com/chain/gas-and-fees
- **Batches go to the L1 inbox:** "The sequencer batches transactions and posts the batch to the Ethereum (L1) Inbox." — https://docs.robinhood.com/chain/transaction-finality
- **The wording differs between pages.** The node page says blob data must be read, while the fee pages say "calldata". The docs never say outright whether batches are posted as blobs, as calldata, or as either one depending on price. No outside DA layer or AnyTrust committee is mentioned on any page I read.

## 5. Sequencer and forced inclusion

- **Single sequencer, ordering first-come first-served:** the chain uses a "first-come, first-served sequencing model", and no transaction can jump ahead by paying a higher fee. — https://docs.robinhood.com/chain. "Robinhood Chain employs a first-come, first-served model based on sequencer arrival time." — https://docs.robinhood.com/chain/differences-from-ethereum
- **The sequencer screens transactions:** "Robinhood Chain maintains compliance standards through sequencer-level screening". Transactions tied to sanctioned addresses are excluded and blocked transfers are never processed. — https://docs.robinhood.com/chain/differences-from-ethereum
- **Soft confirmations:** "The sequencer has committed to your transaction's inclusion and ordering". These can be reversed "only if the sequencer posts a batch with a different transaction order". — https://docs.robinhood.com/chain/transaction-finality
- **Who operates the sequencer:** NOT FOUND as an explicit statement. The docs refer to "the sequencer" in the singular and publish its feeds (`wss://feed.mainnet.chain.robinhood.com`, with backup `wss://delayed-feed.mainnet.chain.robinhood.com`; https://docs.robinhood.com/chain/run-a-full-node). They never name the operator and never describe any plan to decentralise it.
- **Forced inclusion on Robinhood's own docs:** NOT FOUND. The docs say L1→L2 messages are "submitted through the Delayed Inbox" and "Typically completes in minutes" (https://docs.robinhood.com/chain/cross-chain-messaging), and they list the Delayed Inbox contract `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D` (https://docs.robinhood.com/chain/protocol-contracts). They do not describe a way to force a transaction in if the sequencer censors.
- **Inherited Nitro mechanism, from Arbitrum's docs (upstream, not Robinhood-specific):**
  - Parties can bypass the sequencer "using the Sequencer Inbox's `forceInclusion` method".
  - "`delayBlocks` is a constant currently set to 7200 blocks (24 hours)".
  - "The force inclusion window is the lesser of `delayBuffer` and `delayBlocks`", where `delayBuffer` ranges from 30 minutes to 48 hours.
  - Deposits and retryable tickets "enter through the parent chain's delayed inbox".
  - Source: https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer (also served at https://docs.arbitrum.io/how-arbitrum-works/sequencer)
  - Arbitrum's page does not say who may call `forceInclusion`.
  - The 24 h figure is Arbitrum's default. Robinhood's docs do not give the chain's own `delayBlocks` / `delaySeconds` / delay-buffer settings, so Robinhood Chain's actual force-inclusion delay is NOT FOUND.

## 1. Stage

- NOT FOUND. No page I read on docs.robinhood.com/chain or robinhood.com/chain mentions an L2BEAT stage or a decentralisation roadmap (for example, removing the validator allowlist or decentralising the sequencer).
- The only related statements describe the current setup: a "permissioned set of validators" (https://docs.robinhood.com/chain/governance) and the eight-seat Security Council with six non-Robinhood seats (https://docs.robinhood.com/chain/governance).
- The marketing page says the chain was "Developed on Arbitrum's Layer 2 infrastructure, delivering high throughput with 100ms block times and Ethereum's security." — https://robinhood.com/chain/

## Not found

| What | Pages tried |
|---|---|
| Mainnet date when BoLD or fraud proofs went live on Robinhood Chain | /chain, /chain/governance, /chain/run-a-full-node, /chain/transaction-finality, /chain/bridging, /chain/notices-and-upgrades (all under https://docs.robinhood.com) |
| A sentence explicitly giving the Security Council (or a named multisig) the power to upgrade the L1 contracts; the owner address of CoreProxyAdmin `0x1232…90FD` | /chain/governance, /chain/protocol-contracts |
| Whether users get an exit window before upgrades take effect (any comparison of the 7-day timelock with the 7-day challenge period) | /chain/governance, /chain/bridging, /chain/transaction-finality |
| Named operator of the sequencer; any plan to decentralise it | /chain, /chain/differences-from-ethereum, /chain/run-a-full-node, /chain/transaction-finality |
| A Robinhood-documented force-inclusion procedure (function, contract, delay) and the chain's own `delayBlocks` / delay-buffer values; who may call `forceInclusion` (not stated on the Arbitrum page either) | /chain/cross-chain-messaging, /chain/differences-from-ethereum, /chain/transaction-finality; https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer |
| Whether batches are posted as blobs only, calldata only, or both (the pages differ in wording) | /chain/run-a-full-node, /chain/gas-and-fees, /chain/differences-from-ethereum |
| Anything about an L2BEAT stage or a decentralisation roadmap | all pages above, plus https://robinhood.com/chain/ |
| Project code repository | https://github.com/robinhood has 10 public repos (e.g. faust, ticker, spark, aiokafka) and none is chain-related. The docs link Arbitrum/Offchain Labs tooling, not a Robinhood repo. |
| https://docs.robinhoodchain.com | Could not be fetched: TLS error `TLSV1_ALERT_UNRECOGNIZED_NAME`. The official docs are at https://docs.robinhood.com/chain (the link L2BEAT and robinhood.com/chain give). |