Benchmarks

First runs exist: probe files from a single vantage point (Dubai, residential connection) for the rpc, feed, blocks, and send subcommands are committed under benchmarks/data and rendered on this page under Runs recorded so far. Every cell reading "data coming" is replaced by a committed probe file, never by hand.

blck-probe is live. Its read-only modes need no funds; send mode needs a funded key and, on mainnet, both halves of the probe's guard. This page is the frame its output is poured into. Nothing on this page is estimated.

Why this page exists

Robinhood Chain orders transactions strictly by arrival time at one sequencer, and you cannot pay for position. So the numbers that matter are not the ones a typical RPC benchmark reports. What matters is how fast the sequencer submission endpoint takes your transaction, how much earlier the sequencer feed shows a transaction than block RPC does, how blocks are spaced, and how long it takes from your send to your receipt from a given part of the world. blck-probe is being built to measure those four things. Its rpc and feed subcommands also report block lag per endpoint and feed inter-message intervals as side outputs; those have no table here yet.

This is the measurement side of sequencer-edge engineering. If Robinhood ever adds a priority auction, arrival time still decides everything the auction does not cover, and the send-to-inclusion table gains a column for the paid lane. Nothing of the kind is announced (STATUS.md, Q3).

What blck-probe is built to measure

These are the four measurements blck-probe takes. All four have run from one vantage point: rpc, feed, and blocks on both networks, and send on mainnet. Their output files are committed under benchmarks/data and rendered below.

1. RPC round trip per endpoint

For each endpoint in the run, the probe will send a fixed sequence of read requests and record the round trip time of each, measured locally from send to complete response.

• Cold: the first request on a fresh connection, which includes DNS, TCP, and TLS setup.
• Warm: subsequent requests on a kept-alive connection.
• Reported as p50 and p95 over the run's sample count, per endpoint, per network.

Endpoints are the ones verified live in STATUS.md section 3: the official https://rpc.mainnet.chain.robinhood.com (rate limited), robinhood-rpc.publicnode.com, robinhood.drpc.org, robinhood.rpc.blxrbdn.com, robinhood.api.pocket.network, and rpc.ordofi.network. The probe's built-in default set is the official RPC, PublicNode, and dRPC; the rest, and keyed providers (Alchemy, QuickNode, Chainstack, dRPC, Blockdaemon, Validation Cloud, GetBlock), are added through --endpoints or BLCK_PROBE_EXTRA_RPCS as label and URL pairs. Output carries the label only, never the key.

The sequencer submission endpoint is not in this measurement. It rejects reads (eth_chainId returns method not found), so it can only be timed in send mode.

2. Feed arrival versus block visibility

