🐇RabbitStream Overview
Stream Pre-execution Solana Transactions Directly from Turbine Shreds with gRPC Style Filters
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 shreds.
What are Shreds?
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.
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 earliest transaction signal on Solana, they don't carry the final execution details — like logs and confirmed results (Transaction meta) — still they contain enough information to power speed-critical strategies.
RabbitStream extracts transactions directly from raw UDP shreds from multiple sources — independently of any RPC node — and delivers them through a Yellowstone-compatible gRPC interface. The RPC is never in the picture.
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 specific program or account.
Complex Decoding: The data structure of raw shreds is complex and binary-encoded, 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 real-time transaction stream that delivers data directly from raw UDP shreds — before transactions ever hit the RPC.
It does not run as a plugin inside a validator. Instead, it listens directly to raw UDP shreds from multiple sources as they propagate across the Solana network, performing its own shred reconstruction and validation independently. Decoded transactions are then streamed to your application through a Yellowstone-compatible gRPC interface — without touching any RPC node at any point.
It combines the delivery speed of shreds, and the usability and filtering power of Yellowstone gRPC.
Independent from RPC
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.
Multiple Shred Sources
RabbitStream ingests shreds from multiple sources across the network simultaneously — maximising coverage and ensuring the earliest possible delivery.
Yellowstone gRPC Filtering
Use the exact same SubscribeRequest format as Yellowstone gRPC. Filter by accountInclude, accountRequired, and more—no complex decoding is required on your end.
Compatible Transaction Structure
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.
Ultra-Low Latency
RabbitStream delivers transactions before the Replay stage runs — consistently arriving ahead of any RPC-based stream.
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.
Allowed Filters in Rabbitstream: The Trade-Off
RabbitStream is designed for maximum speed, which means we get you the transaction data at the very start of the Solana process (Shredding).
Since RabbitStream capture the data before execution happens, certain information that is generated later in the pipeline is not available:
No Execution Metadata: RabbitStream does not have fields that are created during the final processing stage (like logs, inner instructions, or precise error details).
Limited Filters: Rabbitstream streams data from the pre-processed stage, and only transactions filters are allowed. It does not allow filtering by accounts, blocks, or slot number directly on the stream. This information is typically confirmed and compiled later by the RPC node.
transactions
✅
✅
accounts
✅
❌
slots
✅
❌
blocks
✅
❌
blocksMeta
✅
❌
accountsDataSlice
✅
❌
LUTs
✅
❌
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 speed advantage ranging from ~15ms to 100ms.
Rabbitstream Token Detector Examples [.ts]
We feel this will be a huge unlock for a lot of devs and await feedback from the community.
Frequently Asked Questions
How is RabbitStream different from Yellowstone gRPC?
Both use the same SubscribeRequest interface and support the same transaction filters, but they tap the validator pipeline at different stages.
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. RabbitStream 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.
Is RabbitStream the same as raw shred streaming?
No. Raw shreds are small binary-encoded packets, that arrive undecoded and completely unfiltered — 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 same SubscribeRequest interface as Yellowstone gRPC. 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.
Can the same transaction appear in both RabbitStream and Yellowstone gRPC?
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.
Can we receive failed transaction via RabbitStream?
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.
Do I need a separate client for RabbitStream?
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.
How do i get access to RabbitStream?
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 connecting to RabbitStream here.
Where do i reach out in case of support?
If you have any queries, you can always reach out to us on Shyft Discord or the Chat Support on your Shyft Dashboard.
Last updated