How sequencing works on Robinhood Chain

Robinhood Chain is an Arbitrum Orbit chain running Nitro, ArbOS 61 as of 2026-09-16. Checked against live RPC, the L1 contracts, a raw feed capture, and the official docs on 2026-09-16, plus L2BEAT, Glassnode, DNS, and press coverage where the page says so. Where something is inferred or unknown, the page says so. The source of record is STATUS.md in the BLCK repo.

One sequencer, ordered by arrival

There is a single sequencer, operated by Robinhood. The official docs describe a "first-come, first-served sequencing model, where the order is determined strictly by arrival time". That is the entire ordering rule. No auction. No priority fee that moves you. No way to buy a position in the queue. eth_maxPriorityFeePerGas returns 0.

On L1 there is one batch poster, 0xDaa526086787d9DEbE1D7F3FFdb1fE50cf8687F4 (SequencerInbox.isBatchPoster returns true for it). L2BEAT lists no backup sequencer.

For a searcher this collapses the problem to one variable: the time between your decision and your transaction's arrival at the sequencer. That is what sequencer-edge engineering optimizes.

No public mempool

Checked fact: txpool_content, txpool_status, and eth_newPendingTransactionFilter all return -32601 method does not exist on mainnet. There is no pending pool to read and no pending filter to subscribe to. The Chainstack feed decoder README states the same independently.

Consequences:

• You cannot see anyone else's transaction before the sequencer orders it.
• No public observer can see yours before it is ordered. Any RPC you route through can, and so can the sequencer operator. There is no frontrunning by observation of a public pending pool.
• The first public place a transaction becomes visible is the sequencer feed, and by then it is already ordered.

The sequencer feed

The feed is a WebSocket stream of sequenced messages, in order. Nitro's feed is designed to broadcast sequenced messages ahead of block RPC. blck-probe's first runs from Dubai put the feed within a few milliseconds of PublicNode's newHeads at the median (p95 20 to 40 ms), so from a distant vantage point the lead is small; the intrinsic lead needs a run near the sequencer. The feed is public on both networks:

• Mainnet: wss://feed.mainnet.chain.robinhood.com

BLCK connected from a plain WebSocket client; no key was needed in that test. The payload is JSON: {"version":1,"messages":[{"sequenceNumber":...,"message":{"message":{"header":{"kind":3,...},"l2Msg":"<base64>"}}}]}. l2Msg is base64; see the Chainstack feed decoder for what it decodes to. The feed hosts CNAME to customer-origin.offchainlabs.com behind Cloudflare.

Two things to keep straight when you measure with it:

1. Feed order is sequencer order. The sequence numbers are the ordering.
2. Any timestamp you record when a message arrives is your local arrival time. It includes transit from the origin through Cloudflare to your client. It is not the moment the sequencer ordered the message. Compare feed arrival against block RPC arrival from the same host and you get a feed-versus-RPC delay for that host. Nothing more.

The feed is where you expect to learn state first. Whether it beats block RPC on this chain, and by how much, is a per-host measurement blck-probe records. The only runs so far are from Dubai, where the median difference is a few milliseconds.

Submitting: sequencer endpoint versus read RPC

Robinhood publishes a dedicated submission endpoint, separate from the read RPC.

The submit endpoint rejects reads. eth_chainId against it returns -32601. It exists for eth_sendRawTransaction. Treat it as write-only. Do state reads and simulation elsewhere, sign locally, push the raw transaction there.

