Solana Shreds, RabbitStream, Yellowstone gRPC – What Each One Actually Delivers

A developer’s guide to Solana’s data pipeline – from raw shreds to RabbitStream’s partial transactions to Yellowstone gRPC’s full meta.

If you’ve spent any time in Solana infra Discords, you’ve probably seen these three terms used almost interchangeably – Shreds, RabbitStream, Yellowstone gRPC. They’re related, but they’re not the same layer, the same abstraction, or the same product. Mixing them up leads to real confusion: developers expecting shred-level raw data from RabbitStream and getting confused when they see full transactions (without meta), or expecting Yellowstone gRPC’s semantics from RabbitStream’s gRPC interface.

Let’s untangle it.

Shreds: the raw material, not a product

A shred is a fragment of a block. Before a block is even finalized, validators break it into small packets – shreds – and gossip them across the network via Turbine Protocol. This happens before Replay, before voting finishes, before anything resembling a “transaction” as most developers think of it is assembled.

Shreds are not transactions. They’re erasure-coded pieces of raw ledger data. To get anything usable – an actual instruction, a token transfer, a swap – those shreds need to be collected, ordered, and reconstructed into entries and transactions. That reconstruction step is the whole game, and it’s where the real engineering difficulty lives: non-deterministic arrival order, missing pieces that need erasure-code recovery, and no explicit tx_index field anywhere in the data – ordering is purely positional.

So when someone says “give me shreds,” what they usually mean is the earliest possible signal – before anyone else has it. What they usually need is a reconstructed transaction, just delivered at shred speed.

Use-cases of Raw Shreds

That said, raw shreds do have a real use case – just a narrower one than most people assume. They’re useful when:

→ You’re running self-hosted RPC infrastructure and want to build your own path from network broadcast to block state, rather than relying on someone else’s reconstruction.

→ You’ve already built your own decoding and filtering engine and want raw input to feed it. This involves a lot of engineering time and effort.

RabbitStream: shred-speed delivery, partial transaction output

This is the point that gets lost most often: RabbitStream does not hand you raw shreds. It consumes shreds from multiple upstream sources and reconstructs them into ordered, partial transactions – entirely separate from any RPC node – and streams that reconstructed data out to you. The reconstruction happens at the shred stage, before Replay/banking stage, which is why RabbitStream is faster than anything sourced from the Yellowstone plugin that has already replayed the transaction.

It’s also worth being explicit about the architecture: RabbitStream is not a geyser plugin running inside a Solana RPC node. That’s how Yellowstone gRPC works – it’s a plugin attached to a validator, streaming out what that validator processes. RabbitStream doesn’t sit inside an RPC node at all; it reconstructs directly from shred sources, independently of any RPC.

Three things worth being precise about here:

→ The source is shreds, not RPC. RabbitStream taps the shred layer directly – not RPC, not a Geyser plugin on a validator. This is what gives it its speed advantage: it doesn’t wait for a block to be replayed and confirmed before data moves.

→ The output is a partial transaction, not a full record. Reconstruction is RabbitStream’s job, not yours – you’re not stitching fragments together client-side. By the time data reaches you, it’s an assembled transaction with signatures, message, instructions, decoded and ready to consume. But it’s partial: it won’t have post-execution meta like logs, compute units consumed, balance deltas, success/failure status. That data is only generated once the transaction is actually replayed, and RabbitStream operates before that stage by design. That’s the trade-off for shred-speed delivery.

Another thing to note is that RabbitStream has built-in ALT resolution. It resolves lookup tables used int he transaction and also applies account_include/required filters against resolved lookup addresses. This enables RabbitStream to reach a 99% coverage match when compared to Yellowstone gRPC output.

Note: RabbitStream delivers its data through a Yellowstone-style gRPC interface – same familiar schema and integration pattern developers already know. That’s a delivery choice, not a pipeline claim. The interface looking like Yellowstone’s doesn’t mean the data was sourced or reconstructed the same way; RabbitStream is still shred-sourced and pre-Replay underneath (no meta), regardless of the interface it’s exposed through.

Use-cases of RabbitStream

RabbitStream is the right fit when speed matters more than execution results – when you need to react to a transaction’s existence and contents before it’s confirmed, not to how it turned out. That’s useful when:

→ You’re sniping or racing on new transactions: new pool creations, large swaps, listings – where being first to see the instruction matters more than knowing whether it succeeded.

→ You’re building MEV or latency-sensitive strategies that act on transaction intent (what a transaction is trying to do) rather than transaction outcome (what actually happened after execution).

→ You don’t need meta at all: your logic runs off signatures, instructions, and accounts touched, and logs, compute units, or balance deltas aren’t part of the decision.

