Sign inGet started

What Is 0-Slot Landing on Solana?

0-slot landing means your Solana transaction lands in the same slot as the event it reacts to. How it works, what decides it, and how to measure it.

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

0-slot landing means your transaction lands in the same slot as the event it reacts to, such as a token launch, a new pool or a large swap: a slot difference of zero. A Solana slot lasts about 200 ms, so seeing the event, deciding, signing and reaching the leader all have to fit in what is left of that slot.

This post explains the three things people mean by "0 slot", how a slot works on Solana today, what decides the slot your transaction lands in, and how to measure your own 0-slot rate with a short script. It ends with the services that sell fast landing, described from their own pages.

Disclosure: AllenHark sells a relay, data feeds and servers used for 0-slot trading. AllenHark Relay was first sold under the name 0-slot; it is not 0slot (0slot.trade), a separate company. Facts about other services come from their own pages, linked and checked 6 November 2026.

Three things "0 slot" can mean

MeaningCounted fromWho uses it
Same slot as the triggerThe slot of the event you react toSnipers and searchers. Pump.fun traders call that slot "block 0". Helius's zero-slot guide uses this sense.
First slot after you sendThe slot when you sentSenders measuring their own speed. P2P's help article defines slot-0 landing this way.
0slot, the companyNot a measure0slot is a transaction sending service named after the idea.

The first two differ by however late you saw the event. Say a pool is created in slot 1,000, your feed delivers it after slot 1,001 has started, and your buy lands in 1,001. Counted from your send, that's slot 0. Counted from the trigger, it's +1, and the snipers who landed in slot 1,000 bought ahead of you.

When the trade depends on an event, measure from the trigger. The rest of this post uses that sense, and the measuring section covers both.

How slots and leaders work today

  • A slot is about 200 ms. Ten one-minute samples from mainnet's getRecentPerformanceSamples on 6 November 2026 gave 211 to 216 ms per slot. Many guides still say 400 ms.
  • One leader builds each slot's block. Leaders take turns of four consecutive slots. Forty consecutive mainnet slots we read on 6 November came in runs of four, with one validator holding two turns in a row.
  • The leader streams its block while building it. It sends the block out in pieces called shreds as it goes, so a feed that reads shreds can see a transaction while its slot is still open. See what Solana shreds are.
  • Alpenglow is live. It replaced Solana's consensus on 21 October 2026. Blocks finalize in roughly 150 ms, and confirmed and finalized now describe the same state. Execution, transaction formats and fees didn't change. One slot can briefly have more than one candidate block, so count landings from confirmed data, not processed. More in Alpenglow for RPC and gRPC users.

Within one slot, the leader records transactions in order. Yours can only land after the trigger, because the trigger has already executed by the time you see it. The best possible result is landing right behind it in the same block.

What has to happen inside one slot

StepWhere the time goes
1. The trigger executesThe leader records it somewhere in slot N
2. Your feed sees itShreds leave the leader and reach your feed, then your server
3. You decide, build and signYour own process
4. You sendYour server to your sender, then the sender to the leader's transaction port
5. The leader schedules itThe leader's scheduler, which orders by priority fee
6. It is recordedStill slot N if the leader is still building that block

Your budget is whatever is left of slot N after step 1. A trigger early in the slot leaves you most of 200 ms. A trigger at the very end leaves almost nothing, and if slot N was the last of its leader's four, slot N+1 belongs to a different validator, possibly on another continent.

What decides the slot you land in

FactorWhy it mattersWhat to do
Your feedShreds arrive before a gRPC stream, which arrives before RPC WebSockets, all else being equalRead shreds, or gRPC at processed, from a feed near your server. See shreds vs gRPC vs WebSockets.
Your hot pathOne RPC call between the trigger and the send costs at least a network round tripKeep state in memory, cache the blockhash, and prebuild what you can
PreflightSimulation on the RPC node adds time before the transaction movesSend with skipPreflight once you've tested the transaction
DistanceEvery network leg adds time, and the leader changes every four slotsRun your bot near your sender, and use a sender that reaches the current and next leaders. See why location matters.
Your send pathUnstaked connections are throttled first when a leader is busy (SWQoS). Jito tips count only with Jito leaders.Send through staked connections or a relay. See SWQoS vs Jito vs a relay.
Priority fee and tipOnce inside, the leader's scheduler ranks transactions by fee per unit of cost. Tips pay senders and Jito's auction.Set the priority fee from recent fees on the accounts you write. See why transactions arrive late even with priority fees.
The leaderIts client, location, load and place in its four-slot turn are not yours to chooseGroup your results by leader to see where you lose

