Sign inGet started

How to Land Solana Transactions in the Same Slot: A Hands-On Setup

Land a Solana transaction in the same slot as its trigger: read early, build ahead, send through a relay you keep open, and measure the slot delta.

  • November 20, 2025
  • 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.

Updated 8 November 2026. Rewritten as a hands-on setup, with a send example built from the relay docs and the mainnet slot times measured on 6 November 2026.

In Solana trading, timing is measured in slots, not seconds. A slot lasts about 200 ms: 211 to 216 ms on mainnet when we measured on 6 November 2026. If you spot an opportunity in slot N and your transaction lands in slot N+1 or N+2, you've likely missed the trade.

Landing in the same slot as your trigger is what traders call 0-slot landing. What is 0-slot landing on Solana? explains the term, how slots and leaders work today and what decides your landing slot. This post is the hands-on half: the setup, a send example, and how to check it works.

Why transactions land late

1. Public RPC sends from an unstaked connection

When you send through a public RPC endpoint, your transaction goes through several stages:

  1. Load balancer: routes your request to a node.
  2. Preflight: by default the node simulates your transaction before sending it.
  3. Forwarding: the node forwards it to the current and upcoming leaders, usually from an unstaked connection.
  4. The leader's queue: under stake-weighted QoS, unstaked connections are throttled first when a leader is busy.

Result: by the time the leader takes your transaction, the slot you aimed for has often passed.

2. Jito bundles wait for an auction

Jito's block engine runs its auction at 50 ms ticks, and tips count only with leaders running Jito's client. Bundles give you atomic, ordered execution, which is worth a lot for multi-step trades, but the auction adds a wait compared with sending straight to the leader.

3. Work done at send time

  • Fetching a blockhash when the trigger fires. A blockhash lasts about 150 blocks, which is about 30 seconds, so fetch it ahead and refresh it on a timer. Blockhash not found covers the errors.
  • Preflight on every send. Test your transaction once, then send with preflight off.
  • Opening a connection per transaction. A new HTTPS or QUIC handshake at send time costs you round trips you don't need.

The setup, step by step

1. Read early

Read the trigger from a feed that sees it while the block is still being built:

  • Solana ShredStream: the pieces of the leader's block as they travel over Turbine, before any node replays them.
  • Solana gRPC: account and transaction updates at processed, as a node executes them. Shreds arrive earlier; gRPC is simpler to filter.

Avoid polling RPC for the trigger. By the time a poll returns it, the slot is usually over.

2. Build ahead of the trigger

Have everything ready before the signal arrives, so that the trigger only fills in the trade:

  • A recent blockhash, refreshed on a timer
  • The accounts your transaction touches, and their addresses already derived
  • A priority fee priced from the accounts you write
  • The relay tip, as a top-level SystemProgram.transfer to an AllenHark tip wallet inside the transaction (tip rules)

No network calls between the trigger and the send.

3. Run in the same city as the relay

Every leg you add between your bot and the leader costs time. Run the bot on a server in Frankfurt or Amsterdam, in the same city as the relay region and the data feeds, not on a laptop or in a far-off cloud region. AllenHark Relay also runs in New York and Tokyo.

4. Send through a relay you keep open

AllenHark Relay sends your transaction through five channels at once, including stake-weighted QUIC, QUIC and UDP to the leaders, and the Jito Block Engine. It lands transactions in the same block, at 0.1 ms over QUIC.

AllenHark Relay was first sold under the name 0-slot. It isn't 0slot (0slot.trade), which is a separate sending service.

HTTPS is the simplest way to start. QUIC and WebSocket keep one connection open, so there is no handshake when the transaction is ready.

Example: from trigger to send

TypeScript
import bs58 from "bs58";

const RELAY = "https://fra.relay.allenhark.com/v1/sendTx"; // or ams., ny., tyo.
const sent: { signature: string; triggerSlot: number }[] = [];

// 1. A signal arrives from gRPC or shreds, in slot N
stream.on("data", async (update) => {
  const triggerSlot = slotOf(update); // the slot the signal came from

  // 2. Build and sign with everything prepared in advance:
  //    cached blockhash, priority fee and the relay tip transfer inside the transaction
  const tx = buildTradeTx(update);

  // 3. Send it to the relay, with preflight off
  await fetch(RELAY, {
    method: "POST",
    headers: { "Content-Type": "application/json", "x-api-key": process.env.RELAY_API_KEY! },
    body: JSON.stringify({ tx: Buffer.from(tx.serialize()).toString("base64"), simulate: false }),
  });

  // 4. Keep the trigger slot with the signature, to measure the slot delta later
  sent.push({ signature: bs58.encode(tx.signatures[0]), triggerSlot });
});

For a connection you keep open, the relay docs have QUIC and WebSocket clients in Rust, TypeScript and Python, and the atomic bundle format.

5. Measure the slot delta

For every trade, subtract the trigger slot from the slot your transaction landed in. +0 is a 0-slot landing. The slot-delta script reads both from the chain, given the trigger signature and yours.

  • Mostly +0: your setup works. Keep measuring, since leaders and competition change.
  • Mostly +1: you're one step short. Time each stage with the latency harness to find which one.
  • +2 or more, or missing: the send path is the problem. Check for preflight, unstaked connections and expired blockhashes.

Checklist

  • The trigger comes from shreds or gRPC, not RPC polling
  • Blockhash, fee, accounts and tip are ready before the trigger
  • No network calls between the trigger and the send
  • Preflight is off, once the transaction is tested
  • The bot runs in the same city as the relay region
  • The connection to the relay stays open (QUIC or WebSocket)
  • Every trade's slot delta is recorded and checked weekly

Conclusion

No sender can promise the same slot: the leader, the network and other traders all play a part, which is why 0-slot can't be guaranteed. What you control is how early you read, how much you build ahead and how directly you send.

Get started with AllenHark Relay