TL;DR: Jito is shutting ShredStream down on September 5, 2026. If you consume raw shreds through the proxy, OrbitFlare Shredstream delivers the same UDP packets to the same listener, without the proxy in between. If you used the proxy's gRPC mode, or you only ever needed the transactions, OrbitFlare's Jetstream streams them to you decoded and enriched over gRPC. The sensible plan is the same in both cases: run the replacement alongside ShredStream in your own region, compare the numbers, and switch before the deadline.

What Actually Stops on September 5

Jito published the deprecation notice in early July. The service shuts down completely on September 5, 2026, and Jito recommends DoubleZero Edge as the replacement, with a transition guide on their site. What the notice does not describe is what the shutdown means for the system you are running, so it is worth walking through.

Every ShredStream setup has the same delivery path. Jito's infrastructure collects shreds from well-positioned validators. Your shredstream-proxy instance authenticates to that infrastructure with an approved keypair and holds a heartbeat connection. The proxy then serves your applications in one of two ways. Either it forwards the raw packets to every address in its DEST_IP_PORTS list, or it deshreds them and serves decoded transactions on a gRPC port.

On September 5, the Jito half of that path disappears. The proxy can no longer authenticate, it has nothing to forward, and your application stops receiving data. Everything below the socket, the parser, the filters, the strategy, is unaffected, and it will work with any source that delivers the same packets. That makes the migration problem small and specific. You need a new source of shreds, not a new system.

Same Socket, New Source

OrbitFlare Shredstream is that source. We partner with high-stake validators near the root of Turbine, and we forward the shreds they receive to an IP and port you choose, over UDP. The packets are standard Solana shreds, so your existing parser handles them without modification. Point Shredstream at the listener your proxy currently feeds, and the rest of your pipeline continues to work.

Setup is simpler than what you have now. There is no proxy process, no keypair approval, and no heartbeat to monitor. You enter a destination in the dashboard, and packets start arriving within seconds.

Coverage is wider as well. Jito operated eight ShredStream regions and limited each proxy to two of them. Shredstream runs in nine: Frankfurt, Amsterdam, London, New York, Singapore, Dublin, Siauliai, Salt Lake City, and Tokyo. That includes every location Jito served, so you do not need to move servers to migrate. There is also a free 60-minute trial you can start from the dashboard.

Or Stop Handling Packets Entirely

Many teams only consumed raw shreds in order to turn them into transactions, and some used the proxy's gRPC mode for exactly that reason. If that describes your setup, the migration is a chance to remove the deshredding work instead of rehosting it.

Our Jetstream does the deshredding on our servers and streams decoded transactions over gRPC, earlier than Geyser-based feeds can deliver them. You subscribe with filters, so only transactions touching the accounts and programs you name are sent to you.

Our Jetstream V2 also attaches the fields you would otherwise fetch with a follow-up RPC call. Address lookup tables arrive resolved, and each transaction carries its fee payer, compute unit price, writable accounts, and program IDs. Getting started is a few lines with one of our SDKs (Rust, TypeScript, or Go):

use orbitflare_sdk::jetstream::v2::{JetstreamClientBuilder, TransactionFilter};

let client = JetstreamClientBuilder::new()
    .url("http://fra.jetstream.orbitflare.com")
    .build()?;

let filter = TransactionFilter::new()
    .account_include(["6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"])
    .include_enrichment(true)
    .with_id("pumpfun");

let mut stream = client.subscribe_transactions(vec![filter]);

The protocol covers the operational side too. Every message carries a sequence number, so a dropped message is detectable the moment it happens. The server sends heartbeats on quiet streams, so you can tell an idle stream from a dead connection. Filters can be added or removed while the stream is running, without reconnecting.

For many teams, this path ends the migration with less code than they started with, because the deshredding, packet loss handling, and recovery logic all move to our side.

Benchmarks

We ran both feeds on the same host in Frankfurt and recorded, for each transaction, which feed delivered it first and by how much. Over 10,014 transactions, our Shredstream was first 95.93% of the time.

The percentiles matter more than the win rate. When Jito's feed was behind, it was behind by 6.51ms at the median and 28.77ms at p99. That gap is enough for someone on the faster feed to see a transaction, decide, and act before the slower feed has even delivered it.

Six Weeks Is Enough

The deadline leaves enough time to migrate carefully if you start now. Run the replacement alongside ShredStream on live traffic, in the region where your production systems actually run. Compare p95 and p99, not just the median, because that is where the two feeds differ most. Then switch while ShredStream is still available, so you have a fallback if anything behaves unexpectedly.

Start the trial, point it at your infrastructure, and let your own numbers make the call.

---

OrbitFlare builds Solana infrastructure for teams that need speed: RPC nodes, Jetstream gRPC streaming, trading APIs, and Shredstream. Start a free 60-minute trial from your dashboard, or get in touch if you want help planning the cutover.

Resources

1. Jito ShredStream deprecation notice
2. jito-labs/shredstream-proxy on GitHub
3. OrbitFlare docs
4. Jetstream V2 docs