Ethereum MEV vs Solana MEV: Architecture Differences That Matter

When engineers ask how to port an Ethereum MEV strategy to Solana — or the other direction — they almost always underestimate how deep the architectural differences run. Ethereum MEV vs Solana MEV is not just a tooling swap; it is a fundamentally different game with different latency profiles, different economic equilibria, and different failure modes. Getting this wrong means writing infrastructure that cannot compete, or worse, strategies that leak value every block.

The Mempool: Public Waiting Room vs. No Waiting Room

Ethereum's public mempool is the foundation of most MEV. Pending transactions sit visible in the p2p gossip layer; every searcher watches the same pending state and races to build bundles around it. This creates a well-understood competitive structure: you need a fast node, good simulation, and either direct builder relationships or submission via a relay like Flashbots MEV-Boost.

Solana has no public mempool in the same sense. Transactions are streamed directly to the current leader's validator via RPC or — critically — via Jito's Block Engine, which is the closest analogue to Ethereum's PBS relay. On Solana you cannot frontrun a pending transaction you saw in gossip, because by the time gossip propagates, the transaction has either landed or been dropped. MEV is almost entirely reactive: you respond to confirmed state changes or you submit a bundle alongside a target transaction through Jito's co-located bundle path.

Practical implication: Ethereum sandwich strategies require mempool visibility; they simply do not port to Solana as written. Solana MEV is predominantly backrunning and same-block arbitrage triggered by landing alongside a known transaction in a Jito bundle.

Proposer-Builder Separation vs. Jito's Auction

Ethereum's MEV-Boost separates the roles of block proposer (validator) and block builder (specialized entity that orders transactions for maximum value). Searchers submit bundles to builders, builders compete to construct the most valuable block, and validators select the best header. Tip goes up the stack: searcher → builder → proposer. The typical searcher concern is builder relationships and routing — Flashbots, BloXroute, beaverbuild — and the tip dynamics are set by competitive block-building auctions.

Jito brings a structurally similar auction to Solana but collapses it closer to the execution layer. The Jito Block Engine runs an auction where searchers submit bundles with attached SOL tips; the engine selects the highest-paying, non-conflicting bundle set and forwards it to the Jito-patched validator for in-order execution. There is no separate builder layer yet — searchers interact with the Block Engine directly. Bundles are atomic: all transactions land or none do, with no partial inclusion.

The tip math is different too. On Ethereum, tips are denominated in ETH and priced off expected MEV capture minus builder margin. On Solana, you pay a Jito tip (currently competitive at around 0.001–0.01 SOL per priority bundle) on top of per-compute-unit priority fees. Getting tip calibration wrong — either way — is one of the primary reasons Solana arb bots lose races. Our Solana MEV & Arbitrage Bot uses dynamic tip calibration backed by observed block auction data.

Account Model vs. Ethereum's World State

This is the most underappreciated difference for MEV strategy design. Ethereum transactions modify a global world state; conflicts are implicit. Solana transactions must declare every account they touch upfront, and the runtime enforces that no two transactions in the same slot modify the same writable account unless they are sequenced in a bundle.

This account-locking model has two major consequences:

• Conflict detection is cheap and explicit. The Block Engine can instantly reject bundle conflicts without simulation. On Ethereum, conflict detection requires full EVM re-simulation.
• Your bundle fails if any declared account is modified by a prior transaction in the slot. This is why Solana backrun strategies need tight account scoping — broad account declarations increase conflict probability and kill inclusion rates.

Ethereum state conflicts are implicit and discovered only at execution time, which is why failed Flashbots bundles still cost gas if they do not include a require revert guard. On Solana, a conflicting bundle is silently excluded with no SOL cost beyond the wasted latency.

Latency and Infrastructure Requirements

Ethereum block times are 12 seconds. That is a long auction window by on-chain standards; a competent Ethereum searcher can simulate hundreds of bundle variants, resubmit to multiple builders, and still land in the same block. The infrastructure bar is high but forgiving on time.

Solana slots are 400 milliseconds. The window between a swap confirming and an arb opportunity being claimed by a competing bot is measured in tens of milliseconds. Co-location with Jito infrastructure (Amsterdam, Frankfurt, or US-East depending on leader geography) makes a concrete difference — 20ms network latency is not recoverable when the auction closes in 200ms.

For Ethereum MEV, your critical path is: mempool event → simulation → bundle construction → builder submission. For Solana MEV, it is: on-chain event (confirmed or streamed via Geyser) → simulation → Jito bundle → Block Engine submission. The Geyser plugin interface — which streams account and transaction data directly from a validator — is the Solana equivalent of a private mempool subscription, and running your own validator with Geyser is the infrastructure equivalent of a private Ethereum node with direct mempool access. Read more about the supporting infrastructure in our Infra, Indexers & Data Pipelines service.

Strategy Economics: Where Each Chain Pays

On Ethereum, the richest MEV verticals have historically been:

• Sandwich attacks on large DEX swaps (requires mempool visibility)
• Liquidations on lending protocols (Aave, Compound, Morpho)
• JIT liquidity on Uniswap v3 concentrated pools
• CEX/DEX arbitrage via MEV-Boost bundles timed to price movements

On Solana, the dominant extractable value comes from:

• Atomic cross-DEX arbitrage across Raydium, Orca, Meteora — prices dislocate on every large swap
• Backrunning new pool creation (Pump.fun launches, Raydium pool adds)
• Liquidations on Kamino, MarginFi, Solend
• Priority-fee wars on high-demand mint events

Sandwich attacks on Solana are theoretically possible via Jito bundles (submit a buy, user swap, sell as three-transaction bundle) but they are economically marginal because pool slippage tolerances are tight and competing backrunners often eat the arb leg before you can complete the sandwich. In practice, backrunning and cross-DEX arb dominate real Solana MEV revenue.

Porting Knowledge Without Losing Capital

The mental model transfer that matters: think of Ethereum MEV as queue manipulation — you are reordering a public queue of pending transactions. Think of Solana MEV as state racing — you are the first to act on freshly confirmed state. The skills that transfer cleanly are simulation accuracy, tip/gas optimization discipline, and profit-revert guards. The skills that do not transfer are mempool filtering logic, gas price laddering, and bundle merging heuristics.

If you are building on Solana and come from an Ethereum MEV background, rewrite your mental model for the account declaration constraints before you write a line of bundle logic — it will save you weeks of debugging failed inclusions. Explore our full trading bot services to see where these strategies are already running in production.

---

If you are looking to deploy MEV infrastructure on Solana or EVM chains and want production-grade architecture from day one, reach out directly — we scope and ship searcher systems that compete.