How to Land Solana Transactions in the Same Slot (0-Slot Execution)

November 20, 2025AllenHark Team

How to Land Solana Transactions in the Same Slot

In the high-stakes world of Solana MEV and high-frequency trading (HFT), speed isn't just about milliseconds—it's about slots.

A Solana slot lasts approximately 400ms. If you identify an opportunity in slot N (e.g., a large liquidity injection or a price discrepancy), but your transaction lands in slot N+1 or N+2, you've likely missed the trade.

To win, you need 0-Slot Execution: the ability to read state, sign a transaction, and land it on the leader. Specifically, you must process information from shreds and send it to the AllenHark relay in less than 20ms for same-block inclusion.

Why Standard Methods Fail

Most traders fail to achieve same-slot execution because they rely on infrastructure designed for general users, not HFT.

1. Public RPCs are Too Slow

When you send a transaction via a public RPC (e.g., mainnet-beta.solana.com or standard provider endpoints), your transaction goes through multiple hops:

  1. Load Balancer: Routes your request to an available node.
  2. RPC Node Processing: Validates signature and simulation.
  3. Gossip Network: The RPC node broadcasts your transaction to the rest of the network via Gossip.
  4. Leader Ingestion: The current leader eventually picks it up from the Gossip churn.

Result: This process typically takes 500ms to several seconds, guaranteeing you miss the current slot.

2. Jito Bundles Can Be Delayed

Jito is excellent for atomic inclusion and tip-based incentives, but it introduces its own latency. Jito block engines must:

  1. Receive your bundle.
  2. Simulate it against the current bank.
  3. Forward it to the Jito-Solana validator.

During periods of high congestion, the Jito auction mechanism itself can become a bottleneck. While safer than public RPCs, it doesn't guarantee instant propagation for 0-slot reaction times.

The Solution: Direct Leader Relays

To land in the same slot, you must bypass the gossip network entirely. You need a direct line to the current block producer (the Leader).

Enter AllenHark 0-Slot Relay

AllenHark’s 0-Slot Relay is built specifically for this purpose. It connects your bot directly to our proprietary network of staked validators and partners.

How it works:

  1. Direct Ingestion: You send your signed transaction via QUIC to our Frankfurt relay.
  2. Zero-Hop Routing: We identify the current leader and the next 3 scheduled leaders.
  3. TPU Forwarding: We blast your transaction directly to the Leader's TPU (Transaction Processing Unit) port via reserved, high-QoS connections.

By skipping the RPC validation overhead and the gossip network, AllenHark reduces propagation time from ~800ms to 0.1ms.

How to Implement 0-Slot Execution

To achieve this in practice, your architecture needs to look like this:

  1. Read Fast: Use AllenHark gRPC or Shreds to detect the opportunity instantly (reading from shreds takes about 0.02ms).
  2. Compute Fast: Your bot logic should run on Co-located Servers in Frankfurt to minimize internal latency (<1ms).
  3. Send Faster: Transmit the transaction immediately to AllenHark Relay.

Example Workflow

// 1. Receive signal via gRPC (Slot N, T=0.02ms)
stream.on('data', async (data) => {
  
  // 2. Build Transaction (T=0.05ms)
  const tx = buildArbitrageTx(data);
  
  // 3. Send via AllenHark 0-Slot Relay (T=0.1ms)
  // Bypasses public RPC, hits Leader TPU directly
  await relayClient.send(tx, {
    skipPreflight: true,
    maxRetries: 0 // Speed is everything
  });
  
  // Result: Transaction lands in Slot N (Total &lt; 1ms)
});

Conclusion

If you are tired of seeing "Blockhash not found" or landing trades one slot too late, it's time to upgrade your propagation layer.

Stop using public RPCs for sending. Switch to AllenHark 0-Slot Relay and start landing your trades when they actually matter.

Get Started with AllenHark Infrastructure