Shreds

Jito ShredStream Is Shutting Down — Here's How to Migrate in Minutes

August 21, 2026AllenHark Team

Jito ShredStream Is Shutting Down — Here's How to Migrate in Minutes

If you run a searcher bot, a memecoin sniper, a market maker, or an analytics pipeline that ingests raw Solana shreds through Jito's shredstream-proxy, mark September 5, 2026 on your calendar. That's the day Jito's official ShredStream feed goes dark for good.

The good news: migrating off it is not a rewrite. It's one changed flag. This guide walks through why the shutdown is happening, what AllenHark Jito Shreds actually is, and the exact steps to move your existing setup over before the deadline.

Why Jito ShredStream Is Shutting Down

Jito announced the deprecation of its ShredStream service in mid-2026, with a hard cutoff of September 5, 2026. After that date, Jito's block-engine-url stops accepting shredstream-proxy connections, and the upstream proxy binary itself is built to refuse to run past the shutdown date — there's no "just keep running the old binary" workaround.

For anyone whose infrastructure depends on that raw shred feed — searchers extracting arbitrage, sniper bots watching new token program activity, market makers tracking blocks before they're confirmed, analytics platforms parsing chain activity in real time — this isn't a minor inconvenience. It's a hard stop on a data source your systems were built around.

The underlying protocol Jito built (a proxy binary that authenticates with a keypair, connects to a block-engine endpoint, and forwards decoded shreds to a local UDP listener) is solid. What's disappearing is Jito's willingness to keep operating the endpoint on the other end of that connection.

What AllenHark Jito Shreds Is

AllenHark Jito Shreds is a drop-in replacement for Jito ShredStream. It is not a new integration — it's the same integration, pointed somewhere else.

Concretely:

  • You keep running a shredstream-proxy binary. AllenHark maintains a public fork — allenhark-shredstream-proxy, Apache-2.0 licensed — that's identical to Jito's upstream proxy except it has no kill switch and no forced shutdown date baked in.
  • You keep your existing keypair. There's nothing to regenerate and nothing to migrate cryptographically. You just tell AllenHark which public key to whitelist.
  • The proxy speaks Jito's exact protocol against the AllenHark gateway — the same auth challenge/JWT exchange, the same heartbeat, the same wire format for shreds. Nothing downstream of your --dest-ip-ports listener needs to change. Your parser, your deshredding logic, your consumer processes are untouched.

The only thing that changes is which URL the proxy dials.

The Migration, Step by Step

1. Install the AllenHark proxy binary

Because the upstream shredstream-proxy refuses to run after Jito's shutdown date, you need AllenHark's maintained build instead:

# Prerequisites (Ubuntu): build-essential clang libclang-dev cmake protobuf-compiler
git clone https://github.com/AllenHark-Inc/allenhark-shredstream-proxy.git
cd allenhark-shredstream-proxy
cargo build --release

It's a fork, not a rewrite — same CLI surface, same behavior, minus the kill switch.

2. Register your keypair's public key

Shreds access is whitelisted by pubkey rather than by IP. Sign in to the AllenHark console and register the public key of the keypair your proxy already signs with — not the private key, which never needs to leave your machine.

This is also where you start a 24-hour free trial, so you can validate the whole pipeline before paying for anything. One subscription per user, one pubkey per subscription.

3. Point --block-engine-url at the AllenHark gateway

This is the entire migration:

./target/release/jito-shredstream-proxy shredstream \
  --block-engine-url https://fra.jito.allenhark.network \
  --auth-keypair /path/to/your/keypair.json \
  --desired-regions frankfurt \
  --dest-ip-ports 127.0.0.1:8001,127.0.0.1:8002
  • --block-engine-url is the only value that changes — swap it for https://fra.jito.allenhark.network, the AllenHark Frankfurt gateway (also shown in your console dashboard).
  • --auth-keypair and --dest-ip-ports behave exactly as they did against Jito. Shreds still arrive on your existing listen ports, in the same format, ready for your existing code to consume. Set --desired-regions to frankfurt — AllenHark serves everything from the single Frankfurt gateway today, so the value isn't used for routing.

4. Verify shreds are flowing

Check the proxy logs for a successful auth handshake and an established heartbeat, confirm packets are hitting your --dest-ip-ports listener, and check that your subscription shows as active and connected in the console. If nothing arrives, the most common cause is a mismatch between the registered pubkey and the keypair the proxy is actually running with — whitelisting is strictly pubkey-based.

That's it. Four steps, one changed flag, zero changes to your deshredding or downstream logic.

Trial & Pricing

AllenHark Jito Shreds runs on a simple model: a 24-hour free trial to prove out the migration end-to-end, then $50/month per subscription. One pubkey per subscription, one subscription per user. Shreds are served from the AllenHark Frankfurt gateway at https://fra.jito.allenhark.network.

FAQ

Do I need a new keypair? No. Register the pubkey of the keypair your shredstream-proxy already signs with — AllenHark whitelists by pubkey, the same mechanism Jito used.

What exactly do I need to change in my setup? One CLI flag: --block-engine-url. Your keypair, your --dest-ip-ports, and everything downstream stays identical.

Does AllenHark Jito Shreds speak the same protocol as Jito's ShredStream? Yes — the AllenHark proxy is a fork of Jito's own shredstream-proxy and performs the identical auth challenge/JWT exchange and heartbeat against the AllenHark gateway. There's no new integration to build.

What happens if I miss the September 5, 2026 deadline? Jito's ShredStream stops accepting proxy connections, and the upstream proxy binary itself refuses to run past that date. Your feed goes dark until you switch to a maintained proxy and a working endpoint.

Is the proxy source available? Yes — github.com/AllenHark-Inc/allenhark-shredstream-proxy, Apache-2.0, a kill-switch-free fork of Jito's shredstream-proxy.

How is this different from AllenHark's regular ShredStream product? AllenHark ShredStream delivers raw shreds directly over UDP/gRPC with no proxy at all. Jito Shreds is specifically for teams who want to keep running the shredstream-proxy binary and their existing keypair-based setup — it's the drop-in path, not a re-architecture.

Migrate Before September 5

Every day you wait is a day closer to a feed that just stops. The migration itself takes minutes, not a sprint.