How to Push Solana Transactions Under 500ms (Even During Congestion)

A practical guide for TypeScript HFT builders on optimizing network propagation, using QUIC, and leveraging private relays like AllenHark to bypass congestion.

  • December 3, 2025
  • 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.

šŸš€ How to Push Solana Transactions Under 500ms (Even During Congestion) — A Practical Guide for TypeScript HFT Builders

Why your HFT bot keeps getting stuck in Solana traffic — and how AllenHark Relay fixes it.

High-frequency trading on Solana is a completely different game from building a normal arbitrage or liquidation bot. When the network is hot, leaders produce a new block every ~200ms, transaction queues balloon instantly, and your beautifully crafted arbitrage opportunity dies in the mempool before it gets a chance to land.

If you're a TypeScript engineer trying to push signed transactions in <500ms with near-zero packet drop, this guide breaks down the architecture, best practices, and endpoint configuration patterns used by professional HFT teams — including how AllenHark Relay gives you consistent performance even during congestion.

1. The Real Bottleneck: Network Propagation, Not Signing

Most Solana HFT setups optimize the wrong step.

Your fastest signing architecture won't matter if:

  • Your RPC is a public shared node
  • Your packets hit the public TPU fanout
  • You aren't injected directly into leader nodes
  • You rely solely on sendTransaction instead of QUIC sends
  • You have no tip prioritization pipeline

Propagation delay kills more trades than signing latency.

AllenHark Relay minimizes propagation time by directly feeding your packets into leader-adjacent nodes with private priority lanes.

2. The TypeScript Architecture Used by Most Successful HFT Bots

Below is the recommended production pattern:

(a) Pre-sign your transactions

Never sign on-demand:

TypeScript
const ix = createYourIx();
const message = new TransactionMessage({
  payerKey: wallet.publicKey,
  recentBlockhash,
  instructions: [ix]
}).compileToV0Message();

const rawTx = new VersionedTransaction(message);
rawTx.sign([wallet]);
const serialized = rawTx.serialize();

Then pipe this directly to your relay.

(b) Use a dedicated QUIC sender

Public RPC → WebSockets → sendTransaction() = slow, unpredictable, packet drop hell.

What you want instead:

  • A QUIC client that writes raw UDP datagrams
  • Persistent keep-alive channels (no TLS renegotiation)
  • Direct leader feed entry

AllenHark Relay exposes:

  • QUIC: relay.allenhark.com:4433 (Frankfurt alias for 88.216.36.108:4433; also ams, ny, tyo)
  • HTTPS: https://relay.allenhark.com
  • API key: required on every request — x-api-key header or ?api-key=; over QUIC it's the first line of the stream

Trade bots interact through a thin TypeScript client or raw QUIC packets:

TypeScript
// Example using HTTPS for simplicity (QUIC recommended for speed)
await fetch("https://relay.allenhark.com/v1/sendTx", {
  method: "POST",
  headers: { "x-api-key": process.env.ALLENHARK_API_KEY! },
  body: JSON.stringify({
    jsonrpc: "2.0",
    method: "sendTransaction",
    params: [
      base58SignedTx,
      { skipPreflight: true }
    ]
  })
});

(c) Keep multiple connections warm

Real HFT setups run:

  • 1 QUIC channel for priority send
  • 1 backup QUIC channel
  • 1 HTTP client (axios/keep-alive)
  • 1 websocket stream for slots/leader

Your goal is zero cold starts.

TypeScript
const agent = new http.Agent({ keepAlive: true });
const api = axios.create({
  baseURL: "https://relay.allenhark.com",
  httpAgent: agent,
  timeout: 300
});

3. RPC Config for Low-Latency Sends

Use these settings everywhere:

TypeScript
getLatestBlockhash({
  commitment: "processed"
});

Why?

  • "processed" gives blockhashes 200–600ms fresher
  • "confirmed" adds latency
  • "finalized" is too slow for HFT

Also:

TypeScript
// When using standard RPC methods
sendRawTransaction(serialized, {
  skipPreflight: true,
  maxRetries: 0
});

Preflight is a killer — drop it for anything HFT.

4. The Role of Tips: Your Fast Lane into Leader Blocks

During congestion, Solana prioritizes tipped transactions.

Most bot builders send:

  • too low tips (1–5k lamports)
  • inconsistent tips
  • no adaptive curve

You pay AllenHark Relay per transaction: each one carries a tip of at least 0.001 SOL (1,000,000 lamports), transferred to one of the relay's tip wallets in the same transaction. Create your API key in the console. Relay Dedicated is the optional monthly upgrade for volume: a higher rate limit, and no tip from your whitelisted wallets.

Example Tip Wallets:

  • hark1zxc5Rz3K8Kquz79WPWFEgNCFeJnsMJ16f22uNP
  • harkm2BTWxZuszoNpZnfe84jRbQTg6KGHaQBmWzDGQQ
  • ... (see docs for full list)

5. Why a Private Relay Beats Public RPC Every Time

Public RPC nodes: āŒ Shared bandwidth āŒ Unpredictable queueing āŒ Packet drops during hot moments āŒ No direct leader peering āŒ No mempool bypass

AllenHark Relay: āœ… Private connections straight to the current leader āœ… Never touches public gossip āœ… QUIC, WebSocket and HTTPS endpoints āœ… Jito bundles: up to five transactions, atomic and in order āœ… Pay per transaction, with a tip inside it āœ… Relay Dedicated for volume: a higher rate limit, no tip from whitelisted wallets

Professional traders use private relays because network position is a competitive advantage.

Backend stack (TypeScript):

  • @solana/web3.js or helius-labs/solana for signing
  • Axios with keep-alive for control-plane requests
  • QUIC client for data-plane raw sends
  • AllenHark Relay endpoint for priority routing
  • Adaptive tip algorithm
  • Parallel hot connections
  • Pre-signed transactions

Expected performance:

  • 80–130ms propagation
  • 300–450ms block inclusion
  • <1% drop rate
  • Consistent behavior even in 2M TPS spikes

7. Final Advice: Co-Locate with the Relay

If you're running:

  • market-making bots
  • arbitrage
  • liquidation engines
  • MEV searchers
  • Jito bundles
  • pump detection engines

Co-location cuts your latency another 80–120ms.

We offer physical or virtual co-location in Frankfurt, Tokyo, and New York.

If your PnL depends on landing in the next 1–3 slots, co-location is the single biggest performance upgrade.


CTA: Ready to Build a Fast Bot? Connect to AllenHark Relay

If you want:

  • ⚔ Transaction landing time under 500ms
  • ⚔ Dedicated HFT-grade QUIC channels
  • ⚔ Priority transaction routing
  • ⚔ Leader adjacency
  • ⚔ Near-zero packet drop
  • ⚔ Private delivery straight to the current leader
  • ⚔ QUIC, WebSocket and HTTPS endpoints
  • ⚔ Jito bundles, atomic and in order
  • ⚔ Pay per transaction, with a tip inside it
  • ⚔ Relay Dedicated when your volume grows

Then AllenHark Relay is engineered for you.

šŸ‘‰ Contact us to co-locate with our relay nodes

šŸ‘‰ Read the Relay integration guide

šŸ‘‰ Create your Relay API key