Sign inGet started

The Infrastructure Stack for In-Slot Solana Execution

Building a serious MEV or arbitrage bot? Here is the exact hardware, network, and software stack you need to land a transaction in the slot you read the signal in.

  • 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.

"What server do I need?" is the most common question we get from aspiring MEV searchers.

But in-slot execution—landing a transaction in the slot in which you read the signal—isn't just about buying a big server. It's about the entire pipeline.

Here is the battle-tested infrastructure stack required to consistently win on Solana.

1. The Hardware (Co-Location is Mandatory)

You cannot compete from AWS us-east-1 or your home fiber connection. Speed of light is your enemy.

  • Location: You must be near the stake. Frankfurt (FRA) is one of the largest Solana hubs, and it is where AllenHark's relay and data feeds run.
  • The Server:
    • CPU: High-frequency cores are king. AMD EPYC 9004 series (Genoa) or Ryzen 7950X. You need single-core performance for transaction signing and logic.
    • RAM: DDR5 ECC Memory. Fast memory access is crucial for processing Shred streams.
    • Network: 10Gbps or 25Gbps uplink.

Recommendation: AllenHark Co-Location offers single-tenant AMD bare-metal servers (Ryzen 7950X, Ryzen 9950X, EPYC) in Frankfurt, in the same city as the relay and the shred feeds.

2. The Read Layer (Signal Detection)

You can't act on what you can't see. A public RPC only tells you what happened once the block is done.

  • Requirement: You need to see the "future" before it's finalized.
  • Solution: Solana Shreds (Turbine).
    • Shreds are the UDP packets validators use to spread blocks across the network (Turbine).
    • Listening to shreds allows you to see a transaction while the leader is still building the block.
    • AllenHark Shreds delivers them as raw shreds over UDP (Dedicated), or as reconstructed entries over gRPC or UDP.

3. The Write Layer (Propagation)

This is where most stacks fail. You have the signal, you built the tx, but you send it through public RPC and gossip.

  • Requirement: Direct-to-Leader delivery.
  • Solution: AllenHark Relay.
    • Bypasses gossip.
    • Carries your transaction over private connections straight to the current leader.
    • Accepts QUIC, WebSocket and HTTPS, and Jito bundles.

The Complete Architecture

Here is how the pieces fit together:

  1. Ingest: AllenHark Shreds stream block data to your co-located server while the block is still being produced, before RPC confirmation.
  2. Process: Your Rust/C++ bot decodes the entries, identifies an arb, and signs a tx.
  3. Send: You push the tx to AllenHark Relay over a connection that is already open.
  4. Land: The Relay hands it straight to the current leader, bypassing gossip.

The whole loop has to fit inside one slot, well under a second. Steps 1-3 are dominated by network transit, not by your code — which is why proximity to the relay and to the stake is what actually decides whether you land in slot N.

Result: You give yourself the best chance of landing in slot N, ahead of bots that still send through standard RPCs.

Conclusion

Infrastructure isn't a commodity; it's your competitive advantage. You can write the smartest code in the world, but if your infrastructure sits an ocean away from the leader, you will lose to a simpler bot running closer to it.

Ready to build your stack?