The Solana Data Latency Stack: Six Tiers, Real Numbers

The Solana data ecosystem is a marketing fog. Every provider claims "low latency," "real-time," "ultra-fast." None of them are lying. They are all measuring different things, at different points in the pipeline, against different baselines.

If you are picking a data source for a Solana trading bot, an indexer, a sniper, or an analytics pipeline, you are not picking between fast and slow. You are picking which point on the timeline you want to see the data. The earlier you sit, the rawer the bytes and the more decoding work falls on you. The later you sit, the cleaner the API and the more strategies you have already lost.

This is the stack, ordered by where the data lives on the timeline. Numbers are measured against raw UDP shreds as the reference point.

One tier per section. What it is, where the latency comes from, when it is the right call.

Tier 1: Raw UDP shreds

A shred is a 1232-byte UDP packet. Solana leaders split each block into shreds as they build it, FEC-encode them for loss tolerance, and broadcast them over Turbine. They are the earliest form in which Solana state exists outside the leader.

If a service hands you raw UDP shreds, you are sitting as close to the wire as anyone non-validator can. There is nothing faster. The price is engineering: shreds are not transactions. To extract a signal, you reassemble shreds by slot, recover missing pieces from FEC parity, and deserialize the resulting bytes into entries. Open-source decoders exist; the work is contained, typically a developer-week.

Right call for: pump.fun snipers, atomic arbs, backruns, any strategy where 50 ms of head start changes the win rate.

Tier 1b: gRPC-wrapped raw shreds

Same shreds, repackaged into a gRPC stream. The data is identical to tier 1 but the transport adds framing, TCP, and TLS overhead. You skip the UDP socket plumbing on the client side at the cost of a few extra milliseconds and a heavier dependency.

We benchmarked this directly: 16,523 dual-observed slots, raw UDP wins 98.84% of races, +8.5 ms p50 lead over gRPC-wrapped shreds. Same source, same data, different transport. The gap is small in absolute terms and decisive in latency-sensitive races.

Right call for: teams that want shred-layer latency but cannot or will not run a UDP listener and shred decoder.

Tier 2: Server-side deshredded entries

The provider runs the deshredding pipeline server-side and ships you decoded entries over a Yellowstone-compatible gRPC interface. Helius LaserStream is the canonical example. The client gets clean transactions out of the box; the latency cost is the provider's deshredding pipeline plus gRPC transport, typically 5 to 10 ms over raw shreds.

This tier is significantly faster than tier 5 (vanilla Yellowstone) because the ingestion is at the shred layer, not the Geyser-plugin entry layer. The client API looks identical, but the source is upstream.

Worth flagging: a recent bench between a popular raw-shred provider (with the JavaScript deshredder they recommend) and Helius LaserStream showed LaserStream winning 76% of races. Raw shreds without a fast deshredder are slower than tier 2. Decoder speed matters more than transport speed below ~10 ms.

Right call for: trading bots that need decoded entries fast and do not want to maintain a shred decoder. Same engineering surface as Yellowstone gRPC, with the latency floor of a shred-layer provider.

Shredline DESHRED sits in this tier when it ships. Same upstream as Shredline RAW, decoded server-side on a hot path tuned for minimum added latency.

Tier 3: Premium RPC reads

Direct JSON-RPC calls to a dedicated premium endpoint. Helius standard RPC measures around 1 ms read RTT from a colocated client; the read itself is fast, but the data you get back has already been confirmed on-chain, meaning it is at least one slot stale by construction.

Latency here is two numbers, not one: the call's round-trip is sub-ms on a good network; the data freshness is post-confirmation, ~400 ms behind raw shreds.

Right call for: state lookups, account snapshots, transaction status polling, anything where you need a single deterministic answer about confirmed state and not a stream.

Tier 4: Mid-tier RPC

Same shape as tier 3 with weaker hardware, looser rate limits, and shorter history horizons. Shyft's free tier sits here: ~35 ms read RTT, 10 req/s rate limit, transaction history limited to roughly four days.

Right call for: indexers and analytics pipelines where read latency does not affect competitiveness, and where the cost ceiling matters more than the latency floor.

Tier 5: Yellowstone Geyser gRPC

This is the tier most "Solana real-time data" providers actually sell. Yellowstone Geyser is a Solana validator plugin that emits processed and confirmed entries over a gRPC stream. Chainstack, Triton, and vanilla self-hosted Yellowstone all live here.

The latency floor is structural and brutal: 200 to 400 ms behind raw shreds, depending on whether you subscribe to processed or confirmed level. The cause is the protocol itself. Shreds are emitted by the leader; the receiving validator must reassemble them, the Bank must execute the transactions, the cluster must vote, the supermajority must confirm. Each step is independently fast. They stack.

No Yellowstone provider can close this gap. It is not an implementation problem. It is where the data lives on the protocol's clock.

Right call for: dashboards, post-block indexing, alerting on confirmed events, anything that does not race other bots for the same opportunity.

Tier 6: Enrichment WebSockets

The slowest tier and the easiest to misuse. Pump.fun enrichment feeds, NATS-style aggregated streams, dashboard-style WebSockets. They aggregate post-confirmation data with derived metrics (sniper count, holder count, liquidity deltas) and ship enriched events to subscribers. Useful payloads, but the freshness baseline is post-confirmation: 400 to 550 ms behind raw shreds, sometimes more depending on the aggregation window.

Right call for: enrichment, analytics, scoring, anything where the enriched signal is the value and the latency is acceptable because the data is downstream of the race anyway.

Wrong call for: detection. If your strategy depends on being the first to react to a new mint, a new pool, or a new transaction, using a tier 6 enrichment feed for detection means you have already lost the race before the event reaches you.

Where Shredline sits

Shredline ships at tier 1 (RAW) and tier 2 (DESHRED). RAW is for teams that want the shortest possible pipeline and own their decoder. DESHRED is for teams that want decoded entries with the latency floor of a shred-layer provider.

Both bypass the approval and SDK ceremonies that sit between a Solana team and the shred layer today. Wallet-to-wallet billing, multi-region coverage, no signup, no KYC.

Frequently asked questions