If your use case depends on knowing whether a transaction actually succeeded, or needs post-execution numbers, that’s a signal you need Yellowstone gRPC instead – not RabbitStream.

Yellowstone gRPC: post-Replay, account-and-transaction state via Geyser

Yellowstone gRPC sits downstream of Replay. It’s a Geyser plugin running inside a Solana RPC node – an interface that streams account updates and full transaction data, meta included, after the RPC has replayed and confirmed them. It’s not sourced from shreds; it’s sourced from validator state, after Replay generates the transaction meta.

This is a meaningfully different pipeline from RabbitStream, not just a different speed tier. Yellowstone gRPC gives you broader coverage – account state, not just transactions. RabbitStream trades some of that breadth for shred-stage speed.

Use-cases of Yellowstone gRPCs:

Yellowstone gRPC is the right fit when you need the complete picture, not just the earliest signal. That’s useful when:

→ You need to know outcomes, not just intent: whether a transaction succeeded or failed, what it actually changed, not just what it was trying to do.

→ Your logic depends on execution meta: logs, compute units consumed, balance deltas – for indexing, analytics, accounting, or building an accurate historical record.

→ You need account state alongside transactions: tracking how a program’s or wallet’s on-chain state changed, not just which transactions touched it.

In practice, this maps to a specific set of builders:

→ Indexers and data platforms: anything backfilling or serving historical, queryable on-chain data needs meta to know what actually happened, not just what was attempted.

→ DEX and portfolio trackers: computing real fill prices, P&L, or wallet balances requires the post-execution numbers, not the pre-trade instruction.

→ Block explorers: showing transaction status, logs, and balance changes to a user is inherently a meta-dependent view.

→ Aggregator and router analytics: seeing which pools an aggregator actually routed through means reading inner instructions, which only exist in meta.

→ Accounting, compliance, and reporting tools: anything that needs a verifiable record of what succeeded, failed, or changed state.

If speed matters more than completeness, that’s the signal to look at RabbitStream instead.

	Shreds	RabbitStream	Yellowstone gRPC
Source	Raw network broadcast (Turbine/Validators)	Shreds, from multiple upstream sources	Validator state, via Geyser plugin
Pipeline stage	Before Replay / banking stage	Before Replay / banking stage	After Replay
Runs inside an RPC node?	No – network layer	No- reconstructs independently of any RPC	Yes – Geyser plugin inside an RPC node
Output shape	Raw data fragments, not usable directly	Reconstructed, ordered transaction (signatures, message, instructions)	Full transaction, meta included
Includes execution meta?	No	No – meta is generated at Replay, which hasn’t happened yet	Yes – logs, compute units, balance deltas, status
Speed profile	Earliest possible signal, but unusable raw	Shred-speed, reconstructed and usable	Slower – waits for Replay/confirmation
Delivery interface	N/A – raw protocol data	Yellowstone-style gRPC interface	Yellowstone gRPC
Best fit	Self-hosted RPC infra, custom decoding/filtering engines	Fast, reconstructed transactions without needing meta	Full transaction + account state, meta required

The interface trap: gRPC ≠ Yellowstone gRPC

Here’s the part that trips people up even after they understand the pipeline difference: RabbitStream may expose data through a gRPC interface – that does not make it Yellowstone plugin. gRPC is a transport protocol and interface style, not a product. Two services can both speak gRPC and be built on completely different data sources, pipelines, and guarantees.

RabbitStream’s delivery interface has been kept similar to Yellowstone for developer convenience.

Getting the Mental Model Right

Most of the confusion here isn’t about Solana’s infrastructure being complicated – it’s about collapsing three separate questions into one. Where does the data come from (shreds, pre-Replay, vs. validator state, post-Replay) is a different question from what shape is it in when it reaches you (raw fragments vs. reconstructed transactions), which is a different question again from how is it delivered (a gRPC interface, which is just a transport choice).

RabbitStream answers all three specifically: shred-sourced, independently reconstructed, delivered fast. Yellowstone gRPC answers them differently: validator-sourced, post-consensus, broader in scope. Neither is a subset or a raw version of the other – they’re built for different points in the pipeline, and the right one depends on whether your use case needs shred-stage speed or Replay-confirmed breadth.

Once source, shape, and transport are separated out, “isn’t RabbitStream just shreds?” and “isn’t that just Yellowstone?” stop being trick questions.

If you liked this article, feel free to checkout our other articles on what is RabbitStream or how RabbitStream differs from Solana Yellowstone gRPC to find out more.

Resources

• Shyft Website
• Get Free API Key
• GitHub
• Join our Discord