Anti-MEV on Solana: how Jito private relays actually work.

What MEV is, in one paragraph

Maximal Extractable Value is the value a block producer (or, on Solana, a validator) can capture beyond protocol-level fees by reordering, inserting, or censoring transactions inside a block they are building. In every public-mempool blockchain, MEV is unavoidable — the moment a transaction is broadcast, it is visible to anyone with a node, and a sufficiently sophisticated actor can profit from that visibility. On Solana, the dominant MEV strategies are sandwich attacks against AMM trades, front-running on bonding curves, and arbitrage between concentrated-liquidity ranges.

Sandwich attacks — the anatomy

The sandwich is the canonical MEV strategy. The mechanic, on Solana:

1. You broadcast a buy transaction into the public mempool.
2. An MEV bot's mempool listener observes the transaction within milliseconds, reads the AMM pool state your transaction will touch, and computes the slippage your trade will produce.
3. The bot constructs two of its own transactions — a buy before yours (front-run), and a sell after yours (back-run) — and submits them to a validator with a higher priority fee than yours.
4. The validator orders the three transactions: bot buy, your buy, bot sell. The bot exits at the price your buy created. The bot keeps the spread; you pay it as slippage.

The economics are unforgiving. On a 0.5 SOL buy against a thin Pump.fun curve, the median sandwich extraction we measured in early 2026 was 32–46 bps. On a 5 SOL buy against a recently-graduated Raydium pool, the median was 88–140 bps. Larger trades extract more, with sublinear scaling because the sandwich bot's own tip costs eat into the take.

Solana vs. Ethereum: same idea, different geometry

Ethereum's MEV landscape is mature: Flashbots' MEV-Boost coordinates a builder market, searchers compete for inclusion via tip bidding, and the public mempool is increasingly bypassed by direct relay submissions. Solana's MEV landscape is younger, faster, and structurally different:

• No mempool by protocol. Solana validators do not maintain a strict mempool — incoming transactions are forwarded leader-to-leader. But "transactions in flight" exist for ~400 ms during forwarding, and that window is enough for a fast bot.
• 400 ms slot time. The window between transaction broadcast and inclusion is much shorter, but the MEV game adapts — bots run their own gossip listeners and their own forwarders.
• Block-builder concentration. A small set of validators (the leaders during peak Solana hours) handle the majority of high-value blocks. Reaching them is the relevant problem.
• Jito. Solana's de facto MEV infrastructure provider. Operates a private-relay network and a tip auction.

The Jito architecture

Jito is, in shape, three things:

1. A relay network that accepts signed bundles via authenticated RPC and forwards them to a curated set of validator block-builders.
2. A tip auction where each bundle includes a separate tip transaction, paid only if the bundle lands in a block.
3. A modified validator client (Jito-Solana) that the participating validators run, which knows how to consume bundles atomically.

The crucial property: when you send a bundle to a Jito relay, the bundle is not broadcast on the public gossip network. The bundle is forwarded only to the Jito-participating validator currently producing the block — and only that validator, plus the relay operator, ever sees it before inclusion.

From the perspective of a sandwich bot listening on the public gossip, your trade simply does not exist until it has already been included in a block — at which point the sandwich opportunity has closed.

Bundles vs. transactions

A Jito bundle is a list of up to five transactions that the validator must include atomically — all or none, in the order specified. This is the structural primitive that makes anti-MEV routing work, because it lets you specify pre- and post-trade transactions that compose with your main trade in a single atomic unit.

For a Pump.fun-style trade, a typical bundle structure is:

1. Setup transaction (account creation, ATAs, etc.) — sometimes elided.
2. Your buy transaction.
3. The tip transaction — a transfer to a Jito-controlled tip account, conditional on inclusion.

Three properties to internalize:

• Atomicity. If the validator cannot include all transactions in the bundle, the bundle is dropped and no transaction lands. There is no "partial fill" risk where the tip lands but the trade does not.
• Ordering preservation. The validator includes the bundle's transactions in the specified order. No reordering, no insertion of foreign transactions between them.
• Privacy. The bundle is never gossiped. Only the relay and the destination validator see it before inclusion.