Speed decides whether you land in slot N. Fees and tips decide where you sit inside it. Nozomi's docs make the point: when transactions write the same account, more than one can land in the same slot, and the tip decides who gets the better position. On a Pump.fun launch, block 0 with 40 buys ahead of you is a much worse price than block 0 right behind the create. See Pump.fun block-0 sniping.

Where Jito bundles fit

Jito bundles run up to five transactions in order, all or nothing, inside one slot. They don't help you land beside someone else's transaction: a bundle holds only transactions you have signed copies of, and the trigger has executed by the time you see it. Jito runs its auctions at 50 ms ticks, a quarter of a 200 ms slot, and a tip does nothing when the leader isn't running Jito's client. Use a bundle when your own legs must land together. For one fast transaction, use a sender that covers Jito and non-Jito leaders.

Why 0-slot can't be guaranteed

The leader decides what goes into its block. A transaction can reach it in time and still be scheduled behind others, fail because the price moved past your limit, or arrive just after the block closes. Treat 0-slot landing as a rate you measure and improve, not a promise. A path that lands quickly but drops one transaction in ten isn't fast.

How to measure your 0-slot rate

Two numbers, two tools:

  • From the trigger: your landing slot minus the trigger's slot. Log both signatures each time your bot acts, then run the script below.
  • From your send: your landing slot minus the slot when you sent. The harness in Solana bot latency: where your trade loses time measures it, with timings for every stage.

Code: slot delta from the trigger

slot-delta.mjs reads a file of signature pairs, the trigger and then yours. For each pair it prints both slots, the slot delta and each slot's leader. When the delta is 0, it also prints how many transactions landed between the two.

JavaScript
// slot-delta.mjs: did your transaction land in the same slot as the one it reacted to?
// For each pair of signatures (the trigger, then yours) it prints both slots, the
// slot delta, each slot's leader and, when the delta is 0, how many transactions
// landed between the two in that block.
// npm i @solana/web3.js@1   (Node 18 or later)
//
// RPC_URL   your RPC endpoint (default: Solana's public mainnet RPC, which is rate-limited)
// Usage:    node slot-delta.mjs pairs.txt
//           pairs.txt holds one pair per line: <trigger signature> <your signature>
import fs from "node:fs";
import { Connection } from "@solana/web3.js";

if (!process.argv[2]) throw new Error("usage: node slot-delta.mjs pairs.txt");
const rpc = new Connection(process.env.RPC_URL ?? "https://api.mainnet-beta.solana.com", "confirmed");
const pairs = fs
  .readFileSync(process.argv[2], "utf8")
  .split("\n")
  .map((line) => line.trim().split(/\s+/))
  .filter((p) => p.length === 2);

// The slot of every signature, 256 per call, searching the node's whole history.
// A transaction that failed on-chain still landed, so keep its slot and note the error.
const sigs = [...new Set(pairs.flat())];
const status = new Map(); // signature -> { slot, failed }
for (let i = 0; i < sigs.length; i += 256) {
  const chunk = sigs.slice(i, i + 256);
  const { value } = await rpc.getSignatureStatuses(chunk, { searchTransactionHistory: true });
  value.forEach((st, k) => st && status.set(chunk[k], { slot: st.slot, failed: st.err !== null }));
}

// Who led each slot: one call for the whole range when it spans under 5,000 slots.
// Nodes keep leader schedules for recent epochs only, so old slots may show "-".
const slots = [...new Set([...status.values()].map((s) => s.slot))];
const leader = new Map();
if (slots.length) {
  const first = Math.min(...slots);
  const span = Math.max(...slots) - first + 1;
  try {
    if (span <= 5000) (await rpc.getSlotLeaders(first, span)).forEach((pk, k) => leader.set(first + k, pk.toBase58()));
    else for (const s of slots) leader.set(s, (await rpc.getSlotLeaders(s, 1))[0].toBase58());
  } catch {}
}

// Same-slot pairs: the block lists transactions in the order they were recorded,
// so the gap between the two positions is how many landed in between.
const order = new Map(); // slot -> signatures in block order
async function position(slot, sig) {
  if (!order.has(slot)) order.set(slot, (await rpc.getBlockSignatures(slot)).signatures);
  return order.get(slot).indexOf(sig);
}

