TPU Submissions

Slipstream can submit transactions directly to the current leader validator's Transaction Processing Unit (TPU) via UDP. This is a fire-and-forget mode designed for absolute minimum latency — no confirmation receipt, no retry logic, just raw speed.

How It Works

When you enable tpu_submission, Slipstream bypasses its normal routing pipeline and:

1. Resolves the current slot leader from the leader schedule
2. Looks up the leader's TPU address (UDP port)
3. Sends your serialized transaction directly to the leader's TPU via UDP
4. Returns immediately — no confirmation, no status tracking

This mirrors what Solana validators do internally when forwarding transactions, but from the closest Slipstream worker to the leader.

When to Use TPU Submissions

Good for:

• Latency-critical arbitrage where you need to get a transaction to the leader ASAP
• High-frequency strategies where you're already monitoring confirmation via gRPC/websocket
• Scenarios where you have your own confirmation pipeline and don't need Slipstream to track status
• Spam-resistant strategies where you're sending many transactions and only need one to land

Not good for:

• Transactions that need confirmed delivery guarantees
• Bundles (TPU submission doesn't support atomic bundles)
• Scenarios where you need routing metadata or status tracking

Pricing

TPU submissions cost 2 tokens (0.0001 SOL) per transaction, compared to 1 token for standard submission.

Usage

TPU Submit — Rust

1use allenhark_slipstream::{Config, SlipstreamClient, SubmitOptions};
2
3let config = Config::builder()
4    .api_key("sk_live_...")
5    .build()?;
6
7let client = SlipstreamClient::connect(config).await?;
8
9// Fire-and-forget TPU submission
10let result = client.submit_transaction_with_options(&tx_bytes, &SubmitOptions {
11    tpu_submission: true,
12    ..Default::default()
13}).await?;
14
15// Result returns immediately — signature may or may not be available
16println!("Request ID: {}", result.request_id);
17println!("Status: {:?}", result.status); // Will be "sent" — no confirmation tracking

TPU Submit — TypeScript

1import { SlipstreamClient, configBuilder } from "@allenhark/slipstream";
2
3const config = configBuilder()
4    .apiKey("sk_live_...")
5    .build();
6
7const client = await SlipstreamClient.connect(config);
8
9// Fire-and-forget TPU submission
10const result = await client.submitTransactionWithOptions(txBytes, {
11    tpuSubmission: true,
12});
13
14console.log("Request ID:", result.requestId);
15console.log("Status:", result.status); // "sent" — no confirmation

TPU Submit — Python

1from allenhark_slipstream import SlipstreamClient, config_builder, SubmitOptions
2
3config = config_builder().api_key("sk_live_...").build()
4client = await SlipstreamClient.connect(config)
5
6# Fire-and-forget TPU submission
7result = await client.submit_transaction_with_options(tx_bytes, SubmitOptions(
8    tpu_submission=True,
9))
10
11print(f"Request ID: {result.request_id}")
12print(f"Status: {result.status}")  # "sent" — no confirmation

Combining with Streams

For best results, combine TPU submission with leader hint streams. Wait until the leader is in a region where Slipstream has a nearby worker, then fire:

TPU with Leader Hints — Rust

1// Subscribe to leader hints
2let mut hints = client.subscribe_leader_hints().await?;
3
4while let Some(hint) = hints.recv().await {
5    // Only submit when confidence is high
6    if hint.confidence >= 80 {
7        let result = client.submit_transaction_with_options(&tx_bytes, &SubmitOptions {
8            tpu_submission: true,
9            ..Default::default()
10        }).await?;
11    }
12}

TPU with Leader Hints — TypeScript

1await client.subscribeLeaderHints();
2
3client.on("leaderHint", async (hint) => {
4    if (hint.confidence >= 80) {
5        await client.submitTransactionWithOptions(txBytes, {
6            tpuSubmission: true,
7        });
8    }
9});

TPU vs Standard Submission

Confirming TPU Submissions Externally

Since Slipstream doesn't track TPU submission status, you'll need your own confirmation pipeline. Common approaches:

1. gRPC Subscription — Subscribe to transaction status updates via Solana gRPC (e.g., Yellowstone)
2. WebSocket — Use signatureSubscribe on a Solana WebSocket RPC
3. Polling — Call getSignatureStatuses periodically (higher latency)

Next Steps

• Transactions — Standard transaction submission with confirmation
• Real-Time Streams — Leader hints for optimal timing
• Error Handling — Handle TPU submission errors