# RabbitStream Overview

Speed is everything on Solana. For sniping bots, MEV searchers, and high-frequency trading systems, the earliest possible transaction signal is the edge. That signal lives in <mark style="color:yellow;">shreds</mark>.

#### What are Shreds?&#x20;

When a block leader produces a block on Solana, it doesn't broadcast the full block, but breaks it into small, fixed-size packets called **shreds** — roughly 1,228 bytes each — and propagates them across the network via the **Turbine** protocol.&#x20;

Shreds are the earliest form of transaction data on Solana. They exist before any RPC node has processed anything, before any program has been executed, and before any logs have been written.

While shreds provide the <mark style="color:yellow;">earliest transaction signal</mark> on Solana, they <mark style="color:yellow;">don't</mark> carry the <mark style="color:yellow;">final execution details</mark> — like logs and confirmed results (Transaction `meta`) — still they contain enough information to power speed-critical strategies.

{% hint style="success" %}
[<mark style="color:green;">RabbitStream</mark>](https://shyft.to/solana-shreds-rabbitstream) extracts transactions directly from <mark style="color:yellow;">raw UDP shreds</mark> from multiple sources —
\
independently of any RPC node — and delivers them through a Yellowstone-compatible gRPC interface. The RPC is never in the picture.
{% endhint %}

#### The Problem with Raw Shreds

While raw shreds offer unbeatable speed, working with them have their own challenges for developers:

* **Filters not available, Data Overload**: Shreds arrive as a firehose, meaning you get *every single transaction* on Solana—even the internal voting and failed ones—which creates a huge data load that's hard to handle. There is no way to isolate a
  &#x20;specific program or account.
* **Complex Decoding**: The data <mark style="color:yellow;">structure</mark> of raw shreds is <mark style="color:yellow;">complex and binary-encoded</mark>, making them incompatible with standard Solana parsing libraries and requiring custom, time-consuming decoding logic.
* **Missing Transaction Context:** Since shreds are unconfirmed, they lack the full transaction metadata (meta), including program logs, inner instructions, and pre/post token balances. This limits them primarily to simple sniping strategies.
* **High Expense:** Few providers offer raw/decoded shred streams, and those that do are often priced out of reach for independent developers and smaller teams.

### Introducing RabbitStream: Shred Speed, gRPC Usability

RabbitStream is a <mark style="color:yellow;">real-time</mark> transaction stream that delivers data directly from raw UDP shreds — before transactions ever hit the RPC.

It <mark style="color:yellow;">does not run as a plugin</mark> inside a validator. Instead, it listens directly to <mark style="color:yellow;">raw UDP shreds from multiple sources</mark> as they propagate across the Solana network, performing its own shred reconstruction and validation independently. Decoded transactions are then streamed to your application through <mark style="color:yellow;">a Yellowstone-compatible gRPC interface</mark> — without touching any RPC node at any point.

It combines the delivery speed of shreds, and the usability and filtering power of Yellowstone gRPC.

<table><thead><tr><th width="235">Feature</th><th>What RabbitStream Delivers it</th></tr></thead><tbody><tr><td><strong>Independent from RPC</strong></td><td>RabbitStream is not a plugin inside an RPC node. It operates as an independent system, listening directly to raw UDP shreds on the Solana network. The RPC is never in the path.</td></tr><tr><td><strong>Multiple Shred Sources</strong></td><td>RabbitStream ingests shreds from multiple sources across the network simultaneously — maximising coverage and ensuring the earliest possible delivery.</td></tr><tr><td><strong>Yellowstone gRPC Filtering</strong></td><td>Use the <strong>exact same</strong> <code>SubscribeRequest</code> format as Yellowstone gRPC. Filter by <code>accountInclude</code>, <code>accountRequired</code>, and more—no complex decoding is required on your end.</td></tr><tr><td><strong>Compatible Transaction Structure</strong></td><td>Transactions are streamed with a structure similar to Yellowstone gRPC (minus the full meta data), making it instantly compatible with existing gRPC clients and processing logic.</td></tr><tr><td><strong>Ultra-Low Latency</strong></td><td>RabbitStream delivers transactions before the Replay stage runs — consistently arriving ahead of any RPC-based stream. </td></tr></tbody></table>

{% hint style="info" %}
To maximise coverage and reliability, RabbitStream ingests shreds from **multiple sources across the network simultaneously** — ensuring the earliest possible delivery regardless of which propagation path the shreds take.
{% endhint %}

### Allowed Filters in Rabbitstream: The Trade-Off

RabbitStream is designed for <mark style="color:yellow;">maximum speed</mark>, which means we get you the transaction data at the very start of the Solana process (Shredding).

Since RabbitStream <mark style="color:yellow;">capture the data before execution</mark> happens, certain information that is generated *later* in the pipeline is not available:

* <mark style="color:yellow;">**No Execution Metadata:**</mark> RabbitStream does not have fields that are created during the final processing stage (like logs, inner instructions, or precise error details).
* <mark style="color:yellow;">**Limited Filters:**</mark> Rabbitstream streams data from the pre-processed stage, and <mark style="color:yellow;">only transactions filters are allowed</mark>. It does **not allow** filtering by ***accounts*****,&#x20;*****blocks*****, or&#x20;*****slot number*** *directly* on the stream. This information is typically confirmed and compiled later by the RPC node.

<table><thead><tr><th>Filter type</th><th align="center">Yellowstone gRPC</th><th align="center" valign="top">RabbitStream</th></tr></thead><tbody><tr><td>transactions</td><td align="center">✅</td><td align="center" valign="top">✅</td></tr><tr><td>accounts</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr><tr><td>slots</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr><tr><td>blocks</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr><tr><td>blocksMeta</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr><tr><td>accountsDataSlice</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr><tr><td>LUTs</td><td align="center">✅</td><td align="center" valign="top">❌</td></tr></tbody></table>

#### Speed Advantage

We have already benchmarked RabbitStream's performance against standard Yellowstone gRPC by creating a simple Pump.fun Token Launch Detector. Our initial tests reveal a consistent <mark style="color:yellow;">speed advantage</mark> ranging from <mark style="color:yellow;">\~15ms to 100ms</mark>.

[Rabbitstream Token Detector Examples \[.ts\]](https://github.com/Shyft-to/yellowstone-grpc-vs-rabbitstream)

We feel this will be a huge unlock for a lot of devs and await **feedback** from the community.

### Frequently Asked Questions

<details>

<summary>How is RabbitStream different from Yellowstone gRPC?</summary>

Both use the same `SubscribeRequest` interface and support the same transaction filters, but they tap the validator pipeline at different stages. \
[<mark style="color:yellow;">Yellowstone gRPC</mark>](https://shyft.to/solana-yellowstone-grpc) emits transactions after the Replay stage — meaning execution has completed and you receive the full result, including logs, balance changes, and success/failure status. [<mark style="color:yellow;">RabbitStream</mark>](/solana-shredstreaming/rabbitstream-overview.md) taps the pipeline earlier, right after shreds are reconstructed but before any execution happens. \
You get the transaction intent much sooner, but without execution metadata.

</details>

<details>

<summary>Is RabbitStream the same as raw shred streaming?</summary>

No. Raw shreds are small binary-encoded packets, that arrive undecoded and completely <mark style="color:yellow;">unfiltered</mark> — which means your application receives every single transaction on Solana and must decode each one before it can determine whether it's even relevant.

RabbitStream removes both of those burdens. Shreds are decoded server-side, and transactions are filtered before they reach your application using the <mark style="color:yellow;">same</mark> <mark style="color:yellow;"></mark><mark style="color:yellow;">`SubscribeRequest`</mark> <mark style="color:yellow;"></mark><mark style="color:yellow;">interface as Yellowstone gRPC</mark>. You only receive the transactions you need — nothing more.

This has two practical benefits: your application ingests significantly less network traffic, and you never have to write or maintain custom shred decoding logic.

</details>

<details>

<summary>Can the same transaction appear in both RabbitStream and Yellowstone gRPC?</summary>

Yes, and this is the intended usage pattern. Subscribe to RabbitStream for earliest detection, then use Yellowstone to receive the confirmed result with full execution context. The transaction signature is the same in both streams, making it straightforward to correlate.

</details>

<details>

<summary>Can we receive failed transaction via RabbitStream?</summary>

Yes. RabbitStream delivers transactions before execution. A transaction may fail signature verification, run out of compute units, or land on a fork that is later abandoned. You must handle these cases in your application.

</details>

<details>

<summary>Do I need a separate client for RabbitStream?</summary>

No. RabbitStream uses the same SubscribeRequest format as Yellowstone gRPC, so existing Yellowstone gRPC clients work with minimal changes. The only difference is the `meta` part of the transaction (logMessages, innerInstructions etc) is not available on Transactions streamed via RabbitStream.&#x20;

</details>

<details>

<summary>How do i get access to RabbitStream?</summary>

RabbitStream is available on the **BUILD**, **GROW**, and **ACCELERATE** plans. No separate credentials are needed — authenticate using your existing gRPC token. You'll just need to point your client to the RabbitStream endpoint URL instead of the standard Yellowstone gRPC URL. Find out more about [<mark style="color:yellow;">connecting to RabbitStream</mark>](/solana-shredstreaming/how-to-stream-with-rabbitstream.md#access-and-authentication) here.

</details>

<details>

<summary>Where do i reach out in case of support?</summary>

If you have any queries, you can always reach out to us on [<mark style="color:yellow;">Shyft Discord</mark>](https://discord.gg/RXBmKSdVRe) or the Chat Support on your Shyft Dashboard.

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.shyft.to/solana-shredstreaming/rabbitstream-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.