
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
| Source | Count | Win rate | P50 | P70 | P80 | P90 | P95 | P99 |
|---|---|---|---|---|---|---|---|---|
| BlockRazor | 1,129 | 61.12% | 0.000 ms | 0.050 ms | 0.134 ms | 0.236 ms | 0.312 ms | 0.568 ms |
| Eira Nodes | 1,129 | 38.88% | 0.064 ms | 0.212 ms | 0.302 ms | 0.541 ms | 0.956 ms | 1.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 scope | Matched blocks | BlockRazor first | Eira Nodes first | BlockRazor win rate |
|---|---|---|---|---|
| More than 50 KB | 80 | 77 | 3 | 96.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 samples | Mean lead | P50 | P70 | P80 | P90 | P95 | P99 |
|---|---|---|---|---|---|---|---|
| 77 | 0.618 ms | 0.495 ms | 0.804 ms | 0.977 ms | 1.152 ms | 1.510 ms | 2.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.