The probe will hold a WebSocket to the sequencer feed (wss://feed.mainnet.chain.robinhood.com) and a block-head source against RPC: a newHeads subscription, or eth_blockNumber polling if the WebSocket is unavailable. For each feed message it records the local arrival time, then the local time at which the block containing that message becomes visible through RPC. The feed sequence number is mapped to a block number, and the mapping is checked against decoded transaction hashes. The difference is the feed lead.

Both timestamps are taken on the same machine, so clock skew against the sequencer does not enter the delta. What this measurement does not tell you is absolute latency from the sequencer to you. It tells you how much earlier the feed is than RPC from where you stand.

Reported as p50 and p95 of the delta, with the message count observed and which head source the run used.

3. Block cadence

The probe will record the local arrival time of each new block head it observes over a window and report blocks per wall-clock second, the mean inter-block interval, and the minimum and maximum blocks per second seen.

Nitro only produces a block when there are transactions to put in it. Cadence is therefore a measure of chain activity as much as of the sequencer's configured block speed, which Robinhood does not publish (STATUS.md, Q2). A quiet window will show wider intervals than a busy one on the same sequencer. Runs record the window length so that readers can compare like with like.

4. Send-to-inclusion delay by region

Send mode. The probe signs a minimal self-transfer with a throwaway key, submits it to the sequencer submission endpoint, records the local send time, then records when the hash is acknowledged, when the transaction appears in the sequencer feed, when its block arrives through a WebSocket RPC, and when a receipt is visible. Each of those is a separate column.

Runs are tagged with a region label from BLCK_PROBE_REGION. The point of the region column is to test the working hypothesis that the sequencer sits in AWS us-east-2 (Ohio). That location is inferred from DNS and from Glassnode's monitor. Robinhood has not published it. If the hypothesis is right, a vantage point in us-east-2 should show the lowest send-to-feed delta. If it is wrong, this table is how we find out.

Send mode has run on mainnet at the owner's direction, from a dedicated key holding a small balance: eight zero-value self-transfers, all included. Every row carries the endpoint it was measured against, because the endpoints differ by more than a few milliseconds.

Methodology caveats

Read these before reading any number that lands on this page.

• Single vantage point per run. Each JSON file is one machine in one place at one time. A row is a sample of that path, not a property of the chain. Multiple rows from the same region on different days are expected to differ.
• Local arrival timestamps. Every timestamp is taken by the probe on its own clock. There is no synchronization with the sequencer and no attempt to estimate one-way latency. Deltas between two local timestamps are sound; anything labeled as absolute is not on this page.
• Roughly 100 ms block granularity. The measured mainnet block interval is about 100 ms (STATUS.md section 2). Anything reported in blocks rather than milliseconds has that resolution at best. Whether inclusion delay has a floor tied to the sequencer's block speed setting, which Robinhood does not publish (STATUS.md, Q2), is something send mode will show, not something this page assumes.
• Public RPC rate limits. The official RPC is rate limited and returns HTTP 403 to the default Python urllib user agent, so the probe sends its own user agent string (blck-probe/<version>). TODO (owner): confirm the official RPC accepts it, or switch to a browser-style agent. Public third-party endpoints have their own limits. A p95 that looks bad may be a throttle, not a network path. Runs will record request errors separately, with rate-limit responses counted on their own, so throttling is visible rather than folded into latency.
• Region labels are self-reported. BLCK_PROBE_REGION is whatever the operator typed. BLCK does not verify it. Contributed runs are labeled by the contributor.
• The feed is behind Cloudflare. Feed hosts CNAME to an Offchain Labs origin behind Cloudflare, so feed arrival includes whatever that edge adds from your location.
• Official RPC nodes are not identical. Nodes behind the official host have returned different Nitro versions in the same day (STATUS.md, Q13). Cold and warm samples may land on different nodes.
• Activity dependence. Nitro produces a block only when there is something to sequence, so cadence figures describe the chain during that run, not a configured block time.

Table layouts

Every committed run is rendered in full under "Runs recorded so far" at the bottom of this page: one block per file in benchmarks/data, with the run's facts (network, region, start and end time, sample count, probe version), its endpoints by label, every summary key as recorded, and the notes the probe attached to the run. Nothing is averaged across files and nothing is typed in by hand.

The layouts below are the comparison tables this page grows into as runs from more vantage points land. Their cells are only ever filled from committed probe files. Where no file exists, the cell says "data coming".

RPC round trip

Columns: endpoint, network, vantage region, cold p50, cold p95, warm p50, warm p95, samples, run date. The committed rpc runs are rendered below with their per-endpoint summaries. Rows for the remaining public endpoints and any labeled keyed endpoints are added as runs land.

Feed arrival versus block visibility

Columns: network, vantage region, feed lead p50, feed lead p95, messages observed, run date. The committed feed runs are rendered below.

Block cadence

Columns: network, window length, blocks observed, mean interval, min blocks per second, max blocks per second, run date. The committed blocks runs are rendered below.

Send-to-inclusion by region

One send-mode run exists (mainnet, eight transactions); it is rendered under Runs recorded so far.

Mainnet rows come from runs the owner directed; the probe refuses mainnet sends unless both halves of its guard are set.

Raw data

Every number on this page traces to a JSON file in benchmarks/data. The file format is the JSON Schema at benchmarks/schema/probe-result.schema.json, and scripts/check-probe-output.sh checks every committed file against it. Files are named <subcommand>-<network>-<region>-<UTC timestamp>.json, so each one carries its region label and run timestamp, and only real probe output is committed. There are no synthetic or hand-edited files in that directory, and there will not be.

External reference

Glassnode runs a public latency monitor for Robinhood Chain at https://latency.glassnode.com/robinhood/status. BLCK does not control it, does not know its methodology in detail, and does not reproduce its numbers here. It is useful as an independent view. It is also one of the two sources for the inference that the sequencer sits in us-east-2, and BLCK treats that as an inference rather than a fact.

Measure from where you are

Every number on this page was measured from one machine in Dubai, which answers the wrong question. Ordering on this chain is by arrival time, so what decides whether a strategy is worth building is how far you are from the sequencer, not how far someone else was.

The page carries a probe that measures that in your browser, against the same three endpoints blck-probe uses. All of them allow cross-origin requests, so there is no backend involved and nothing is uploaded: the numbers exist only in your tab. Your result appears beside the Dubai figure for the same endpoint.

Read it as an upper bound. A browser round trip carries overhead a native client does not, so the same machine measures slower here than through blck-probe, and the useful parts are the comparison between endpoints and the order of magnitude. If your fastest endpoint is several hundred milliseconds away, the chain produces more than a block per round trip from where you sit, and anything decided by arrival time is lost before your transaction leaves.

Contribute a region

The send-to-inclusion table is only as good as the set of vantage points behind it. A run from Frankfurt, Tokyo, Singapore, Sao Paulo, or a colo you already rent is worth more than a second run from the same region, and a run from inside us-east-2 is the one that tests the location hypothesis directly.

What a contribution needs:

• A blck-probe run with BLCK_PROBE_REGION set to something specific enough to be useful (provider and region, for example aws-eu-central-1 or hetzner-fsn1).
• The unmodified JSON output.
• Send-mode runs spend real ETH. Use a dedicated key with a small balance, and set both halves of the probe's guard deliberately.
• No keys, ever. Keyed endpoints appear by label only.

TODO (owner): add the contribution link and the review process for accepting contributed data files.