Flashbots MEV-Share vs Jito: OFA for EVM vs Solana

Backrunning a Uniswap swap on Ethereum and sniping a new pool on Solana feel like the same job until you look at how the transaction actually reaches a block. On Ethereum you're bidding into an order-flow auction that deliberately hides the victim's calldata from you. On Solana you're racing a bundle into a leader's slot with almost no privacy at all. Those two facts drive most of the economic differences between running searchers on the two chains, and they explain why a strategy that prints on one can be structurally unprofitable on the other.

This is a comparison of Flashbots MEV-Share and Jito — the two dominant order-flow paths — with a bias toward one question: what does each mean for the P&L of a backrunning bot?

The two auction models, briefly

MEV-Share is a programmable OFA run by Flashbots. A user (or a wallet, or an RPC aggregator) sends a transaction to the MEV-Share node instead of the public mempool. The node then broadcasts hints about that transaction — not the full calldata, but selectively revealed fields: the to address, function selector, logs, or a subset of them, depending on what the originator opted into. Searchers subscribe to the hint stream over SSE, construct a backrun, and submit a bundle. If it lands, the value gets split via a refund, and by default the user gets 90% of the backrun profit.

Jito is a bundle auction, not a hint auction. You send a bundle of up to 5 transactions plus a SOL tip to a Jito Block Engine region. The engine runs a sealed-bid auction every 200ms, orders bundles by tip, and forwards winners to the Jito-Solana validator client running on the current leader. There are no hints and no protocol-level refunds. You already have the transaction you want to backrun — usually because you pulled it from the public mempool-equivalent (shredstream, a Geyser plugin, or your own RPC firehose).

The one-line difference: MEV-Share sells you information about order flow; Jito sells you placement of a bundle you already assembled.

What the hint model does to backrun economics

MEV-Share's partial-hint design is the interesting part, and it's where most searchers lose money before they understand it. Because you don't see the full transaction, you're pricing a backrun against an incomplete picture. A hint might tell you a swap hit a specific pool and emitted a Swap event, but not the exact amountIn. You either simulate across a plausible range or you probe.

Concretely, a backrun bundle on MEV-Share looks like this:

bundle = [
  { hash: userTxHash },          // the hinted tx, referenced by hash only
  { tx: yourSignedBackrun }      // your arbitrage, built from the hint
]

You never hold the user's raw transaction. You reference it by hash and Flashbots stitches it in. That's elegant, but it means your backrun has to be robust to the exact fill you can't see. If your calldata assumes a state the user's swap didn't produce, the bundle reverts and you land nothing — you don't pay for reverts here, which is the saving grace.

The refund math changes how you bid. Since the user takes 90% by default, a naive searcher thinks their margin is 10% of the arb. It isn't quite: the refund is computed on the backrun's realized profit, and you can adjust your bid by how much priority fee and coinbase transfer you attach. The searchers who win consistently treat the refund percentage as a competitive lever, not a fixed tax. If you're modeling this seriously, it's the kind of thing worth pressure-testing in a strategy consultation before you commit capital, because the break-even backrun size on MEV-Share is meaningfully larger than on a public-mempool backrun.

What Jito's model does to backrun economics

Jito is blunter and, in some ways, easier to reason about. There's no refund, so 100% of the extracted value is yours minus the tip. Your entire strategy problem collapses to: what tip clears the auction for this slot?

That sounds simple until you meet the failure modes:

• Tip is your whole moat. Because bundles are ordered by tip and the auction reruns every 200ms, you're in a first-price sealed-bid war. Overbid and you eat your margin; underbid and someone lands ahead of you in the same slot.
• No revert protection by default inside a partially-landed world. A Jito bundle is atomic — all txs land or none do — but that atomicity is only within your bundle. Another searcher's bundle can land in an earlier slot and move the state you were targeting. Your bundle then simulates fine on the block engine and still misses the opportunity.
• Region latency is real. Jito runs Block Engine endpoints in Amsterdam, Frankfurt, NY, Tokyo, and SLC. Submitting to the wrong region relative to the current leader's location adds tens of milliseconds you cannot afford. Serious operators submit to multiple regions simultaneously and dedupe.

The tradeoff between routing through Jito versus other bundle relays is genuinely non-obvious, and I've written about the specific differences in bundle-landing behavior between bloXroute and Jito that matter once you're optimizing for inclusion rate rather than just tip. If you're building a sniper that depends on landing in the same slot as a pool-creation transaction, that inclusion-rate detail is the whole game — see how it plays into a Solana sniper bot build.

Latency, competition, and where the money actually is

Ethereum's 12-second slots give you a comfortable window to receive a hint, simulate, and submit. The bottleneck is information, not speed — everyone gets the hint at roughly the same time, so edge comes from better simulation and smarter refund bidding.

Solana's ~400ms slots invert that. The bottleneck is speed and placement, not information — the transaction you want to backrun is often visible to everyone via shredstream at nearly the same moment. Edge comes from geographic colocation, tip modeling, and how fast your bundle construction pipeline runs. This is why the retail-bot fee question (Trojan, Maestro, and friends) is really a latency question underneath — I broke down where those fees and latency tradeoffs actually land versus a custom build, and the short version is that shared infrastructure caps your inclusion rate no matter how good your strategy is.

There's also a subtler LP-side interaction. Backrunning DLMM and concentrated-liquidity pools on Solana behaves differently from constant-product because the active-bin mechanics change how much a swap moves price — worth understanding before you assume your Ethereum arb intuition transfers, which is part of why the Meteora DLMM versus Orca Whirlpools mechanics matter for LP and arb bots.

A rough decision heuristic

• You want passive, capital-efficient backruns with revert safety and don't mind sharing 90% → MEV-Share on Ethereum. Your risk is bounded (no pay-on-revert) and the hint stream is a clean signal source.
• You want to keep 100% of extracted value and can invest in colocation + tip modeling → Jito on Solana. Higher operational burden, thinner protection, but no refund haircut.
• You're market-making rather than backrunning → the auction model matters less than your inventory and quoting logic; a venue like a Hyperliquid market maker sidesteps both OFA designs entirely.

The gotcha nobody prices in

On both chains the biggest silent cost is bundles that land but don't profit. On MEV-Share it's a stale hint — you built against state that changed between hint and inclusion. On Jito it's a won auction on a slot where the opportunity already evaporated. In both cases you paid gas or tip for nothing, and these near-misses often outnumber your wins 5:1 during the tuning phase. That ratio, not the headline refund percentage, is what determines whether your bot is net positive over a month.

If you're wiring up either path for the first time, the failure modes above are exactly the ones that don't show up in a backtest and only surface in production, which is where a second set of eyes on the bundle-construction and simulation logic pays for itself — a code review and audit of the pipeline before you fund it.