Jito ShredStream Sunset: Migration Options for Solana Teams

Why the Jito ShredStream sunset matters

Jito ShredStream has been widely used by Solana teams that need data earlier than standard RPC, WebSocket, or Geyser paths can provide. Instead of waiting for downstream APIs, ShredStream users consume Solana shreds closer to the moment block data is produced and propagated.

That matters for latency-sensitive workloads such as:

• trading and MEV systems;
• token launch monitoring;
• custom RPC infrastructure;
• validator-adjacent data pipelines;
• real-time risk, monitoring, and alerting systems.

The right migration path depends on one question:

Do you actually need raw shreds, or do you need the fastest usable transaction data?

Those are not always the same thing.

What you need to replace

A Jito ShredStream migration should not be treated as a simple swap. Before choosing a replacement, review what your current stack does after receiving shreds.

Most teams need to evaluate five areas.

1. Raw shred delivery

If your system already has a custom deshredding and recovery pipeline, then raw shreds may still be the right interface. In that case, you need a replacement that gives you low-latency UDP delivery, strong regional coverage, and reliable packet reception.

2. Decoding infrastructure

Raw shreds are early, but they are not the final object most applications need. Most systems ultimately need transactions or filtered updates.

If you currently spend engineering time maintaining shred decoding, reconstruction, filtering, and monitoring, migration is a good moment to ask whether that work should stay in-house.

3. Transaction availability

For many trading systems, the important metric is not only when the first shred arrives. The important metric is when your application can act on the transaction.

That includes:

• receiving enough data;
• decoding it correctly;
• applying filters;
• passing the event to the strategy or application.

A raw feed can be fast at the packet level but still slower at the usable-transaction level if the local processing path is inefficient.

4. Regional latency

Solana latency is highly regional. A good migration test should run in the same location as your production infrastructure, or in the region where your strategy actually executes.

For most latency-sensitive teams, one global number is not enough. You should test Frankfurt, Amsterdam, New York, London, Tokyo, or whichever region matters for your setup.

5. Operational complexity

Raw shreds give maximum control, but they also create operational work.

You need to manage packet loss, UDP handling, deshredding, decoding performance, correctness checks, and failover behavior.

For some teams, that control is worth it. For others, a decoded or binary transaction stream gives better production results with less infrastructure.

Shreder migration options

Shreder offers multiple Solana data products because different teams need different levels of control.

Option 1: Raw Shreds

Use Raw Shreds if you want direct raw UDP shred delivery and already operate your own low-latency processing stack.

This is the closest replacement for teams that currently consume raw Jito ShredStream data and want to keep their internal pipeline mostly unchanged.

Raw Shreds are best for teams that:

• already have custom shred decoding infrastructure;
• want maximum control over processing;
• need direct UDP packet-level access;
• benchmark latency at shred-arrival level;
• have engineers dedicated to maintaining the pipeline.

Raw Shreds are powerful, but they are not the easiest path. If your final goal is transaction data, you may be able to simplify the stack with Decoded Shreds or Binary.

Option 2: Decoded Shreds

Use Decoded Shreds if you want the speed of shred-level data without maintaining the full decoding pipeline yourself.

Decoded Shreds are designed for teams that want to consume structured transaction data with filters, while staying close to the shred frontier.

This is a good fit if:

• you currently use raw shreds only because they are early;
• you do not want to maintain deshredding logic;
• you need server-side filtering;
• you want faster integration than a raw-shred migration;
• you care about usable transaction latency, not only packet arrival.

For many production teams, Decoded Shreds are the practical migration path: still fast, but much easier to operate.

Option 3: Binary

Use Binary if you want the fastest practical path to transaction data with minimal overhead.

Binary streams compact serialized transaction bytes from shreds, so your application can deserialize locally and act quickly. It avoids much of the complexity of raw shred processing while keeping the data path optimized for latency-sensitive systems.

Binary is best for:

• trading systems;
• searchers;
• latency-sensitive bots;
• teams that want transaction data as early as possible;
• users who want less infrastructure than a raw shred pipeline;
• teams that care about low tail latency and operational simplicity.

