Fastest crypto price API, live head lag across 6 data providers

We measure the gap between a transaction settling on chain and the same transaction appearing on each aggregator's data feed. The harness watches reference pools across Base, BNB Chain, Solana and Robinhood Chain from three regions (us-east, eu-west, sgp), records every new on-chain event with millisecond timestamps, and observes when each aggregator's WebSocket reflects the same event.

• ·Aggregators measured: Mobula, Codex, GeckoTerminal and Serialized on all four chains; OKX and Birdeye on Base, BNB and Solana. Neither can scope a subscription to a pool, so both are subscribed per token and matched to the bench pool by transaction hash, their off-pool trades discarded rather than scored. Both send whole-second timestamps, which is why they are measured only on chains whose headline reads a clock we hold rather than the provider's own.
• ·Robinhood Chain carries four of the six feeds. Neither OKX nor Birdeye indexes it, measured rather than inferred: both accept the subscription and then deliver nothing (0 trades in 40 to 45 s, on the pool and on its non-stable leg) while Base and BNB on the same code delivered hundreds. An accepted subscription is not evidence of coverage on either feed.
• ·Chains: Base, BNB Chain, Solana, Robinhood Chain.
• ·Reference on BNB Chain: a node subscription we hold ourselves, every emission matched to it by transaction hash, the ruler Base uses. Until 2026-10-03 the column used each provider's own timestamp, assuming BNB's chain-supplied timestamps sat within roughly 60 ms of a trade becoming observable. Measured, that gap is 569 ms, so the old column tracked block time more than any pipeline: the four feeds sat within 9% of each other, against the common clock they spread over a factor of four.
• ·Solana (since 2026-09-16): the headline is the lag behind the first feed to report the trade, our own node subscription included in the race. Solana has no on-chain timestamp with sub-second precision, so the timestamps providers send compare conventions: Mobula's `date` (its ingestion time) read as a constant 0.10 s, Serialized's `at` (blockTime, whole seconds) as 0.75 s, while against a common clock the two feeds are 10 to 30 ms apart.
• ·Solana zero point: no RPC WebSocket we hold, public or keyed (mainnet-beta, Helius, Alchemy), precedes the providers' geyser feeds, so an absolute zero point is not available and the first observation is the ruler. Our node stays in the race: it validates the hash on chain and bounds the field whenever a feed is slower than a plain RPC subscription.
• ·Race: every feed's arrival for a transaction is compared to the earliest feed's (exactly one feed wins each trade, the earliest arrival, so the shares add up to 100; trades only one feed reported are not scored). Published on every chain as `head_lag_first_share_pct`, the First to report view: the share of the last 24 h of trades a feed reported before every other feed.
• ·Race eligibility (since 2026-10-04): only trades our own pool subscription saw are raced. OKX and Birdeye are subscribed per token and see every pool on it, so the book had filled with trades from pools this bench does not measure, scored as a race between those two alone. After the filter, Solana discards hundreds of thousands of off-pool races an hour and scores of order 100, its rate before those feeds arrived. Feeds seeing only our pool had been divided by a denominator they could not enter.
• ·Consequence for the Solana column: `head_lag_seconds` there is the lag behind the first feed in a race, so it moved with the same fix. Figures published before 2026-10-04 for OKX and Birdeye on that column were measured on a wider set of trades than the other four feeds.
• ·Solana headline: `head_lag_seconds` is the lag behind the first observation of the trade, our node included, floored at 1 ms. GeckoTerminal polls and lands 15 to 100 s later; it is measured against the same first arrival.
• ·Reading the Solana column: the leading feed's figure is the floor, not a measured latency. Whichever feed wins a race has a lag of zero by definition, published as 1 ms so the row renders, and over a recent 30 minutes the leader sat on that floor for 94% of its samples with p50 and p90 both at 1 ms. So the gap between the leader and the next feed is not a speed ratio; it is how far behind the others arrived. Read the leader through First to report and the others through their own lag.
• ·Regions: us-east, eu-west, sgp. Cross-region median reported in the headline.
• ·Reference on Base: two preconfirmation sources held by us in every region, the sequencer's flashblock stream and the sequencer node's `pendingLogs` subscription, with the earliest sighting of each transaction taken as the zero point. A Base block becomes queryable about 0.36 s after the timestamp it carries, while flashblocks publish every 200 ms inside the 2 s interval, so that timestamp is not the moment a trade becomes knowable.
• ·Why Base has two reference sources, since 2026-10-29: the flashblock endpoint is served through a CDN and carries a tail of 170 to 220 ms on its slowest decile. A reference that is late flatters every provider measured against it, and by late October one provider was arriving before our own reference on more Base races than it lost, so the zero point had stopped bounding the field.
• ·Adding that second Base source can only move the zero point earlier, never later, because the clock keeps the first sighting of a transaction and discards the rest. Base head-lag figures published before 2026-10-29 are therefore smaller than the same measurement would be today, by up to the size of that tail. The first-to-report shares are unaffected: that race is between providers, and the reference does not compete in it.
• ·Base emissions we cannot match to a flashblock are dropped rather than measured against a different ruler. Measuring against the block timestamp charged a provider reading preconfirmations with a negative lag, and described the chain's stamping convention rather than the provider's pipeline.
• ·Metric: gauge `head_lag_seconds`, scraped every 30 seconds. Aggregated over the 24-hour window using `quantile_over_time`.
• ·Success rate: presence ratio. Share of expected sampling slots where a value was actually emitted (2,880 expected per provider per day at the 30 s scrape). 100% means the aggregator's feed was reachable for the full window.
• ·Coverage is not the same as presence. Birdeye's stream carries part of the bench pool's flow rather than all of it: 106 of 442 and 13 of 44 pool swaps over two Base windows, about a quarter. Its percentiles therefore describe the trades it does report, and the presence ratio above measures whether the feed was reachable, not how much of the pool it covered.
• ·Cardinality: four aggregators on four chains plus two on three (OKX, Birdeye) is 22 aggregator-chain pairs × 3 regions = 66 active series.
• ·Probe placement: the three probes run in their named regions on Railway (europe-west4, us-east4, asia-southeast1). Until 2026-09-15 all three ran in asia-southeast1 under regional labels; region columns before that date are three Singapore vantage points.
• ·Codex endpoints: the Solana subscription reads Codex's Frankfurt edge node (`fra.edge.codex.io`) from all three regions; Base, BNB Chain and Robinhood Chain read the standard `graph.codex.io` endpoint. Solana and Base subscribe at Codex's Processed commitment level (on Base, the flashblock preconfirmation the Base reference also reads); BNB Chain and Robinhood Chain at the default.
• ·Codex auth: the harness authenticates with an API key Codex supplied for this bench. Earlier figures read every chain from `graph.codex.io` with a token minted from a defined.fi web session, Base at the default commitment level.