Flashbots MEV-Boost vs Jito Bundles: EVM and Solana MEV Compared

Ethereum separates who builds a block from who proposes it. Solana doesn't. That one architectural fact explains almost every practical difference between running a searcher strategy on Flashbots' MEV-Boost and running one on Jito, and it's where any real comparison has to start rather than with slogans about "MEV infrastructure."

MEV-Boost: an auction bolted onto a 12-second slot

MEV-Boost implements proposer-builder separation (PBS) as a sidecar next to a validator's consensus client. Builders — beaverbuild, Titan, rsync, Flashbots' own builder, and a handful of others — assemble full blocks from the public mempool plus private order flow, then submit headers with a bid to relays. Relays verify the bid is real (they hold the full block body, the proposer only sees the header) and forward the highest bid to the validator's MEV-Boost sidecar. The proposer signs blind, trusting the relay not to steal the block or lie about the payment.

Searchers interact with this by sending bundles — an ordered list of transactions, atomic, all-or-nothing — via eth_sendBundle to a builder or relay, targeting a specific block number. If any transaction in the bundle reverts unexpectedly, the whole bundle is dropped by the builder before it ever touches a block, so a failed backrun costs you nothing on gas. That's the single best property of the Flashbots model: you get a free simulation gate.

// eth_sendBundle to a builder/relay
{
  "jsonrpc": "2.0",
  "method": "eth_sendBundle",
  "params": [{
    "txs": ["0xf86d80..."],
    "blockNumber": "0x112a880",
    "minTimestamp": 0,
    "maxTimestamp": 1731000600
  }]
}

The tradeoff is trust distribution. You're trusting a relay not to leak your bundle to a competing builder, trusting a builder not to extract your alpha and replicate it, and trusting the whole PBS chain to resolve in under 12 seconds. MEV-Share reduces some of this by letting you selectively disclose bundle contents to searchers in exchange for a rev-share, but the base model still routes through several semi-trusted hops before a block lands.

Jito: no separate builder, tips paid on-chain

Solana has no PBS. The leader for a given slot runs the Jito-Solana validator client, which bundles a block engine and a relayer directly into the validator software. Searchers submit bundles — up to 5 transactions, still atomic — straight to the block engine over gRPC, and the block engine simulates and orders them by tip, where the tip is a real SOL transfer to one of eight hardcoded Jito tip payment accounts, paid in the same transaction rather than as an out-of-band bid.

// sendBundle: last tx typically pays the Jito tip
{
  "jsonrpc": "2.0",
  "method": "sendBundle",
  "params": [["base58Tx1", "base58TipTx"]]
}

Because Solana's slot time is roughly 400ms and there's no header-only blind-signing step, the whole auction happens far faster and with one fewer trust hop — you're trusting the current leader's block engine, not a chain of relay-builder-proposer. The catch is leader rotation: you're auctioning against whoever is leader in the next slot, and that leader changes every 400ms on a known schedule, so your bundle has to reach the right block engine before the slot flips or it's wasted. Getting that timing right is 80% of what makes a Solana searcher bot profitable, and it's a big part of why colocated infrastructure and low-latency data feeds matter more here than almost anywhere else — the kind of groundwork covered in our piece on Jito vs Firedancer validator latency and in how you stream account and slot updates fast enough to act on them.

A worked example: same backrun, two chains

Say you're backrunning a large swap to rebalance a pool. On Ethereum you'd simulate against the pending mempool tx, build a bundle with your backrun immediately after it, and submit to 3-4 builders simultaneously since inclusion isn't guaranteed by any single one — Flashbots' builder alone captures maybe a quarter of blocks on a good week, so single-relay submission is a losing habit. On Solana you watch for the swap landing (or predict it from a decoded instruction in the mempool-equivalent, since Solana has no public mempool in the Ethereum sense), then send a 2-tx bundle — your backrun plus tip — directly to the current leader's block engine, and you get one shot per slot rather than a multi-block window.

Side by side

Dimension	Flashbots / MEV-Boost	Jito Bundles
Block cadence	~12s (Ethereum)	~400ms (Solana)
Architecture	PBS: builder → relay → proposer	Integrated block engine on leader validator
Bundle size	Unbounded in practice	Max 5 transactions
Payment	Builder bid (off-chain to proposer)	On-chain tip to Jito tip accounts
Failure handling	Reverting bundle dropped pre-inclusion	Same — simulated before inclusion
Trust hops	Builder + relay + proposer	Block engine (leader) only
Public mempool	Yes, plus private order flow	No native mempool
Dominant risk	Relay/builder censorship or leak	Missing the 400ms leader window

Gotchas that actually bite

On Ethereum, don't assume relay neutrality — some relays filter OFAC-sanctioned addresses, which changes your effective inclusion odds depending on which relays you fan out to. On Solana, tip sizing is a live-fire auction every 400ms with no smoothing, so a static tip strategy will get outbid constantly during volatile periods; you need a feedback loop reading recent accepted tip sizes, not a hardcoded lamport figure. Both ecosystems punish naive retry logic — resubmitting a stale bundle to a new block or slot without re-simulating is a common way to eat unnecessary fees or land a now-unprofitable trade.

If you're running this kind of strategy against a market-making book rather than one-off arbitrage, the tip and bid logic needs to live next to your inventory and risk engine, not bolted on as an afterthought — that's the integration work we do as part of Solana market-making infrastructure, alongside the low-latency data and RPC plumbing both chains demand. A live trading dashboard also needs to surface these auction outcomes — win rate, effective tip cost, relay latency — which is exactly the kind of view we build into a trading dashboard rather than leaving it buried in logs.

Which to pick when

If you're building on Ethereum or any MEV-Boost-compatible L1/L2, you don't get a choice — PBS is the only path to reliable inclusion, so the real decision is which builders and relays to integrate with, and you should default to multi-builder submission from day one. If you're building on Solana, Jito bundles are effectively the only serious option today for atomic, tip-prioritized inclusion, and the interesting decisions are around leader-schedule prediction and tip-curve modeling rather than which relay to trust. Teams running strategies on both chains end up maintaining genuinely separate execution stacks — there's no shared abstraction that doesn't leak the underlying differences, and the same discipline shows up in adjacent systems like how the Hyperliquid HLP vault manages risk across very different execution constraints. Auction parameters on both sides shift as validator sets and builder market share change, which is why ongoing tuning matters as much as the initial build — that's the kind of work we handle under support and maintenance once a bot is live rather than treating deployment as a one-time task.

Need a searcher or market-making bot built around whichever of these two auction models your book actually trades — get in touch through our trading infrastructure services.