# RabbitStream Overview

On Solana, speed is everything for high-frequency trading and sniping bots. The fastest data comes from <mark style="color:yellow;">Shreds</mark>, which are raw data packets emitted at the earliest stage of processing. While Shreds provide the earliest transaction detection (pre-processing), they are <mark style="color:yellow;">missing the final details</mark> (transaction meta) like logs and confirmed results. They still contain enough information to be useful for speed-critical sniping strategies.

{% hint style="success" %}
[RabbitStream](https://shyft.to/solana-shreds-rabbitstream) extracts transactions directly from shreds — while the validator is still processing the slot. By the time Yellowstone gRPC executes and emits a transaction, RabbitStream has already delivered it.
{% 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 are unfiltered, 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. Any form of <mark style="color:yellow;">filtering is not available</mark>.
* **Difficult Decoding Requirements**: 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.

{% hint style="info" %}

### RabbitStream: Shred-Stage Extraction with Yellowstone Filtering

Every Solana block starts as <mark style="color:yellow;">**shreds**</mark> — small packets emitted by the leader and propagated across the Solana network via Turbine Protocol. These shreds exist before any form of execution by the RPC, before any account locking, before any logs are written.

RabbitStream taps the validator pipeline at exactly this point — the **Blockstore stage**, immediately after shreds are reconstructed into readable entries — and streams decoded transactions to your backend.\
\
RabbitStream decodes shreds server-side and delivers transactions through a Yellowstone-compatible gRPC interface, letting you apply familiar filters like `accountInclude` and `accountRequired` without writing any custom shred parsing logic.
{% endhint %}

### Introducing RabbitStream: Shred Speed, gRPC Usability

RabbitStream provides <mark style="color:yellow;">real-time transactions extracted directly from shreds</mark>**,** coming straight from leader&#x73;**, and** <mark style="color:yellow;">streamed through a gRPC interface</mark>**.** 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>How Rabbitstream solves it</th></tr></thead><tbody><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>Feel Solana's pulse as it happens. RabbitStream provides the lowest latency for transaction detection possible outside of running your own validator cluster.</td></tr></tbody></table>

### 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></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.