Sign inGet started

What is Slipstream? AllenHark's Sender-Agnostic Solana Transaction Relay

An introduction to Slipstream — a leader-proximity-aware transaction relay that picks the sender closest to the current leader for each of your Solana transactions.

  • March 5, 2026
  • Infrastructure
  • AllenHark Team
A quiet stack of pagesAn abstract drawing of light on the page's dark ground. A neat stack of thin, solid pages, the top one lit, with faint streams of light drifting toward it from the left.A quiet stack of pagesAn abstract drawing of light on the page's dark ground. A neat stack of thin, solid pages, the top one lit, with faint streams of light drifting toward it from the left.

What is Slipstream?

If you've been trading on Solana — whether it's arbitrage, sniping, liquidations, or any latency-sensitive strategy — you've probably experienced the frustration of transactions that land late. You pick a sender, send your transaction, and hope it reaches the leader in time. Sometimes it does. Often it doesn't.

Slipstream is AllenHark's answer to this problem. It's a sender-agnostic, leader-proximity-aware transaction relay that takes the guesswork out of choosing how your transactions reach the leader.

The Problem Slipstream Solves

On Solana, the validator producing blocks (the "leader") changes every four slots. Different leaders run in different data centers around the world. When you submit a transaction through a single sender — whether that's Jito, a public RPC, or any other endpoint — your transaction always takes the same path regardless of where the leader actually is.

This means:

  • If the leader is in a US data center and your sender is in Europe, your transaction crosses an ocean it didn't need to
  • If your sender has a temporary routing issue, your transaction may not land at all
  • If a competing sender is closer to the current leader, you lose to anyone using that sender

How Slipstream Works

Slipstream runs workers in several regions. The regions are not hardcoded: the SDK discovers them at connect time, and each region reports its current round-trip time to the leader.

When you submit a transaction through the SDK, Slipstream:

  1. Identifies the current leader from the real-time leader schedule
  2. Selects the worker closest to that leader
  3. Picks the sender — Nozomi, Helius, another third-party sender, or your own — based on the leader's identity and network conditions
  4. Delivers your transaction through the path closest to the leader

The discovery service publishes each region's current round-trip time to the leader, and the SDK uses it to pick the best option for you.

What Makes It Different

Sender Agnostic

You're not locked into one sender. Slipstream has integrations with multiple senders and selects the best one per transaction. If Nozomi is closest to the current leader, it uses Nozomi. If another sender is closer, it uses that one. You get the benefit of all senders without managing any of them.

4-Protocol Fallback

Slipstream supports QUIC (port 4433), gRPC (10000), WebSocket (9000), and HTTP (9091). The SDK tries them in order and falls back automatically. QUIC comes first, and if your network blocks UDP, it switches to gRPC or WebSocket.

Atomic Bundles

Submit 2–5 transactions as an atomic bundle. Either all execute or none do — no partial fills, no inconsistent state. A bundle costs 5 tokens.

TPU Direct Submission

Slipstream can also submit your transaction directly to the leader's TPU via UDP. Fire-and-forget — no confirmation, no retry. It costs 2 tokens per transaction.

Real-Time Streams

Subscribe to 5 live data feeds through your existing connection:

  • Leader hints — know which worker is closest to the upcoming leader
  • Tip instructions — current tip levels for bundle priority
  • Priority fees — recommended compute unit prices with landing probabilities
  • Latest blockhash — fresh blockhashes without polling
  • Slot updates — real-time slot progression

Dynamic Region Discovery

Regions aren't hardcoded. The SDK discovers available workers from discovery.allenhark.network, ranks them by latency, and connects to the best one. As AllenHark adds more regions, your SDK picks them up automatically.

Token-Based Billing

Slipstream uses a simple pay-per-use model, counted in tokens bought with SOL (the token rate is in the billing docs):

  • Single transaction: 1 token
  • Bundle (2–5 tx): 5 tokens
  • TPU direct: 2 tokens
  • RPC proxy call: 1 token

Deposit SOL, get tokens, pay only for what you use. A small daily token allowance lets you test before you deposit.

Getting Started

Slipstream has production-ready SDKs for Rust, TypeScript, and Python:

Terminal
# Rust
cargo add allenhark-slipstream

# TypeScript
npm install @allenhark/slipstream

# Python
pip install AllenHarkSlipstream

Connect and submit your first transaction:

TypeScript
import { SlipstreamClient, configBuilder } from "@allenhark/slipstream";

const config = configBuilder()
    .apiKey("sk_live_...")
    .build();

const client = await SlipstreamClient.connect(config);
const result = await client.submitTransaction(txBytes);
console.log("Status:", result.status);

Who Should Use Slipstream

  • MEV searchers who want delivery through whichever sender is closest to the leader
  • Arbitrage bots that can't afford to lose races due to sender selection
  • Sniper bots competing for time-sensitive opportunities
  • Trading desks that want multi-sender redundancy without managing infrastructure
  • Anyone tired of being locked into a single sender

Learn More