Solana MEV and Jito relay

In 2025 my main work was Solana MEV infrastructure. The centre of it is a bundle relay: searcher bots hand it bundles, and it spreads them across eight Jito block-engine regions and more than 4,000 egress addresses while keeping every region's rate limits. It was written in Go with gRPC and later ported to Rust on tokio and axum.

Around it: a Rust atomic-arbitrage bot that sends Jupiter routes in Jito bundles with Kamino flash loans, compute budgets tuned for 22 DEXs and an on-chain profit guard; a Yellowstone gRPC monitor that decodes competitors' MEV transactions with lookup-table resolution; and pool discovery with RPC latency ranking feeding a self-hosted Jupiter router.

The globe above is a simulation of the relay's routing, not live traffic.

Bots keep speaking the block engine's HTTP JSON-RPC format; the relay converts each bundle to gRPC and sends it to a regional endpoint. One port rotates across every region and each pinned port names a single region, so choosing a region is a port number and the bot's code does not change. Connections are pooled per region.

The relay was built for 30,000 to 60,000 requests a second across regions, fire-and-forget with retries. At that rate every egress address and region pair has its own budget: a token bucket, plus a cooldown whenever the engine answers with Retry-After.

Under load the first version's throughput collapsed. Three causes: limiter state drifted out of sync between workers, an egress address was locked before it was actually ready to send, and a check-then-act race let two workers take the same slot. The fix was one shared atomic limiter and a min-heap ready queue ordered by the time each pair may send next, so a sender takes the earliest ready pair instead of polling for one.

• Proxy wait, before13–28 ms
• After<0.5 ms

1. <0.5 msproxy wait, from 13–28

   Contention found and removed

   A shared atomic limiter and a ready queue replaced per-worker state and early locking, and the race went with them.

2. ~300kgoroutines, uncapped

   Backpressure instead of a pile-up

   At 10,000 requests a second with every address cooling down for 30 seconds, an uncapped relay would hold about 300,000 goroutines and the memory that comes with them. A cap on requests in flight turns the burst into a queue.

3. Go → Rusttokio, axum

   Same front, new runtime

   The Rust port on tokio and axum keeps the relay's contract: JSON-RPC in, one port per region, the rotating port across all of them.

4. 0trailing bytes

   Decoders that are exact, not close

   124 recorded Jupiter v6 instructions decode with nothing left over, and a port of a closed executor's public ABI round-trips encode and decode.

Before building another strategy I measured where Solana arbitrage revenue actually lands, from public chain data, and took five of the winning bots apart. Each claim is tagged observed, inferred or unknown, and one standard-library Python command recomputes every table offline.

1. $87k

   a day earned by the top 25 circular-arbitrage wallets combined; the first takes 39%

2. 86%

   of sampled gross is two-hop flow through meme-coin pools

3. $0.003

   median gross per trade for plain SOL/USDC two-hop between AMMs

4. 9% vs 38%

   of revenue spent on costs by bundle-only bots versus bots that spray outside bundles

These figures describe other wallets' activity, measured on 20 and 21 October 2026. They are not my volume or my returns. More in Measure before you build.

Relay

• Go
• gRPC
• Rust
• tokio
• axum
• SOCKS5 and bound-address egress

Solana

• Jito bundles
• Yellowstone gRPC
• Jupiter v6
• Kamino flash loans
• address lookup tables
• Solana Go SDK

Research

• Python (standard library)
• Solana RPC
• Dune SQL

The method carried over to an EVM layer-2 arbitrage bot, built detection-first: it reads and measures before anything signs. The relay's design is written up in a post on its throughput.