const counts = { "+0": 0, "+1": 0, "+2": 0, "+3 or more": 0, "earlier": 0, "not found": 0 };
console.log("trigger slot   your slot  delta  in the block                 trigger leader  your leader");
for (const [trigger, mine] of pairs) {
  const t = status.get(trigger), m = status.get(mine);
  if (!t || !m) {
    counts["not found"]++;
    console.log(`${!t ? "trigger" : "your transaction"} not found: ${!t ? trigger : mine}`);
    continue;
  }
  const delta = m.slot - t.slot;
  let where = "";
  if (delta === 0) {
    const [ti, mi] = [await position(t.slot, trigger), await position(m.slot, mine)];
    where = ti < 0 || mi < 0 ? "?" : mi > ti ? `${mi - ti - 1} between` : "ahead of the trigger";
  }
  counts[delta < 0 ? "earlier" : delta >= 3 ? "+3 or more" : `+${delta}`]++;
  console.log(
    `${String(t.slot).padStart(12)} ${String(m.slot).padStart(11)} ${(delta < 0 ? String(delta) : `+${delta}`).padStart(6)}` +
      `  ${[where, m.failed && "yours failed"].filter(Boolean).join(", ").padEnd(27)}  ${(leader.get(t.slot) ?? "-").slice(0, 8).padEnd(14)}  ` +
      `${(leader.get(m.slot) ?? "-").slice(0, 8)}${leader.get(t.slot) && leader.get(t.slot) === leader.get(m.slot) ? " (same)" : ""}`,
  );
}
console.log(`\n${pairs.length} pairs: ` + Object.entries(counts).filter(([, n]) => n).map(([k, n]) => `${k}: ${n}`).join(", "));
Terminal
npm i @solana/web3.js@1
export RPC_URL="https://your-rpc-endpoint"
node slot-delta.mjs pairs.txt

The script only reads, so it costs nothing to run. Point RPC_URL at your own RPC for more than a handful of pairs, since the public endpoint is rate-limited.

How we tested it: on 6 November 2026 we ran it against mainnet's public RPC with seven pairs taken from real blocks. They were two transactions from one block, both ways round, and one each from the next slot and five slots later. We added a reversed pair across slots, a made-up signature and a transaction that failed on-chain. Every row matched what the blocks show:

Text
trigger slot   your slot  delta  in the block                 trigger leader  your leader
   466077471   466077471     +0  49 between                   Fd7btgyS        Fd7btgyS (same)
   466077471   466077471     +0  ahead of the trigger         Fd7btgyS        Fd7btgyS (same)
   466077471   466077472     +1  yours failed                 Fd7btgyS        2GUnfxZa
   466077471   466077476     +5                               Fd7btgyS        9jxgosAf
   466077472   466077471     -1                               2GUnfxZa        Fd7btgyS
your transaction not found: 4r8is43ysB6vmY4UbtpF72j4RhLwDr4wFLSpD4rTtW61DSpiGHCx1r5hBRRSvfdzSAYbCEadNgorcTEUAkmyimyv
   466077471   466077471     +0  4 between, yours failed      Fd7btgyS        Fd7btgyS (same)

7 pairs: +0: 3, +1: 1, +3 or more: 1, earlier: 1, not found: 1

The pairs are other people's transactions, so these rows show that the script reads blocks correctly. They say nothing about anyone's landing speed. The +1 row shows a common case: slot 466077471 was the last of its leader's turn, so the next slot had a different leader.

Reading your results

  • Mostly +0 with few in between: you're fast and early. Keep measuring, since leaders and competition change.
  • Mostly +0 with many in between: you're in time but not first. Look at your priority fee and tip, and at how early your feed sees the trigger.
  • Mostly +1: you're one step short. Time each stage with the latency harness to find which one.
  • +1 only when the leader changes: your sender doesn't reach the next leader quickly. Try a sender with paths to upcoming leaders, or one nearer to them.
  • +2 or more, or missing: the send path is the problem. Check for preflight, unstaked connections and expired blockhashes.

The setup, end to end

  1. Feed: shreds, or gRPC at processed, delivered near your server. Detect new Pump.fun tokens and pools in real time has working code.
  2. Server: in the same city as your feed and your sender, not a laptop or a far-off cloud region.
  3. Bot: no network calls between the trigger and the send, a cached blockhash, and preflight off.
  4. Sender: staked connections or a relay, over a connection you keep open, preferably QUIC.
  5. Fee: a priority fee priced from the accounts you write, plus the sender's tip.
  6. Measurement: the slot delta of every trade, grouped by leader, checked every week.

The hands-on version, with a send example, is how to land Solana transactions in the same slot.

Services that sell fast landing

How we compared: each row says what the service's own pages say about how it sends and about slots, checked 6 November 2026. We didn't benchmark landing rates or latency, and we list no prices or tip amounts. Follow the links for current figures.