For many Jito ShredStream users, Binary may be the better migration target than another raw-shred feed.

Binary also supports an optional preconfs add-on, which can deliver transaction signals even earlier than shreds. Preconfs are received from validators before full shred propagation, allowing your system to see and react to transactions at the earliest possible stage in the network lifecycle. For ultra latency-sensitive strategies, this can provide an additional edge beyond standard shred-based feeds.

Benchmark: Shreder vs Jito ShredStream

In Shreder’s public benchmark, Shreder and Jito ShredStream were compared using the same methodology as our benchmarks hub.

The main takeaway is not only the median difference. The tail matters. In latency-sensitive Solana systems, p95 and p99 delays can be the difference between acting on an opportunity and seeing it after competitors already moved.

That is why migration testing should include both:

• first-arrival rate, showing which source sees data first more often;
• tail latency, showing how often a source falls behind by meaningful margins.

View Shreder benchmarks and methodology →

Raw shreds are not always the best migration target

It is natural for Jito ShredStream users to search for another raw shred stream first. But before migrating, it is worth reviewing what your application actually needs.

If your application needs raw shreds because your internal system is built around them, then Raw Shreds are the right place to start.

But if your application ultimately needs transactions, then raw shreds are only an intermediate format. In that case, Decoded Shreds or Binary may provide a cleaner migration path.

A raw-shred pipeline usually requires you to handle:

• UDP packet ingestion;
• packet loss behavior;
• shred reconstruction;
• decoding;
• deduplication;
• filtering;
• monitoring;
• recovery from spikes and gaps.

With Decoded Shreds or Binary, much of that work is moved out of your application path, so your team can focus on strategy, indexing, monitoring, or execution logic instead of maintaining low-level shred infrastructure.

Suggested migration checklist

If you currently use Jito ShredStream, we recommend testing the replacement path before the shutdown date.

A practical migration plan looks like this:

1. Identify your current dependency

Start by documenting exactly how your system uses Jito ShredStream today.

Are you consuming raw shreds directly?
Do you decode them into transactions?
Do you use them as a primary data source or as a latency accelerator next to Geyser/RPC?

This determines whether Raw Shreds, Decoded Shreds, or Binary is the best replacement.

2. Measure usable latency, not only packet latency

For raw feeds, packet arrival is important. But your application usually acts later.

Measure the full path:

• when the packet arrives;
• when the transaction is reconstructed;
• when your filters match;
• when your application receives the final event;
• when your strategy can act.

This gives a more honest view of production performance.

3. Compare tail behavior

Median latency is useful, but p95 and p99 are often more important.

If one provider is occasionally 30–50 ms later, that may matter more than a small difference in p50. Solana opportunities often disappear quickly, so consistency matters.

4. Choose the simplest product that satisfies the latency requirement

Do not default to raw shreds unless you actually need raw shreds.

Use:

• Raw Shreds if you need maximum control and have your own pipeline;
• Decoded Shreds if you want structured transaction data without maintaining decoding infrastructure;
• Binary if you want the fastest practical transaction stream with minimal overhead.

Which Shreder product should you choose?

The most common mistake is assuming that a raw-shred product must be replaced with another raw-shred product. Sometimes that is true. But often, the better migration is from raw packets to an optimized transaction stream.

Final thoughts

The Jito ShredStream sunset gives Solana teams a clear deadline, but it also creates a chance to improve the data path.

If your team needs raw packet-level access, Shreder Raw Shreds provide a direct low-latency replacement path.

If your team mainly needs fast transaction data, Decoded Shreds or Binary may be a better fit. They preserve the speed advantage of shred-level infrastructure while reducing the amount of custom decoding and operational work your team has to maintain.

The best next step is to run Shreder in parallel with your current setup, compare latency and coverage in your production region, and choose the product that gives you the earliest usable data with the least unnecessary complexity.

We offer free trials for all of these products, so you can get started quickly and evaluate them in your own environment. Setup takes just a few minutes, making it easy to test performance, latency, and integration before committing to a migration path.