Robinhood Chain Sequencer Feed is live. Receive ordered blocks earlier with Node-required Ultra or Direct Ultra access.
Get Started
Sign in
Create Account

Robinhood Chain Feed Benchmark: BlockRazor vs Eira Nodes

BlockRazor Robinhood Chain Sequencer Feed benchmark

In the benchmark conducted on October 3, 2026, BlockRazor and Eira Nodes produced 1,129 matched Robinhood Chain feed events. BlockRazor delivered 61.12% first, compared with 38.88% for Eira Nodes, and recorded lower relative latency from P50 through P99. In the large-payload sample, BlockRazor led Eira on 77 of 80 blocks larger than 50 KB, a 96.25% head-to-head win rate.

Key results

  • Overall sample: 1,129 matched events
  • First arrival: BlockRazor 61.12%, Eira Nodes 38.88%
  • P95: 0.312 ms vs. 0.956 ms
  • P99: 0.568 ms vs. 1.492 ms
  • Payloads over 50 KB: BlockRazor 77/80 (96.25%), Eira Nodes 3/80 (3.75%)

Benchmark methodology

The benchmark client ran in the AWS US East (Ohio) Availability Zone identified as use2-az2. One client maintained simultaneous connections to BlockRazor Direct Sequencer Feed Ultra over WebSocket JSON and Eira Pulse at the RECEIVED commitment level over gRPC. Eira's gRPC runtime produced a structured update without application-level JSON deserialization; BlockRazor's native-compatible WebSocket JSON was parsed with ByteDance Sonic. Both feeds were timestamped when the event became client-ready, then matched by block height.

High-Performance JSON Parsing

Go clients connecting to the Robinhood Chain Direct Sequencer Feed can use ByteDance Sonic to parse JSON messages received over WebSocket. Sonic uses JIT compilation and SIMD acceleration to reduce parsing latency and CPU overhead in latency-sensitive trading systems.

In our benchmarks, Sonic achieved a P50 JSON parsing latency of approximately 2–3 microseconds. Actual performance may vary with message size, data structure, CPU architecture, and runtime environment. We recommend benchmarking with real feed data and warming up commonly used Go types before processing latency-sensitive traffic.

Our current reference implementation is written in Go. For trading strategies written in Rust, C++, or other languages, developers can use this latency as a reference when selecting and benchmarking an equivalent high-performance JSON parser.

For each matched event, the earlier source was assigned 0.000 ms; the other source shows the difference between the two client-ready timestamps. The result therefore includes each product's required ingestion path. It is not a raw transport-only or sequencer-to-client latency measurement.

Overall latency results

SourceCountWin rateP50P70P80P90P95P99
BlockRazor1,12961.12%0.000 ms0.050 ms0.134 ms0.236 ms0.312 ms0.568 ms
Eira Nodes1,12938.88%0.064 ms0.212 ms0.302 ms0.541 ms0.956 ms1.492 ms

Across 1,129 matched events, BlockRazor's 61.12% win rate was 22.24 percentage points higher than Eira Nodes' 38.88%. At P95, BlockRazor recorded 0.312 ms versus Eira's 0.956 ms—a 0.644 ms, or 67.36%, reduction. At P99, BlockRazor recorded 0.568 ms versus 1.492 ms—a 0.924 ms, or 61.93%, reduction.

Large-payload results: BlockRazor led on 96.25%

When onchain market activity increases, large payloads commonly arrive in consecutive runs rather than as isolated messages, making sustained large-payload performance particularly relevant during market peaks. This sample contains 80 consecutive matched blocks, from block 79165757 through 79165836, with payload sizes ranging from 65.16 KB to 124.54 KB.

Payload scopeMatched blocksBlockRazor firstEira Nodes firstBlockRazor win rate
More than 50 KB8077396.25%

For the 77 blocks won by BlockRazor, the lead is calculated as Eira relative latency minus BlockRazor relative latency. Percentiles use the nearest-rank method: the 77 lead values are sorted, and percentile p is taken from rank ⌈p × 77⌉; P95 is therefore the 74th sorted value.

Winning samplesMean leadP50P70P80P90P95P99
770.618 ms0.495 ms0.804 ms0.977 ms1.152 ms1.510 ms2.113 ms

BlockRazor led by at least 0.5 ms on 38 of 77 winning blocks (49.35%) and by at least 1 ms on 13 blocks (16.88%). This distribution shows that the WebSocket JSON path maintained a consistent client-ready advantage across the large-payload sample.

What this means for trading systems

Lower feed latency preserves more time for the rest of the trading path:

receive earlier → parse and filter earlier → evaluate earlier → construct and simulate earlier → submit sooner

This advantage is most relevant to sniping, copy trading, address monitoring, and real-time signal systems. Feed selection should also consider event coverage, reconnect behavior, message integrity, regional consistency, protocol compatibility, and operational support.

Frequently asked questions

Why is BlockRazor P50 shown as 0.000 ms?

The source that became client-ready first for a matched event was assigned zero relative latency. It does not mean the full sequencer-to-client path took zero time.

Is comparing gRPC with WebSocket JSON fair?

The protocols are different, so this is not a protocol-neutral raw-byte test. It compares the practical point that matters to strategy code: when a structured event is ready to use. Eira includes gRPC/Protobuf decoding; BlockRazor includes Sonic JSON parsing.

Why use Sonic?

BlockRazor remains compatible with the native WebSocket JSON subscription model. Sonic reduces the additional JSON parsing cost while retaining that compatibility, and its parsing time is included in the reported BlockRazor results.

Test BlockRazor in your environment

Review the BlockRazor Robinhood Chain products, read the Direct Sequencer Feed Ultra integration guide, and compare the feeds from the region where your strategy runs. For another comparison against the official Robinhood Chain feed, see the BlockRazor Sequencer Feed benchmark. For access and integration support, contact BlockRazor.

Subscribe to BlockRazor

Stay current with our latest blockchain infrastructure research and receive new posts in your inbox.