Robinhood Chain Sequencer Feed & Transaction Sending are now live. Receive data earlier, send transactions faster!
Get Started
Sign in
Create Account

Performance claims, with evidence attached.

Chain
Capability
Status
Robinhood ChainTransaction Submission
Current

Test date

Robinhood Chain transaction sending

Same-nonce races and paired transactions measured arrival order and final onchain position against the official endpoint.

Same-nonce win rate60.46%

425 of 703 resolved rounds

Onchain position lead
54.62%
Comparable rounds
703
Failed sends
0
Comparison

BlockRazor Transaction Sending vs official Sequencer endpoint

Scope

703 rounds in each of two tests

Regions

Ohio

Method and limitations

The same client triggered matched transactions. The tests compared same-nonce winners, block height and transaction index.

The result measures the published Ohio test conditions and does not guarantee a fixed ordering position.

Sources verified: 2026-09-22
Robinhood ChainNode Stream
Current

Test date

Sequencer Feed Ultra vs official feed

Matching blocks were observed from the same clients in three Ohio Availability Zones.

Relative latency through P990.000ms

Across all three tested AZs

Matching samples
13,251
Availability Zones
3
Official-feed P99 max
953.111ms
Comparison

BlockRazor Ultra vs Robinhood Chain official feed

Scope

13,251 matching blocks

Regions

Ohio use2-az1, Ohio use2-az2, Ohio use2-az3

Method and limitations

The first feed to deliver a matching block received 0 ms relative latency. Later arrival was measured from the timestamp difference.

Zero relative latency means first arrival in the comparison, not zero end-to-end delivery time.

Sources verified: 2026-09-22
Robinhood ChainTransaction Submission
Current

Test date

Robinhood Chain RPC regional race

Same-nonce transaction pairs measured which regional route reached execution first.

Highest inclusion rate70%

Frankfurt test region

Singapore
65%
Tokyo
65%
Transaction pairs
150
Comparison

BlockRazor RPC vs official Sequencer endpoint

Scope

50 same-nonce pairs per region

Regions

Frankfurt, Singapore, Tokyo

Method and limitations

Each regional client submitted identical-nonce pairs to BlockRazor and the official endpoint with matching parameters.

The result compares the stated regions and transaction configuration, not every production workload.

Sources verified: 2026-09-22
BaseTransaction Submission
Current

Test date

Base infrastructure benchmark

One report evaluated transaction submission, Block Stream and FlashBlock Stream across three regions.

Earlier transaction position93.93%

Tokyo region

Submission groups
300
Block Stream P50 lead
43ms
FlashBlock P99 lead
290ms
Comparison

BlockRazor vs Base native and P2P paths

Scope

300 submission groups and two 6-hour stream tests

Regions

Frankfurt, Tokyo, Virginia

Method and limitations

Regional clients compared transaction position and timestamp differences for matching blocks and FlashBlocks.

Submission and stream metrics describe different tests and should not be combined into one latency score.

Sources verified: 2026-09-22
SolanaEnd-to-end
Current

Test date

Solana bot end-to-end latency

Server and client deployments measured the path from transaction construction to landing confirmation.

Lowest published client P50118ms

Frankfurt multi-region client

Frankfurt average
142ms
Virginia average
174ms
Tokyo average
263ms
Comparison

Multi-region server and client architectures

Scope

Server, multi-region client and single-region client cases

Regions

Frankfurt, Amsterdam, New York, Tokyo, Virginia

Method and limitations

The benchmark timed transaction construction, submission and landing confirmation with Shred parsing or Yellowstone gRPC.

Client and server results include different network and application layers and should be read separately.

Sources verified: 2026-09-22
SolanaBlock Stream
Current

Test date

Solana Shred Stream vs Jito

Matching Shreds were compared by first arrival and arrival-time difference in four regions.

First-arrival rate97.32%

Tokyo region

Frankfurt
85.25%
New York
84.86%
Tokyo P50 lead
43.6ms
Comparison

BlockRazor Shred Stream vs Jito ShredStream Proxy

Scope

Matching Shreds aggregated in one-minute windows

Regions

Frankfurt, Amsterdam, New York, Tokyo

Method and limitations

Clients received both streams, deduplicated by slot and Shred index, then calculated first arrival and lead-time percentiles.

The test measures Shred delivery timing, not transaction execution or strategy outcomes.

Sources verified: 2026-09-22
SolanaTransaction Submission
Current

Test date

Solana SWQoS transaction race

DurableNonce transactions with equal tips and priority fees compared provider performance on the SWQoS route.

First-to-Leader share39.83%

New York test region

Frankfurt
30.12%
Send interval
1.6s
Route
SWQoS
Comparison

BlockRazor vs multiple Solana RPC providers

Scope

DurableNonce transfers across rotating Leaders

Regions

Frankfurt, New York

Method and limitations