The priority-tip auction

Validators participate in Jito because Jito routes paying customers to them. A validator producing a block prefers bundles with higher tips because it captures the tips for that slot. The tip is therefore both an inclusion mechanism and an auction.

The tip is denominated in SOL, paid via the tip transaction inside the bundle, and is conditional on inclusion. If the bundle is dropped (atomicity failure, slot ended, validator switched away from Jito), no tip is paid.

Tip pricing is a moving target. Tips that are too low miss inclusion during congested slots. Tips that are too high turn into the same MEV tax in a different costume — you are paying the validator the same value the sandwich bot would have extracted. The right tip is the smallest tip that consistently lands.

That tip is empirical. It varies by hour, by overall network priority-fee percentile, by which leader is producing the slot, and by bundle composition. There is no fixed answer — there is only a tuning loop.

The public-mempool tax (with worked numbers)

Let us put numbers on what mempool routing costs. Take a 1,000 SOL Pump.fun session that fires roughly 12,000 trades over 90 minutes:

• Median trade size: 0.07 SOL (small retail-persona trades dominate).
• Median sandwich extraction on a small trade against a thin curve: 38 bps.
• Per-trade extraction in SOL: 0.07 × 0.0038 = 0.000266 SOL.
• Across 12,000 trades: 12,000 × 0.000266 = ~3.2 SOL.

3.2 SOL on a 1,000 SOL session is 0.32% — call it 16% of a 2% session commission. Quietly extracted, not visible on any dashboard, paid to MEV bots over the course of the session.

The same session routed through Jito with a tip-tuning loop landing tips at the 50th percentile of network priority fees costs roughly 0.6–0.9 SOL in tips total — call it 0.07–0.09% of session volume. The net saving is ~2.3 SOL on the 1,000 SOL session, every session.

Bundle tip auto-tuning

The naive tip strategy is a fixed range — say 0.0001 to 0.001 SOL randomized per bundle. This works in calm conditions and breaks the moment the network is busy. The fix is a tip-tuning loop that:

1. Samples the recent priority-fee distribution from a Solana RPC every few seconds.
2. Maintains a rolling target percentile (typically the 50th — high enough to land, low enough to not overpay).
3. Sets the next bundle's tip to the percentile target plus a small random jitter.
4. Watches its own bundle landing rate and adjusts the percentile target up or down based on miss rate.

Implemented well, this loop keeps the bundle landing rate above 99% during normal conditions, and gracefully degrades during network-wide congestion events — e.g., the brief Solana priority-fee spikes that follow Pump.fun launchpad rotations.

Failover and "fail closed"

One subtle trap: when a Jito relay is unhealthy, a poorly-engineered bot will silently fall back to public-mempool routing because the bundle send failed. From the operator's dashboard, the session keeps running. Under the hood, every trade is now exposed to MEV.

The right behavior is to fail closed. If the primary Jito relay is unhealthy, fall over to a secondary Jito relay. If all configured relays are unhealthy, queue the trades and wait — do not silently degrade to public routing. The user contracted for anti-MEV execution. The bot's job is to honor that contract or surface the failure.

Practically, this means maintaining a primary + 2–3 secondary Jito endpoints in different regions, health-checking each one continuously, and rotating to the healthiest available endpoint per bundle. We documented our exact failover policy on the security page.

What we measure across 5,000+ trades

Cross-sample of the 5,000 most recent trades fired across all sessions in the last 14 days:

• Bundle landing rate (Jito routed): 99.6%.
• Median tip per bundle: 0.000273 SOL (50th percentile of network priority fees during the sample period).
• p99 tip per bundle: 0.0019 SOL (during a brief congestion spike on 2026-04-14).
• Estimated MEV extraction avoided: ~9.8 SOL across the 5,000 trades, vs. a public-mempool baseline.
• Failovers triggered: 14 (relay-level), all auto-resolved within 800 ms.

The headline: anti-MEV routing on Solana is no longer optional for any operator running meaningful volume. The cost is a tipping loop and a failover policy. The benefit is the 25–80 bps per trade you stop losing to bots that exist exclusively to tax you.