The official read RPC is more than one node. web3_clientVersion returned nitro/v3.11.4-rc.3-7d5ac27 from one and nitro/v3.12.0-rc.2 from another behind the same host. Robinhood publishes no first-party WebSocket JSON-RPC. Public third-party wss endpoints exist (wss://robinhood-rpc.publicnode.com, wss://robinhood.drpc.org), plus keyed providers. Alchemy is the docs-recommended one. Any third-party RPC is another hop between you and the sequencer. Measure it rather than assume it.

One practical note: the official RPC returns HTTP 403 to the default Python urllib user agent. Send a normal user agent.

Block cadence

Nitro produces a block only when there are transactions to put in it. Measured on mainnet over a 60 s sample: 621 blocks in 60.6 s, mean 97.7 ms per block, with per-second block counts ranging from 2 to 44.

The configured maximum block speed is not published (open question Q2 in STATUS.md). "About 100 ms" is a measurement, not a setting. Do not build timing assumptions on a fixed tick. Blocks are a function of load.

The finality ladder

Three rungs, each stronger than the last.

1. Sequencer ordering (soft confirmation). The sequencer accepts your transaction, assigns it a position, and emits it on the feed. Until the batch reaches L1, that order rests on the sequencer alone. This is what you trade on.
2. L1 batch posting. The batch poster writes batches to Ethereum as EIP-4844 blobs. Verified: the latest SequencerBatchDelivered on the L1 SequencerInbox decoded with dataLocation 3 (Blob), carried by a type 0x3 transaction with blob versioned hashes. This is a rollup, not AnyTrust. Once the batch is on L1, the data has been published to Ethereum.
3. BoLD. Dispute resolution uses BoLD with a permissioned validator set. Rollup.validatorWhitelistDisabled() returns false and getValidators() returns two addresses. The docs name the validators as Offchain Labs and Alchemy. Which address belongs to which is not published (Q7).

Settlement contracts:

Force inclusion: 4 days, with a caveat

If the sequencer refuses or ignores your transaction, the escape hatch is the L1 delayed inbox. You submit on Ethereum, wait, then force inclusion.

SequencerInbox.maxTimeVariation() on both networks returns delayBlocks 28800, futureBlocks 300, delaySeconds 345600, futureSeconds 3600. The delay is 345600 seconds. That is 4 days. It is not the roughly 24 hours that is the Arbitrum default. Plan around 4 days.

Open question: ArbOS 61 ships a transaction filtering precompile at 0x74. L2BEAT reports it is configured on Robinhood Chain and can nullify force inclusion. BLCK has not probed it (Q4). Until someone does, treat "force inclusion works" as unverified on this chain, and read any censorship-resistance claim with that in mind.

Sept 4, 2026: a blob-posting gap, not a halt

Describe this one accurately, because the coverage did not. An L2 block scan of all of 2026-09-04 found no gap above 700 s. 854,255 blocks were produced that day at roughly 101 ms. L2 block production continued.

What stopped was blob batch posting to Ethereum, in two windows: 12:29:47Z to 12:38:23Z and 12:42:47Z to 12:48:11Z. About 14 minutes in total. Arbitrum attributed it to blob market conditions. There is no Robinhood post-mortem (Q5).

For a searcher the lesson is about the ladder above. Rung 1 kept going. Rung 2 paused. For about 14 minutes every L2 transaction rested on the sequencer's word alone. BLCK did not check whether ordering was affected during the gap. If your risk model needs L1 data availability before you count a fill, that is what it costs when the blob market misbehaves.

Single point of failure

One sequencer. No backup sequencer listed on L2BEAT. No published failover procedure. The Terms of Service disclaim uptime (Q8). If the sequencer is down, the only alternative path is the delayed inbox with its 4-day delay, subject to the filtering caveat above.

Where the sequencer is (inferred)

Not officially published. DNS for sequencer.mainnet.chain.robinhood.com resolves to 3.136.74.196, 3.141.111.43, and 3.142.9.34, all inside the AWS us-east-2 (Ohio) EC2 range. Glassnode's latency monitor independently places it in us-east-2. Treat this as a strong inference, not a statement from Robinhood. Measure from where you intend to run before committing to a region.

What this means for you

• The only lever is arrival time. Fee does not move you. Measure your path to the sequencer from your actual box. That is what blck-probe does.
• Submit to the sequencer endpoint, raw and pre-signed. Every RPC hop in between is latency you pay for nothing.
• Read state from the feed when being early matters. It is ordered and public. Measure its lead over block RPC from your own host before relying on it.
• There is no public pending transaction to frontrun. The race is to public signals and to sequenced state, and it is won by reacting faster than the next person.
• Blocks are load-driven. Do not schedule against a 100 ms tick.
• Sequencer order is your trading confirmation, batch posting is your data-availability confirmation, BoLD is settlement. Know which one your risk model needs.
• Force inclusion is a 4-day path with an unresolved filtering caveat. It is not an operational fallback.
• One sequencer, no published failover. Build for the sequencer going away.
• The region is inferred, not published. Measure from candidate regions before choosing one.
• If Robinhood ever adds a priority auction, arrival time still decides everything the auction does not cover. The latency work stays and an auction layer gets added on top. See 02 for what would change.