Comparison

Solana gRPC vs ShredStream

Both are marketed as low-latency Solana data. They tap the pipeline at different points, which is the only comparison that actually matters.

The pipeline, in order

A transaction becomes observable in stages, and every data product is a tap on one of them. Understanding the order tells you the answer before you benchmark anything.

The leader packs transactions into entries and shreds them onto the wire. Peers receive shreds and reconstruct entries. The validator replays and processes those entries against its bank. Geyser plugins fire on that processed state. RPC nodes then serialise, encode and publish over websockets or REST.

You cannot be faster than the stage you are tapping. A gRPC feed cannot beat a shred feed by optimising its transport, because it is downstream by construction.

Tap pointProductTypical lagPayload
Leader broadcastShredStream~1 msRaw shreds
Post-processingGeyser / Yellowstone gRPC80–120 msProtobuf events
Post-serialisationRPC websocket200–400 msJSON
On requestgetTransaction polling300 ms+JSON

What gRPC gives you that shreds do not

Structure. A Yellowstone gRPC feed hands you decoded account updates and parsed transactions with the validator's interpretation already applied. You subscribe with filters, you get typed messages, and you can be productive the same afternoon.

Shreds give you none of that. You receive fragments and you own everything downstream: reassembly, FEC recovery, deserialisation, and deciding what a partially observed slot means. That is real engineering work.

If your strategy tolerates a hundred milliseconds, gRPC is the more sensible product and we will say so plainly. Buying a shred feed to run a strategy that reacts in seconds is money spent on latency you are not using.

What shreds give you that gRPC cannot

Time inside the slot. Because shreds are broadcast during block production, you can observe a transaction while the block containing it is still being assembled. No downstream product can offer that, because at the moment you see the shred the processed state those products report on does not exist yet.

For anything competing on ordering — sniping a launch, racing a liquidation, quoting against flow — that window is the entire product. For everything else it is an expensive luxury.

Cost and operational shape

Commercial gRPC endpoints typically bill per month with tiered message limits, and throttle exactly when the network is busiest. Our shred feed is a flat 0.3 SOL per day with no metering, and the only thing you operate is a UDP socket — no connection to keep alive, no reconnect logic, no credential in the hot path.

Many desks run both: gRPC for state and accounting, shreds for the reaction path. They answer different questions and the combination is cheaper than trying to make one product do both jobs.

Frequently asked

Is Yellowstone gRPC the same as Geyser?
Yellowstone is a widely used implementation of the Geyser plugin interface that exposes updates over gRPC. Both tap the validator after it has processed an entry, so both sit downstream of the shred broadcast.
Can I use gRPC and ShredStream together?
Yes, and most serious desks do. Shreds drive the reaction path where ordering decides the outcome; gRPC or RPC drives state, reconciliation and anything that needs the validator's interpretation rather than raw bytes.
Which is cheaper?
It depends on volume. Metered gRPC plans look cheap until a congested day, which is when they throttle and when you care most. Our flat 0.3 SOL/day never meters — 8.55 SOL for a month, 97.2 SOL for a year.

Measure it against your own bot

Twenty-four hours of raw shreds from New York and Frankfurt for 0.3 SOL. All we need is an IP and a port.

Keep reading