Jito vs Flashbots: MEV Auctions on Solana vs Ethereum

Bundle auctions on Solana and Ethereum solve the same problem: get a batch of transactions included atomically, pay for priority without living at the mercy of a public mempool. But the mechanics diverge enough that a strategy tuned for one chain will misfire on the other if you just swap the RPC endpoint. I've ported sandwich and backrun logic between both stacks enough times to know exactly where the assumptions break.

The core mechanical difference

Flashbots runs on top of Ethereum's proposer-builder separation (PBS). Searchers submit bundles to builders (Flashbots' own builder plus competitors like beaverbuild, Titan, and rsync), builders compete to assemble the most valuable block, and MEV-Boost relays hand the winning block header to whichever validator is proposing that slot. The validator signs blind: it never sees the transaction contents, just commits to a header it's told is the best available. Twelve-second slots give builders real time to simulate, reorder, and rebuild before the deadline.

Jito doesn't sit on top of a separation layer like that. It's baked directly into a modified validator client, Jito-Solana, which roughly 90%+ of stake now runs. Searchers send bundles (up to 5 transactions, atomic, all-or-nothing) to Jito's Block Engine, which runs its own off-chain auction and forwards the winning bundle to whichever validator is leader for that slot. There's no builder market in the Ethereum sense. Jito Labs operates the primary Block Engine, and while the code is open source and some large validators run their own instance, it's still a far more centralized auction layer than Ethereum's multi-builder, multi-relay setup.

The practical consequence: on Ethereum you're bidding into a competitive builder market with real block-building competition and several relays to fall back on. On Solana you're mostly bidding into one company's auction, even though the validators executing the result are decentralized.

Timing changes everything

Solana's ~400ms slot time versus Ethereum's 12 seconds isn't just a latency stat, it reshapes how you build. The leader schedule is published a full epoch ahead of time (roughly two days), so a serious searcher pre-computes which validator leads which slot and routes bundles to Block Engine regions (NY, Amsterdam, Tokyo, Frankfurt, Salt Lake City) close to that path. The Yellowstone gRPC vs plain RPC/WebSocket latency question stops being an optimization and becomes table stakes here, because a 40ms round-trip advantage can be the entire difference between landing a bundle and missing the slot entirely.

Ethereum's slower cadence is more forgiving. You have time to simulate against exact head state, get rejected by one builder, and still resubmit before the next block. That slack is why Ethereum MEV infra can afford coordination layers like MEV-Share; there's room in the timeline for it. Bolt the same coordination overhead onto a Solana searcher loop and you'll blow through the slot before your bundle even reaches the Block Engine.

Tips, fees, and what actually gets paid

Ethereum bundles pay builders either through the transaction's priority fee (post EIP-1559) or a direct coinbase.transfer() inside the bundle, conditioned on inclusion. Fail to land, and you pay nothing beyond simulation cost. Flashbots' model only charges you gas if a transaction reverts after making it into the block.

Jito tips run on a completely separate rail from Solana's per-compute-unit priority fee. You append a system transfer to one of 8 designated tip payment accounts, and that transfer amount is what the Block Engine actually auctions on, not your compute unit price, which is its own, much smaller fee market for base transaction priority. Mixing these two up is the single most common mistake I see in ported bots: cranking setComputeUnitPrice() aggressively while leaving the Jito tip near zero loses every auction, and overpaying tips on a bundle that would've landed unassisted (because the leader wasn't even Jito-connected that slot) just burns money.

// Solana / Jito bundle skeleton — tip instruction is separate from priority fee
let tip_ix = system_instruction::transfer(
    &searcher_pubkey,
    &jito_tip_accounts[rand::random::<usize>() % 8],
    tip_lamports, // this is what wins the Block Engine auction
);

let cu_price_ix = ComputeBudgetInstruction::set_compute_unit_price(cu_price);
// cu_price is a separate, much smaller fee market — don't confuse the two

Inclusion guarantees (there mostly aren't any)

Neither system guarantees inclusion, but the failure modes differ. On Ethereum, a bundle can simply lose the builder auction and never appear anywhere: no cost, but also no real-time feedback beyond a timeout. On Solana, if the current leader isn't running Jito-Solana at all (a shrinking but nonzero share of slots), your bundle has nowhere to go regardless of tip size, so resilient searchers submit through the Jito path and a plain priority-fee transaction as a fallback in the same slot window.

This is where client diversity stops being a decentralization talking point and starts mattering for strategy design. Firedancer's arrival as a second major validator client means the Jito/non-Jito leader split, and possibly the bundle mechanism itself, is going to keep shifting over the next several upgrade cycles. Build your leader-detection logic to be swappable, not hardcoded to today's validator mix.

Side by side

Dimension	Flashbots (Ethereum)	Jito (Solana)
Auction layer	Builder market via PBS + MEV-Boost relays	Jito Block Engine (largely single operator)
Slot time	~12s	~400ms
Bundle size	Arbitrary, practical limits from builders	Max 5 transactions
Tip mechanism	Priority fee or coinbase.transfer()	Dedicated transfer to 1 of 8 tip accounts
Fallback if auction fails	Resubmit to next builder/block	Leader may not run Jito at all
Validator visibility into content	Blind signing (PBS)	Full visibility, leader executes directly
Latency sensitivity	Moderate	Extreme, sub-slot matters

Which to pick when

If you're building or auditing arbitrage and liquidation bots on Ethereum L1, Flashbots' tooling (MEV-Share, bundle simulation RPC, several competing builders) gives you more resilience and more places to retry. Lean into that redundancy rather than fighting it. If you're on Solana, the game is almost entirely about latency and leader prediction; a bot with a mediocre strategy but excellent Block Engine routing beats a smarter bot with lazy infrastructure, which is close to the opposite of how it plays out on Ethereum.

Don't try to reuse one codebase across both chains. The auction models, tip accounting, and failure semantics differ enough that porting logic 1:1 produces bots that silently overpay on one side and silently lose every auction on the other. If your program handles funds directly through these tip or bundle flows, get the logic checked independently, particularly if it's written in native Rust rather than Anchor, where the review surface for tip-account handling and bundle atomicity assumptions changes quite a bit, as we cover in our Anchor vs native Rust audit comparison. A proper smart contract audit catches exactly the edge cases that don't show up until real MEV competition finds them. And if you're deciding where to point your team's MEV effort given your latency budget and risk appetite, that tradeoff is worth working through in a strategy consultation before you write a line of bundle code.

Need a bot that actually lands Jito bundles instead of just building them? Our Solana sniper bot service is built around exactly this auction and leader-routing logic.