Sandwich Attacks on Solana vs Ethereum: Key Differences

Classic Ethereum sandwich bots work because the attack surface is obvious: a public mempool, predictable block times, and gas price auctions that let you reliably slot transactions before and after a target. Solana removes most of that infrastructure entirely, which means the techniques that made EVM MEV bots profitable do not transfer. Understanding exactly why requires getting into the mechanics of how each chain actually sequences and executes transactions.

The Mempool Gap

Ethereum's pending transaction pool is public by default. Before inclusion in a block, any transaction sits visible to the entire network — searchers, block builders, and validators alike. A sandwich bot monitors the mempool, detects a large AMM swap with meaningful price impact, constructs a frontrun and backrun, and submits both with gas bids high enough to bracket the victim. The timing window is generous: average block time is ~12 seconds, and even during congestion you typically have several seconds from mempool visibility to inclusion.

Solana has no equivalent public mempool. Transactions are forwarded by clients directly to the current leader via TPU (Transaction Processing Unit) connections, and that forwarding path is largely opaque to outside observers. There is no global pending transaction pool you can monitor. Some RPC providers expose limited "pending" feeds, but coverage is incomplete and latency is high enough to be operationally useless for sandwich construction. If you cannot see the victim transaction before it lands, there is no sandwich.

Slot Timing and the Execution Window

Solana produces a slot approximately every 400 milliseconds. That is 30x faster than Ethereum's 12-second block time. Even if you somehow observed a pending transaction, you would have under 400ms to detect it, construct two additional transactions, sign them, route them to the leader, and have all three land in the correct order within the same slot. In practice, transaction propagation alone across the Solana network typically takes 50-200ms depending on geography and network conditions. The math does not leave room for a reliable sandwich.

Ethereum's slower cadence is actually what enables the attack at scale. You have time to simulate the victim's state changes, calculate optimal sandwich sizes, run a priority fee auction via flashbots or private orderflow, and get your bundle submitted. The entire MEV-Boost / PBS infrastructure exists because the 12-second window made it economically worthwhile to build.

Parallel Execution and Account Locking

Solana's runtime executes non-conflicting transactions in parallel using Sealevel. For two transactions to be sequenced relative to each other — which sandwiching requires — they must touch the same accounts. When they do, Solana's scheduler serializes them, but the ordering within a slot is controlled by the validator's local scheduling logic, not by a fee auction accessible to external parties.

Ethereum's EVM is strictly sequential within a block. Transaction ordering is entirely a function of gas price (or priority fee with EIP-1559), which is exactly the lever MEV searchers pull. Solana's compute unit pricing exists but does not give you the same deterministic ordering guarantee across conflicting transactions that gas priority gives you on Ethereum. Validators can — and do — reorder based on fee, but the interface for submitting priority-ordered bundles is not standardized across the network the way Flashbots is on Ethereum.

Where MEV Actually Lives on Solana

This does not mean Solana is free of MEV — it means the MEV manifests differently. The dominant strategies are:

• Arbitrage between AMMs — price discrepancies between Raydium, Orca, and Jupiter routing paths close within the same slot or across slots. Pure arb requires no victim transaction.
• Liquidations — protocol liquidation auctions are competitive but do not require frontrunning a specific user.
• Jito bundles — Jito's modified validator client introduced an orderflow auction that lets searchers submit bundles with tips for priority ordering, creating a partial approximation of Ethereum's PBS model. This is the closest Solana gets to EVM-style MEV infrastructure.
• CLOB sniping — on central limit order book DEXes like Phoenix or OpenBook, latency to the leader matters more than mempool observation.

Jito bundles are worth understanding carefully: they restore some of the ordering guarantees that sandwich bots need, but only within Jito-enabled validators (which are a majority but not all validators). Even then, the 400ms slot window constrains what is practical compared to Ethereum's 12-second window.

Why EVM Sandwich Code Fails Directly

Engineers who port EVM sandwich bots to Solana without rearchitecting them run into several concrete failures. First, the mempool monitoring component has no valid data source to subscribe to. Second, the bundle submission logic assumes Flashbots-compatible endpoints that do not exist outside Jito's specific API. Third, transaction construction on Solana requires specifying all account keys upfront and managing compute unit limits explicitly — the dynamic gas estimation approach from EVM does not apply. Fourth, the fee-priority ordering that makes bracketing reliable on Ethereum is weaker and more validator-dependent on Solana.

Building MEV infrastructure for Solana means starting from the chain's actual execution model, not adapting EVM patterns. The profitable strategies are real, but they look like low-latency arb and liquidation systems co-located near validator infrastructure, not the gas-auction-based sandwich bots that dominate Ethereum MEV.

If you are building or evaluating automated trading strategies on Solana or other chains, the execution model differences are not edge cases — they determine which strategies are viable at all.

---

We build and operate production trading bots that account for these chain-specific mechanics. If you want to understand what is actually extractable on Solana, Hyperliquid, or Polymarket, reach out.