Solana Searcher Infrastructure: Colocation, RPCs and Slot Leaders

Winning Jito bundles consistently is an infrastructure problem before it is a strategy problem. The searcher who lands their bundle 40 ms ahead of yours does not necessarily have a better arbitrage detector — they are almost certainly closer to the block engine, on a faster RPC, and routing their submission to the correct regional endpoint based on the active slot leader. This guide covers the concrete infrastructure choices a Solana searcher needs to make in 2025 to compete on latency, not just logic. Our Solana MEV & Arbitrage Bot service is built on exactly this stack.

Why Solana Searcher Infrastructure Is Different from EVM

On Ethereum, MEV infrastructure centers on Flashbots relay and builder relationships. Solana's model is different: Jito runs a block engine that validators opt into, and searchers submit bundles directly to regional Jito endpoints. There is no public mempool to crawl — you are racing other searchers to submit a bundle the validator's block engine will accept and include. Latency to the block engine endpoint, not mempool visibility, is the critical path. Additionally, Solana slots are 400 ms long and validators rotate on a published schedule, which means you have a deterministic window per slot and can pre-select your submission target.

Choosing an RPC Provider

Your RPC is your eyes. Every opportunity you detect — a large swap about to clear, a price dislocation opening across pools — surfaces first through an RPC or a dedicated account-streaming connection. In practice, for competitive searcher work you need two things from your RPC:

• Geyser / account streaming access. Standard JSON-RPC getAccountInfo polling is too slow. You need a provider that exposes a Geyser plugin interface or a websocket account-subscription endpoint with sub-100 ms delivery. Helius and Triton are the two most-used production options in 2025; both expose Geyser-compatible streams and have regional nodes.
• Low-latency sendTransaction / bundle endpoints. Confirmation of your own submissions matters for nonce management and retry logic. Point your sends to the same region as your block engine target, not to a generic load-balanced endpoint on the other side of the planet.

A common pattern: use Helius enhanced websockets for detection and Jito's own sendBundle RPC for submission. This avoids the latency added by routing your bundle through a third-party RPC's relay layer.

Colocating Near Jito Block Engine Endpoints

Jito publishes block engine endpoints in multiple AWS regions: mainnet.block-engine.jito.wtf resolves to a load balancer, but the regional endpoints (amsterdam.mainnet.block-engine.jito.wtf, ny.mainnet.block-engine.jito.wtf, tokyo.mainnet.block-engine.jito.wtf, frankfurt.mainnet.block-engine.jito.wtf) let you target your nearest cluster directly. Ping each from your candidate servers and pick the one closest to your validator distribution target — do not just pick the one closest to you, pick the one closest to where winning validators are running.

In practice, most high-stakes Solana validators run in Amsterdam and Frankfurt for European latency, and in the eastern US (Ashburn/NY) for US validator concentration. For a searcher running MEV across the whole validator set, Amsterdam and NY are the two endpoints worth colocating near. Running a bare-metal or dedicated instance in the same AWS AZ as the endpoint — not a cheap VPS in the same city — drops your round-trip to the block engine to 1–5 ms, versus 20–80 ms from an arbitrary cloud VM.

Do not run a production searcher from a residential connection or a shared cloud compute instance. Variable jitter at the 99th percentile is what loses bundles at the margin.

Tracking the Slot-Leader Schedule

Solana's slot-leader schedule is published on-chain and computable ahead of time from the current epoch's LeaderSchedule account. The getLeaderSchedule RPC call returns which validator is scheduled to produce each slot for the rest of the epoch. This is not a curiosity — it is actionable data:

• If the upcoming slot leader is a Jito-opted-in validator, submitting a bundle makes sense. If they are not opted in, your bundle will not be processed and you are wasting a round-trip.
• The typical strategy is to fetch the leader schedule at epoch start, build a lookup table of upcoming slots, and gate bundle submission to slots where the leader is in Jito's validator set. You can get the current Jito validator list from https://mainnet.block-engine.jito.wtf/api/v1/validators.
• Look ahead 2–4 slots. By the time your bundle traverses the network and is processed by the block engine, the "current" slot may already be past. Targeting the slot that will be active in ~800 ms (two slots out) is a safer default than targeting currentSlot + 1.

A lightweight pre-submission check costs you a few microseconds of local computation and saves you burning tip budget on validators who cannot include your bundle.

The Realistic Latency Budget in 2025

Here is what a competitive latency stack looks like end to end in practice:

• Signal to detection: 5–30 ms from a Geyser stream or a confirmed-block websocket subscription, depending on provider and region.
• Simulation: 1–10 ms for a local transaction simulation using a recent snapshot of on-chain state. Skip remote simulation; it costs 20–60 ms.
• Bundle construction and signing: <1 ms in Rust, 2–5 ms in TypeScript/Node.
• Submission to block engine: 1–5 ms if colocated in the same region; 20–80 ms if not.
• Total end-to-end: a well-tuned stack in the same region as the block engine can achieve 15–50 ms from signal to bundle received. A poorly configured stack running remotely sits at 150–400 ms, which is competitive with nobody.

The 50 ms target is not arbitrary — at 400 ms per slot, you have a narrow window to detect an opportunity, simulate, and submit before the slot closes or competing bundles land.

Tip Calibration and Bundle Success Rate

Infrastructure gets your bundle in front of the block engine in time. Your tip determines whether it gets included. Jito's block engine runs a priority auction among submitted bundles per slot; the validator takes the highest-tipping bundle (net of simulation validity). Tip calibration is empirical: run a searcher in shadow mode, log the tips of included bundles versus failed submissions, and adjust. A starting point in 2025 is 10,000–50,000 lamports for low-competition arb opportunities, scaling with expected profit. Hardcoding a fixed tip is leaving money on the table when competition is low and losing bundles when competition spikes.

The other lever is bundle size. A two-transaction bundle (your setup transaction + arb) is generally more competitive than a longer chain because each additional transaction adds simulation overhead and increases the chance of a stale-account read invalidating the bundle. Keep bundles tight.

Putting It Together: A Production Checklist

Before going live with a Solana searcher, run through these:

• Geyser or enhanced websocket streaming from a provider with a node in your target region
• Bare-metal or dedicated instance colocated within the same AWS region as your primary Jito endpoint
• Pre-computed slot-leader lookup table refreshed at epoch boundaries
• Bundle submission gated to Jito-opted-in validators only
• Local simulation (not remote RPC) using a hot snapshot of account state
• Tip floor set empirically from live auction data, not hardcoded

Each item on that list is independently worth 10–50 ms or a measurable improvement in bundle inclusion rate. None of them require a novel strategy — they are the baseline for running any competitive Solana MEV operation.

---

If you want a production searcher built on this infrastructure — bundle submission, Geyser detection, slot-leader scheduling and tip calibration all included — get in touch and we can scope it out.