Shredstream vs Yellowstone gRPC: raw timing or processed context
Shredstream and Yellowstone gRPC expose different moments in the Solana data path. Shredstream pushes raw leader shreds over UDP before a validator finishes executing the slot. Yellowstone gRPC streams processed validator updates with filters, transaction status, logs, account changes, and commitment context. That makes Shredstream the earlier signal and gRPC the easier application interface. The earlier feed also asks more of you. Your receiver must rebuild entries, remove duplicate packets, track incomplete sets, and treat every observation as fork-sensitive. Yellowstone handles the validator work first, then gives your client structured protobuf messages. Many trading systems use both. Shredstream feeds the time-sensitive detection path while gRPC confirms execution and updates state.
Streamed events and instructions
every event the program emits, decoded and ready to consume
| Event | Type | Description | Frequency |
|---|---|---|---|
| Leader shreds | event | Shredstream exposes raw block fragments before validator execution finishes. | — |
| Deshredded entries | event | Your receiver reconstructs entries and transactions from sufficient shred sets. | — |
| Duplicate packets | event | Your Shredstream client must identify repeated UDP packets. | — |
| Fork observations | event | Early shred data can belong to a branch that Solana later abandons. | — |
| Processed transactions | event | Yellowstone emits transaction updates after the validator executes them. | — |
| Account updates | event | Yellowstone can filter and stream changed account state. | — |
The data stages compared
last reviewed 2026-07-28
The practical difference
| Dimension | Shredstream | Yellowstone gRPC |
|---|---|---|
| Timing | Before validator execution | After validator processing |
| Transport | Raw UDP push | Bidirectional gRPC stream |
| Payload | Data and coding shreds | Structured protobuf updates |
| Filtering | You decode and filter | Subscription filters |
| Execution metadata | None | Status, logs, balances, accounts |
| Commitment | None | Processed, confirmed, or finalized |
| Duplicates and forks | You handle them | Validator and client context |
| Engineering effort | High | Moderate |
Where each feed enters the path
Solana's official documentation says, “Turbine is Solana's block propagation protocol.” Read the Turbine documentation for the protocol detail.
Earlier does not mean final. A shred can belong to a fork that loses. A transaction can also fail during execution. Yellowstone gives you the later context needed to tell those cases apart.
Payload and engineering work
A Shredstream receiver maintains state by slot and shred index. It uses coding shreds to recover missing data where possible, rebuilds entries, decodes transactions, removes duplicates, and expires abandoned forks.
A Yellowstone client sends a subscription request and consumes typed updates. The open source Yellowstone gRPC repository defines those filters and protobuf messages.
What you do not get from raw shreds
You do not get execution logs, balance changes, an error field, compute units, account updates, or commitment. That missing context is a property of the stage, not a client defect.
Choose by workload
Use Shredstream for time-sensitive opportunity detection when your team can run a production deshredder. Use Yellowstone for indexers, alerts, account watchers, analytics, and trading logic that needs execution results.
Use both when detection and confirmation have different latency needs. Keep the two paths independently observable so a gap in one feed does not silently corrupt your state.
Ultra includes one Shredstream destination and access to Yellowstone gRPC.
Frequently asked questions
Related products
Run the early and processed paths together
Ultra includes one Shredstream destination plus Yellowstone gRPC access. The same access is available during the Ultra trial.