ServiceHow it sends, per its own pagesWhat its pages say about slots
AllenHark RelayFive channels at once, including stake-weighted QUIC, QUIC and UDP to the leaders, and the Jito Block Engine. Takes QUIC, WebSocket and HTTPS, with regions in Frankfurt, Amsterdam, New York and Tokyo.Lands transactions in the same block, at 0.1 ms over QUIC. First sold under the name 0-slot.
Helius SenderSends through all its pathways at once (Helius, Jito, Harmonic, Rakurai and others), or through one SWQoS path on a cheaper tier. Every transaction needs a tip and a priority fee. Regional endpoints in seven cities.The Sender page makes no slot claim. Helius's zero-slot guide pairs Sender with its LaserStream feed.
Jito Block EngineBundles of up to five transactions, all or nothing, and single transactions. Auctions run at 50 ms ticks, and tips count only with leaders running Jito's client.Bundles execute within the same slot.
Nozomi (Temporal)Block builders (Jito, Harmonic) or Nozomi's staked connections. Orders by tip, with first arrival breaking ties, and retries until the transaction confirms or its blockhash expires.Several transactions writing one account can land in the same slot. The tip decides position.
0slotA staked_conn sendTransaction that connects straight to its validator node, with dedicated SWQoS per user. A tip in every transaction, on plans sized by transactions per second. Endpoints in New York, Frankfurt, Amsterdam, Tokyo and Los Angeles.Its home page headline is "It's 0 slot!".
P2P Syncro SenderForwards each transaction through all enabled channels at once, including staked TPU connections to the current and upcoming leaders. Public endpoint validated by tip, or a private endpoint with an API key.Defines slot-0 landing as the first slot after you send, and says inclusion timing is not guaranteed.

Sources: AllenHark Relay docs; Helius Sender and Helius's zero-slot guide; Jito low-latency send; Nozomi tipping and FAQ; 0slot home page and docs; P2P's slot-0 article and Syncro Sender docs. Checked 6 November 2026.

To compare senders yourself, send the same trade through each at once as durable-nonce variants, so at most one copy lands and one tip is paid. Then run the slot-delta script on the results. SWQoS vs Jito vs a relay has the code and its caveats. For a wider comparison of relays, see Solana MEV relay services compared.

Where AllenHark fits

Run the script above against us, from your own server, as you would against anyone else.

  • Send: AllenHark Relay. Formerly 0-slot. It lands transactions in the same block, at 0.1 ms over QUIC, and takes Jito bundles. Each API key gets 10 requests per second by default, more on request. The relay docs list the four regions and recommend co-locating with one for the 0.1 ms figure.
  • Feed: ShredStream. The block as the leader sends it out: decoded entries over gRPC or UDP, raw shreds over UDP, or Jito's proxy protocol. It runs from Frankfurt, with Amsterdam on some plans.
  • Feed: Yellowstone gRPC. Streams at processed, with a from_slot replay of about 48 hours.
  • Server: co-location. Single-tenant bare metal in Frankfurt, Amsterdam and Chicago, and cloud VPS in Frankfurt, paid monthly.
  • Another route: Slipstream. A separate product from Relay. It routes each transaction through the worker nearest the current leader, with 0.2 ms leader RTT.
  • All of it, managed: AllenHark bots. They detect in 0.2 ms, send through AllenHark Relay by default and can add other fast senders (Fast senders).

FAQ

What does 0 slot mean on Solana?

Your transaction landed in the same slot as the event it reacted to, a slot delta of zero. Some senders use it to mean the first slot after you sent, which is easier to hit.

Is 0 slot the same as same block?

Yes, once the slot is final. One leader builds one block per slot. Under Alpenglow a slot can briefly have more than one candidate block, but at most one is finalized.

How long is a Solana slot?

About 200 ms. We measured 211 to 216 ms on mainnet on 6 November 2026. Leaders take turns of four slots, so a turn lasts under a second.

Is 0-slot landing guaranteed?

No. The leader decides what goes in its block and in what order. Speed, fees and your send path raise the odds, so measure your rate and count the transactions that never land.

Is 0slot the same as AllenHark Relay?

No. 0slot (0slot.trade) is a separate company. AllenHark Relay was first sold under the name 0-slot, and its old address now leads to the Relay page.

Do I need Jito for 0-slot landing?

No. Jito bundles are for legs that must land together, and they only land with leaders running Jito's client. For one fast transaction, use staked connections or a relay that covers all leaders.

Did Alpenglow change 0-slot landing?

Execution, transaction formats and fees didn't change. Blocks now finalize in roughly 150 ms, and a slot can briefly have more than one candidate block. Measure from confirmed data, and if your sender counted ticks to time the slot, it needs its own slot clock now.

Sources

Checked 6 November 2026, except where noted.