> For the complete documentation index, see [llms.txt](https://docs.rpcfast.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/shredstream-grpc.md).

# Shredstream gRPC

RPC Fast's low-latency Jito-compatible stream of Solana Entries reconstructed directly from shreds.

Shredstream gRPC delivers Solana Entries reconstructed directly from the shred pipeline, before normal validator replay metadata is available. It exposes the Jito-compatible `ShredstreamProxy.SubscribeEntries` API and leaves transaction decoding, filtering, and processing under your control.

{% hint style="success" %}
Use Shredstream gRPC when you need shred-level latency and want to own the complete decoding and filtering pipeline.

**Shredstream gRPC is available on the Aperture plan, with up to 10 concurrent streams.**
{% endhint %}

## Why Use Shredstream gRPC?

* **Shred-level delivery.** Entries are emitted from the deshred pipeline without waiting for validator replay or Geyser processing.
* **Jito-compatible protocol.** Existing consumers of `ShredstreamProxy.SubscribeEntries` can use the same protobuf contract.
* **Unfiltered entry payloads.** Each response carries canonical serialized Solana Entries, including all transactions in those entries.
* **Maximum client control.** You decide how to decode transactions, resolve Address Lookup Tables, filter accounts and programs, and distribute work across your own pipeline.
* **Low protocol overhead.** The gRPC envelope contains only the slot and the serialized entry batch.

## Performance Comparison

The latest [gRPC stream speed report](https://s3-public-assets.rpcfast.com/streaming-speed-comparison.html) was generated on **August 25, 2026** from a 3-minute run. It compared identical transaction signatures at the same observer using local receive timestamps.

| Faster endpoint in the report | Compared with | Shared transactions | Arrived first | Median lead when first | p95 lead when first |
| ----------------------------- | ------------- | ------------------: | ------------: | ---------------------: | ------------------: |
| ShredStream                   | Yellowstone   |              58,688 |         99.9% |                4.82 ms |            16.04 ms |
| ShredStream                   | TxStream      |              58,688 |         50.9% |                  30 us |              571 us |

ShredStream and TxStream were effectively neck-and-neck on shared transactions. Both shred-derived streams delivered transactions before Yellowstone in at least **99.8%** of their matched races.

{% hint style="info" %}
The report's ShredStream collector matched 56.9% of the benchmark's unique transactions because it did not resolve Address Lookup Tables (ALTs). This is a limitation of the benchmark's client-side filter, not evidence that the transactions were absent from the raw stream. Pairwise speed results use only signatures observed by both endpoints.
{% endhint %}

## Protocol Reference

Shredstream gRPC uses the standard Jito-compatible protobuf contract from [`jito-labs/mev-protos`](https://github.com/jito-labs/mev-protos/blob/master/shredstream.proto).

| Property        | Value                                            |
| --------------- | ------------------------------------------------ |
| Endpoint        | `solana-shredstream-grpc.rpcfast.com:443`        |
| Service         | `shredstream.ShredstreamProxy`                   |
| RPC             | `SubscribeEntries`                               |
| Full method     | `/shredstream.ShredstreamProxy/SubscribeEntries` |
| Request         | `SubscribeEntriesRequest`                        |
| Response stream | `Entry`                                          |
| Authentication  | `x-token` gRPC metadata                          |

Use the endpoint and token shown for your application in the RPC Fast dashboard. Dedicated deployments can have a different hostname.

### Request Format

`SubscribeEntriesRequest` has no fields. Every subscription receives the full entry stream; Shredstream gRPC does not provide server-side transaction or account filters.

```protobuf
message SubscribeEntriesRequest {}

service ShredstreamProxy {
  rpc SubscribeEntries(SubscribeEntriesRequest) returns (stream Entry);
}
```

### Response Format

Each `Entry` response contains:

| Field     | Type     | Description                                                        |
| --------- | -------- | ------------------------------------------------------------------ |
| `slot`    | `uint64` | Solana slot associated with the entry batch.                       |
| `entries` | `bytes`  | A bincode-compatible serialized `Vec<solana_entry::entry::Entry>`. |

```protobuf
message Entry {
  uint64 slot = 1;
  bytes entries = 2;
}
```

After deserialization, every Solana `Entry` contains `num_hashes`, `hash`, and a vector of versioned transactions. One gRPC response can contain multiple entries. Do not treat one response as a complete block or as confirmation that its transactions landed.

{% hint style="warning" %}
Keep your Solana entry and transaction decoder dependencies current. The stream carries canonical network data and can include any transaction version supported by the network; older decoders may reject newer transaction versions.
{% endhint %}

## Connect from Rust

The following dependencies use Jito's generated gRPC client and current Solana entry types:

```toml
[dependencies]
jito-protos = { git = "https://github.com/jito-labs/shredstream-proxy", rev = "b96e369f3165600c02182e3d8e1d01b6aada9fdb" }
solana-entry = { version = "=4.2.1", features = ["agave-unstable-api"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }
tonic = { version = "0.13", features = ["tls-webpki-roots"] }
wincode = "=0.5.5"
```

Set `RPCFAST_X_TOKEN` to your application's Shredstream gRPC token, then connect, subscribe, and decode each entry batch:

```rust
use {
    jito_protos::shredstream::{
        SubscribeEntriesRequest, shredstream_proxy_client::ShredstreamProxyClient,
    },
    solana_entry::entry::Entry as SolanaEntry,
    tonic::{
        Request,
        metadata::MetadataValue,
        transport::{ClientTlsConfig, Endpoint},
    },
};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("RPCFAST_X_TOKEN")?;
    let channel = Endpoint::from_static(
        "https://solana-shredstream-grpc.rpcfast.com:443",
    )
    .tls_config(ClientTlsConfig::new().with_webpki_roots())?
    .connect()
    .await?;
    let mut client = ShredstreamProxyClient::new(channel);

    let mut request = Request::new(SubscribeEntriesRequest {});
    request.metadata_mut().insert(
        "x-token",
        MetadataValue::try_from(token.as_str())?,
    );
    let mut stream = client.subscribe_entries(request).await?.into_inner();

    while let Some(message) = stream.message().await? {
        let entries: Vec<SolanaEntry> = wincode::deserialize(&message.entries)?;
        let transactions = entries
            .iter()
            .map(|entry| entry.transactions.len())
            .sum::<usize>();

        println!(
            "slot={} entries={} transactions={}",
            message.slot,
            entries.len(),
            transactions,
        );
    }

    Ok(())
}
```

## Test ShredStream with grpcurl

Download [`shredstream.proto`](https://raw.githubusercontent.com/jito-labs/mev-protos/master/shredstream.proto) and [`shared.proto`](https://raw.githubusercontent.com/jito-labs/mev-protos/master/shared.proto) to the same directory. Then set `RPCFAST_X_TOKEN` and start the stream:

```bash
grpcurl \
  -import-path . \
  -proto shredstream.proto \
  -H "x-token: ${RPCFAST_X_TOKEN}" \
  -d '{}' \
  solana-shredstream-grpc.rpcfast.com:443 \
  shredstream.ShredstreamProxy/SubscribeEntries
```

`grpcurl` prints the `entries` field as base64 because it is a protobuf `bytes` field. Use a Solana-aware decoder, such as the Rust example above, to inspect entries and transactions.

## Production Integration Guidance

* **Read continuously.** Decoding or strategy work should not block the gRPC receive loop. Hand batches to bounded worker queues.
* **Reconnect on transport errors.** Retry `UNAVAILABLE` with backoff. A slow consumer can be disconnected with `RESOURCE_EXHAUSTED: Lagged`; reconnect only after addressing the bottleneck.
* **Plan for gaps.** Subscriptions are live-only and do not replay data missed while disconnected. Use another source if your application requires gap recovery.
* **Filter after decoding.** Match static account keys and, when necessary, resolve ALTs before applying account-based filters.
* **Measure freshness.** Track the latest received slot, receive rate, decode failures, queue depth, reconnects, and lag relative to a reference RPC slot.
* **Deduplicate by transaction signature.** Early data can arrive through forks or multiple data paths; do not use the slot alone as a transaction identity.

## Important Semantics

Shredstream gRPC is an early, pre-execution feed rather than a source of confirmed state.

* A streamed transaction can fail, never confirm, or land on a fork that does not survive.
* The stream does not include confirmed balances, inner instructions, execution status, program logs, or rewards.
* There is no commitment parameter and no server-side filtering.
* Entry hashes and transaction bytes are delivered without transaction-level rewriting; decoding and ALT resolution are client responsibilities.

{% hint style="success" %}
Use [Aperture TxStream](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/txstream) when you want decoded transactions, server-side filters, resolved ALT addresses, compact responses, or real-time simulation. Use [Yellowstone gRPC](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/yellowstone-grpc) when you need validator-processed accounts, blocks, transactions, and execution metadata.
{% endhint %}

## When to Use Shredstream gRPC

Shredstream gRPC is best suited to teams that already operate a high-performance Solana decoding pipeline and want the earliest low-level data surface.

Common use cases include:

* HFT and MEV searchers with custom parsers and strategy-specific filters
* transaction and program-activity detection before validator replay
* low-latency indexing pipelines that enrich raw transactions independently
* redundant early-data paths alongside TxStream or Yellowstone gRPC


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/shredstream-grpc.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.