Racing multiple block feeds: how we deliver the earliest copy of every Robinhood block

Most block feeds are a single socket to a single source. You open one connection, the source pushes each new block as it sees it, and your application acts on what arrives. It is simple, and most of the time it is fine. The problem is the part that is not most of the time: the moment that one source stalls, reconnects, garbage-collects, or simply sits a beat behind whoever else saw the block, your application sits there with it. You are not slow because the chain is slow. You are slow because you tied yourself to one observer of the chain and inherited its worst moments.

For a trading or settlement backend reading the Robinhood Chain, those worst moments are exactly the ones that matter. A feed that is first on average but occasionally last is not an average problem — the late blocks are where decisions go wrong. This post is about the change we shipped to remove that single-observer penalty: we stopped trusting one feed and started racing several.

Why a single block feed leaves time on the table

A block exists on the network before any one feed hands it to you. Between the moment a block is produced and the moment it reaches your socket there is a relay path: the source observes the block, serializes it, and writes it down its connection to you. Every source has its own path, and those paths are not equal from where you sit. One may sit a short hop from the producer; another may be closer to your region; a third may be busy flushing an earlier message when the new block lands.

With one feed you get exactly one of those paths, chosen once, forever. You cannot tell whether the block you are holding is the earliest copy that existed or the last. You cannot tell whether a two-beat gap was the chain being quiet or your source being behind. And when that source drops — every long-lived socket eventually drops — you get nothing at all until it reconnects and replays, if it replays. The single feed is not wrong; it is just a single point of both delay and failure, and you have no second opinion.

Racing several feeds and keeping the earliest copy

The fix is to stop choosing one path in advance. We now open several independent block-feed sources in parallel for the Robinhood Chain feed: the standard public sequencer feed alongside other independent observers of the same chain. Each source streams the same blocks; what differs is which one hands you a given block first.

Every block carries a monotonic sequence number, and that is the key we deduplicate on. As copies of a sequence arrive from the different sources, the first copy wins: we forward it to your subscription immediately and mark that sequence seen. Every later copy of the same sequence — from the slower sources — is dropped on arrival. Your application sees one clean, in-order stream; under the hood it was a race, and you always received the leg that finished first.

The sources that lose the race are not idle. They stay connected, and because they are already streaming, they are live fallback: if the source that usually wins stalls or drops, the next copy of the next sequence simply comes from whichever source is now first, with no reconnect, no gap, and no change on your side. Resilience here is not a separate failover system that has to detect a failure and switch; it is a property of running the race continuously. The standard public feed remains one of the racers, so nothing about the data you receive changes — same blocks, same format, same ordering — only the arrival time of each block improves to the best of what was available.

A detail that matters in production: more sources does not mean more noise for you. Deduplication happens before anything reaches your subscription, so a client on a racing feed and a client on a single feed read byte-identical blocks in the same order. The difference is only in timing and in what happens on a bad minute.

What we measured

We turned the racing feed on at two edges and watched which source delivered each block first, counted over live traffic rather than a synthetic test.

On our EU edge, the racing path delivered the block first on about 99.7% of blocks, measured against the standard public feed as the baseline. When it won there, it was earlier by a median of roughly 62 milliseconds, about 112 milliseconds at the 90th percentile and about 138 milliseconds at the 99th — so on the blocks that would otherwise have been slowest, the racing feed was ahead by more than a tenth of a second. For the overwhelming majority of blocks, an independent source handed us the block before the public feed did, and that is the copy your subscription received.

On our North American edge the picture is different, and it is worth being honest about: the public feed sits close to us there, so the two run nearly even at the median (the public feed a few milliseconds ahead), and the racing path wins the minority of blocks — the slow tail — where it is earlier by up to about 98 milliseconds at the 99th percentile. Both outcomes are the point. Where another source is ahead, you get its copy; where the public feed is ahead, you get that; you are never pinned to the loser, and the worst-case blocks are the ones the race helps most.

Throughout, the public feed stayed connected and in sync as a fallback on both edges, with the running sequence advancing and no gaps introduced by the race. The win-rate split is a live number from our own metrics, not a one-off benchmark, and it moves with network conditions and routing — which is exactly why racing beats choosing one path up front.

When this is the wrong approach

Racing feeds buys you one thing: the earliest copy of a block that already exists, plus resilience when a source misbehaves. If that is not your bottleneck, it is the wrong tool.

If you need deterministic, single-source ordering for audit or replay — where the requirement is "exactly what this one named source said, in its order" — a race is the wrong model, because the whole idea is that the winning source varies block to block. Pin a single feed instead.

If you only act on finalized or confirmed state rather than on each block as it appears, the earliest copy gains you nothing: you are going to wait for confirmation anyway, and a plain single feed, or periodic JSON-RPC polling, is simpler and cheaper. See finality and commitment levels across chains for where that line sits.

If you need history — a block from last week, an account's past state, a proof at an old height — a live feed of any kind is the wrong surface entirely; that is an archive read over JSON-RPC, and racing live sockets does not touch it. And if your constraint is cost on a free or near-free tier, the plumbing that keeps several sockets warm is not where you should spend; a single feed is the economical choice.

Racing earns its keep when you act on fresh blocks, when the slow tail costs you, and when a dropped socket must not become a gap. That is the profile of a payments or trading backend, and it is who we built this for.

How to connect

Nothing in how you connect changes. The racing feed is served on the same Robinhood Chain endpoint with the same API key; you subscribe the same way and read the same blocks, now delivered from whichever source is first. The connection details, archive depth and the feed's place in the product are in the Robinhood Chain docs, and the full set of real-time channels we run — which transport each uses and how to resume after a drop — is in the streaming overview. The product summary and pricing for the chain live on the Robinhood Chain RPC page.

Sources

• Triport production metrics, EU and North American edges, 2026-10-23: per-source first-copy win counters and per-sequence lead-time quantiles (median, p90, p99) over a rolling window on the Robinhood Chain block feed, with the standard public feed held connected as fallback and the running sequence advancing with no gaps.
• Robinhood Chain documentation, read 2026-10-23: endpoints, archive depth and block-feed behaviour.
• Triport streaming overview, read 2026-10-23: the real-time channels we operate, the transport each uses, and resume behaviour after a disconnect.
• Finality and commitment levels across chains: when you should wait for confirmation instead of acting on the earliest block.