The test held tip and priority fee constant, excluded Jito-landed transactions and compared which provider reached the Leader first.

The result describes the filtered SWQoS route under equal-fee conditions.

Sources verified: 2026-09-22
BSCMempool
Current

Source verified

BSC Public Mempool first arrival

Clients compared reception time for the same public pending transactions from BlockRazor and a regular node.

Lead rate in every region>99%

Four-region comparison

Tokyo average lead
136.4ms
Tokyo P90 lead
218.7ms
Regions
4
Comparison

BlockRazor Public Mempool vs regular node

Scope

Comparable matching public transactions

Regions

Dublin, Frankfurt, Tokyo, Virginia

Method and limitations

For matching transactions, regional clients measured the reception-time difference between BlockRazor and a regular node.

The documentation does not publish a sample count or test date, so the card does not infer either value.

Sources verified: 2026-09-22
BSCBlock Stream
Current

Source verified

BSC NewBlocks reception

Regional clients compared arrival time for the same blocks from BlockRazor and a regular node.

Lead rate in three regions100%

Dublin, Frankfurt and Tokyo

Virginia lead rate
99.5%
Tokyo average lead
239.1ms
Tokyo P90 lead
622.9ms
Comparison

BlockRazor NewBlocks vs regular node

Scope

Comparable matching blocks

Regions

Dublin, Frankfurt, Tokyo, Virginia

Method and limitations

Clients recorded reception timestamps for matching blocks from the regional relay and a regular node.

The documentation does not publish a sample count or test date.

Sources verified: 2026-09-22
BSCNode Stream
Current

Source verified

BSC full-node synchronization

Matched blocks compared nodes connected to BlockRazor Relay with nodes using their existing peer path.

Highest lead rate99.51%

Tokyo region

Tokyo average lead
113ms
Tokyo P90 lead
654ms
Regions
4
Comparison

Relay-connected node vs regular synchronization path

Scope

Matched block samples

Regions

Dublin, Frankfurt, Tokyo, Virginia

Method and limitations

The benchmark compared the same node with and without the BlockRazor Relay peer connection.

The documentation does not publish a sample count or test date.

Sources verified: 2026-09-22
BSCMempool
Historical

Test date

BSC high-performance network

A 24-hour historical comparison evaluated first-seen transactions and blocks against bloXroute.

First-seen transactions at 1-5 ms2x

Tier 1 result stated in the report

Observation window
24h
Core regions
4
Status
Historical
Comparison

BlockRazor Tier 1 and Tier 2 vs bloXroute Enterprise-Elite

Scope

24-hour transaction and block observation

Regions

Virginia, Frankfurt, Dublin, Tokyo

Method and limitations

Physically close clients compared first-seen transactions and blocks across equivalent service plans.

This is a historical 2024 benchmark. Product plans, networks and competitors may have changed.

Sources verified: 2026-09-22

Benchmark methodology

Streams

First-arrival rate
The share of matched events delivered by one source before the comparison source.
Relative latency
The timestamp difference between matched events. The first source is recorded as the 0 ms baseline.

Transaction submission

Same-nonce comparison
Submit competing transactions from the same account with the same nonce, then record which route produces the included transaction.
Block and index comparison
Submit different transactions under matched conditions, then compare block height and transaction index to determine execution order.

Comparable inputs

Tests hold relevant inputs constant, such as nonce, fees, client location or matching block identity.

Regional context

Results identify where clients ran because network path and physical distance materially affect latency.

Distribution, not one average

Where available, P50, P90, P95 and P99 expose the typical case and the slow tail.

Bounded conclusions

Published observations are evidence for the stated test, not a universal SLA or trading guarantee.

Benchmark FAQ

Are these benchmarks live?

No. This first version indexes published test reports and current documentation. Every card displays its test date or states when the date is not published.

How is first-arrival rate calculated?

The same event must be observed from both sources at the same client. The first-arrival rate is the share of comparable matched events delivered by one source before the other.

How should relative latency be read?

For each matched event, the earlier source becomes the 0 ms baseline and the later source receives the timestamp delta. A 0 ms value means first arrival in that pair, not zero end-to-end latency.

Why use the same nonce for transaction submission?

Transactions from the same account with the same nonce compete for one executable position. This makes the included transaction a direct route-level outcome when fees and other parameters are held constant.

When are block height and transaction index compared?

Use this method for different transactions that can both land. The earlier block wins first; if both land in the same block, the lower transaction index indicates earlier execution order.

Which samples should be excluded?

Exclude mismatched events, missing counterparts, failed sends, ambiguous inclusion and rounds where controlled parameters drift. The report should disclose exclusion rules and remaining sample counts.

Test from your own production path.

Use the published results as a starting point, then validate latency and execution with your workload, region and transaction configuration.

Start buildingTalk to us

Summarize this page with AI

ClaudeChatGPTGeminiGrokCopilotPerplexity