MEV: How a Searcher Captures MEV (Part 2)

Last week, in Part 1 of this series, we broke down the fundamentals of MEV on Solana, what it is, why it exists, and the key actors in the MEV supply chain. If you haven't read that yet, start there.

In this piece, we're going deeper into one of the actors from the MEV supply chain; the searcher.

Who Are Searchers?

Searchers are traders who monitor onchain activity and attempt to place their trades strategically before or after other transactions to extract value. They are the ones scanning every block, every liquidity pool, every oracle update for profitable opportunities arising from transaction ordering.

Validators can also act as searchers because they already control what goes into their blocks. So when it's their turn to produce a block, they can spot profitable opportunities from incoming transactions and insert their own transactions to exploit them. We will talk more about how validators extract value in our next blog.

How Do Searchers Find Opportunities?

A searcher's bot runs a continuous loop: read the latest chain state, find whether any profitable opportunity exists, and if so, execute before anyone else does. The entire cycle needs to be completed in milliseconds.

There are two types of opportunities based on their information source:

Onchain state opportunities: arbitrage and liquidations, where the data is already confirmed onchain and the competition is purely about speed.

Pending transaction opportunities: front-running and sandwiching, where the edge comes from seeing a user's transaction before it's committed to a block.

Onchain State Opportunities

The most extracted type of MEV is Arbitrage: When the same asset trades at different prices across two or more venues, a searcher buys where it's cheap and sells where it's expensive. As most of the people know, it’s called arbitrage: you spot price gaps across different venues and profit on these inefficiencies. At the same time, you’re helping the markets: to make sure prices on all exchanges are identical. On Solana, several types exist of arbitrage:

AMM vs AMM: the same pair priced differently on two different AMMs because their pool balances are diverged

AMM vs Order Book: an AMM still quotes a stale price while market makers on an order book have already updated to reflect a new price

CEX vs DEX: a price moves on a centralized exchange but hasn't been reflected on any on-chain venue yet. This happens because DEXs don't adjust prices automatically like CEXs do, they only update when someone actually makes a swap, and even that is limited by block times. That delay is the opportunity.

Multi-hop / Cyclic: no direct two-pool gap exists, but a path through multiple tokens (e.g. USDC → ORCA → SOL → USDC) creates a profitable cycle

Cross-chain: the same asset priced differently on Solana vs another chain, though this can't be executed atomically

In practice, the bot is constantly doing three things:

Monitoring pool reserves across every relevant DEX: Raydium, Orca, Meteora, Phoenix, OpenBook, watching for any mismatch in prices for the same trading pair.

Computing whether the gap is actually profitable. A price difference alone isn't enough, the searcher needs to account for trading fees on both pools, price impact from their own trade size, and the tip they'll need to pay to win the bundle auction.

Calculating the optimal trade size. This is where most people's intuition breaks. Trading too little means the profit doesn't cover the tip. But trading too much is just as bad, the larger your trade, the more you move the pool's price against yourself, shrinking your own returns. The profit curve rises to a peak and then falls back down. The bot needs to find that peak, the exact input amount that maximizes profit.

Arbitrage volume spikes during high-volatility events, sudden trading volume and liquidity shifts create more price gaps across venues.

The next type of onchain state profit opportunities are liquidations. When collateral value drops below a protocol's minimum ratio, the position becomes liquidatable, anyone can repay the debt and claim the collateral at a discount.

Searchers monitor two things:

Oracle price feeds: a Pyth update can instantly make healthy positions undercollateralized

Lending protocol account state: actual collateral ratios of open positions

The trigger is the oracle update. The searcher fires [oracle_tx, liq_tx] as a single atomic bundle; if the oracle lands separately, every other searcher races you to it. Atomicity removes that race.

Pending Transaction Opportunities

Everything above reacts to the confirmed state, data that's already onchain. Front-running and sandwiching work fundamentally differently, they require seeing a user's transaction before it's committed to a block. Without that visibility, they can't happen.

On Solana, there's no public mempool, so searchers need to build that visibility themselves:

Private mempool access: either by running one or being invited into one

Validator-level visibility: being a validator yourself means you see everything arriving at your node during your leader slot

Relationships with validators willing to share their incoming transaction flow

Modified validator clients that enable transaction reordering

When Jito shut down its public mempool in March 2024, sandwich activity dropped overnight. It came back within a month. Here's how.

The first adaptation: private mempools. Operators like DeezNode built their own transaction visibility infrastructure, offering validators profit-sharing deals to forward incoming transaction flow. Multiple validator operators publicly reported receiving detailed proposals with projected earnings.

The second adaptation: a shift in technique.

Jito introduced jitodontfront (special address), letting users flag their transaction so it can't be frontrun inside a bundle. This broke tight sandwiches, where all three transactions (frontrun, victim, backrun) are bundled together and executed consecutively.

Sandwich searchers responded with wide sandwich attacks, also called "blind" or "optimistic" sandwiches:

Tight: all 3 transactions bundled together, consecutive, atomic. Blocked by jitodontfront.

Wide: frontrun sent separately, backrun sent 50–300ms later. No bundle involved, so jitodontfront can't do anything about it.

The numbers from the sandwiched.me 2025 report:

- Wide sandwiches increased nearly 30x after jitodontfront was introduced, from roughly 1% to over 30% of all sandwich attacks

- $370M–$500M extracted by sandwich bots over a 16-month period

- Every mitigation created a new adaptation

How Searchers Evolved on Solana

Phase 1: Brute Force (2021–2022)

Searchers didn't start sophisticated, they started with spam. The first real MEV came from NFT mints, where one block had zero profit opportunity and the next had enormous profit opportunity the moment a mint went live. With no coordination mechanism, the only viable strategy was flooding the network with transactions and hoping one landed.

Bots competed purely on volume, causing repeated congestion halts. This wasn't irrational, with low transaction costs and a large enough prize, spamming is mathematically positive expected value even with a low success rate.

Phase 2: Priority Fees & Jito (Mid-2022 – 2023)

Mid-2022 introduced priority fees, shifting competition slightly toward fee bidding over pure spam. It helped at the margins but didn't change the fundamental game, spam remained positive EV.

The real inflection point was Jito in August 2022. For the first time, searchers had access to proper off-chain auctions through bundles, atomically executed transaction sets where winning guaranteed execution and losing cost nothing. This mirrors exactly what Flashbots did for Ethereum, where pre-Flashbots searchers ran chaotic priority gas auctions in the public mempool, wasting enormous gas on tit-for-tat bidding wars. Bundles replaced that with sealed-bid competition, you bid your true value, spam disappeared, barriers to entry fell.

Adoption stayed under 10% through most of 2023 simply because network activity wasn't generating enough MEV to matter.

Phase 3: Memecoin Season Changes Everything (Late 2023 – Early 2024)

Late 2023 and early 2024 unlocked a completely new MEV target. Memecoin traders set extremely high slippage tolerances to prioritize fast execution, creating near-perfect sandwich conditions, searchers could front-run, let victims execute at maximum slippage, and immediately back-run the difference. Jito adoption exploded from 10% to 50% of validator stake by January 2024, hitting 92% by 2025. The opportunity had finally caught up to the infrastructure.

The January 2024 WIF trade illustrated the scale: one trader bought $8.9 million of DogWifHat in a single transaction, overwhelming all available liquidity. A searcher back-ran the resulting price discrepancy with an 890 SOL tip ($91K), netting 17,442 SOL ($1.79M) in profit from a single bundle.

Phase 4: The Mempool Removal Backfires (March 2024)

Sandwich attacks became severe enough that Jito shut down its public mempool in March 2024, sacrificing significant revenue. The immediate effect was real, sandwiching dropped noticeably. But private alternative mempools emerged almost immediately, offering the same functionality to select participants only.

This mirrors a pattern Ethereum already proved. PBS solved pre-Flashbots chaos but recreated concentration one layer down, as we covered in our PBS article, three builders now control roughly 88% of Ethereum blocks and 57% of transactions flow through private channels. Solana's mempool removal was creating a similar dynamic: searchers with private access compounded their advantage while everyone else competed with less information.

How Searcher Execution Actually Works

Searchers continuously monitor onchain state, looking for conditions that make a trade profitable. When they find one, the execution pipeline has three layers.

Bundles

Most competitive strategies are executed as bundles rather than single transactions. A bundle is a group of up to five transactions that execute sequentially and atomically, either all of them land together, or none of them do. This matters because a frontrun without a guaranteed backrun is just an open position with no exit. Atomicity removes that risk entirely.

Bundles also carry a tip. This is how searchers bid for block space, higher tip means higher priority in the auction.

Block Engines

Block engines sit between searchers and validators. They receive bundles, simulate them to verify validity, run a priority auction based on tip per compute unit, and forward the winning combination to the validator.

How the auction works:

Searcher submits a bundle with a tip

The engine simulates it, verifying all transactions will succeed

Bundles targeting the same state (same read/write locks) compete against each other

Winners are ranked by tip efficiency

Winning bundles are forwarded to the validator

Auctions run on short ticks, around 50ms, meaning searchers compete across multiple cycles per slot. Submitting early in a tick with a competitive tip is the basic execution discipline every searcher develops.

Submitting to Validators

For a bundle to execute as intended, the validator producing the block needs to be running compatible software. A bundle submitted to a standard validator won't be treated as a bundle at all, it loses atomicity, revert protection, and tip routing. This is why validator client adoption matters structurally. The more of the network running bundle-aware software, the more reliably searcher strategies execute as designed.

Who Builds the Infra

Several projects have built the infrastructure searchers depend on, each approaching the problem from a different angle.

Jito: the dominant MEV infrastructure on Solana. Modified validator client, block engine for bundle auctions, and ShredStream for low-latency data. Still the core pipeline most searchers use today.

Harmonic: an open aggregation layer that pulls candidate blocks from multiple builders (including Jito, JitoBAM, Paladin, etc.). Validators pick the best one based on their own preferences. Finally introduces real builder competition to Solana.

Paladin: a fork of the Jito-Solana client with a priority express lane (P3) that sends high-priority transactions straight to the leader, bypassing relays and intermediaries. Rejects sandwich bundles by default.

All of this infrastructure is built around one assumption: that the searcher can act fast enough to make it matter. The strategies and execution pipeline exist. What separates winners from losers at this point is almost entirely a question of speed.

Why Speed Defines Solana MEV

On Ethereum, searchers have seconds to react. Blocks are produced every 12 seconds, and the mempool gives substantial lead time. On Solana, slots are 400ms and auctions tick every 50ms. The competitive window isn't measured in seconds; it's measured in the time it takes a signal to travel through fiber.

This changes the nature of the game entirely. On Ethereum, strategy and simulation quality are the primary edges. On Solana, infrastructure quality is equally important. A searcher with a better algorithm but slower data feeds will consistently lose to a searcher with average algorithms and faster state visibility. Speed isn't an advantage; it's the baseline requirement for competing at all.

Why standard RPC not optimal for searchers

Searchers need to know the instant onchain state changes, a price moves on Raydium, a collateral ratio drops below liquidation threshold, a large swap hits a pool. The default way to get this data is polling an RPC node: you ask "what's the current state?", get a response, ask again. For normal apps this works fine. For MEV it's fatal. By the time you find out about a state change — at best 400ms later — someone else has already captured the opportunity.

Geyser and Yellowstone: streaming instead of polling

Geyser is a plugin that runs inside Solana's validator software. Every time an account changes or a transaction confirms, Geyser fires that event instantly, before the data is even available through normal RPC. But Geyser runs inside the validator, so you need a way to receive those events on your own server. That's what Yellowstone does. Built by Triton One and now open source, Yellowstone takes Geyser's internal events and streams them to you over gRPC.

For a searcher, that means the moment a pool's reserves shift or an oracle pushes a new price, their bot already knows, and is computing whether there's a profitable trade before most of the network has even seen the update.

ShredStream: seeing data before blocks are finished

Geyser tells you what changed after a transaction is processed. ShredStream goes a step earlier, before the block is even complete.

Solana doesn't build a full block and then broadcast it. The leader continuously streams block data out in real-time fragments called shreds as it constructs the block. These shreds propagate through Turbine, Solana's data distribution layer, which uses a stake-weighted tree. Validators with more stake sit higher in the tree and receive shreds earlier. Everyone else waits downstream.

This creates a structural disadvantage for anyone who isn't a large validator. By the time shreds reach a searcher's server through normal Turbine propagation, the highest-staked validators on the network have already seen that data , potentially already reacted to it.

ShredStream bypasses that tree entirely. Instead of waiting for shreds to trickle down through Turbine based on stake position, it delivers shreds directly to your server regardless of stake weight. The practical result is that searchers can observe incoming transactions before the block is fully assembled, before most of the network has even seen the data.

This matters most in tight races. If two searchers spot the same arbitrage, the one who sees the relevant transactions arrive in the current block first can compute and submit before the other has even received the signal. At 50ms auction ticks a 20–40ms shred delivery advantage is often the entire margin between winning and arriving second.

Jito ShredStream

Jito operates ShredStream with regional endpoints across multiple locations. Searchers run a lightweight proxy that authenticates with the block engine and forwards shreds directly to their local trading server.

Co-location

Even with the fastest data feeds, physics still applies. A round trip from Singapore to New York takes ~170ms, nearly half a Solana slot in travel time alone. Searchers place servers in the same data centers as major validators, often in central Europe where a large share of high-staked validators are hosted. At these speeds, being in the same building matters.

What's Next?

Searchers operate within an infrastructure they don't fully control. The block engines, the validator clients, the transaction flows, all of it ultimately runs through validators and the RPC layer underneath. Searchers compete for the opportunities. Validators and RPCs decide who gets to see them in the first place.

In Part 3, we go up the stack, into how validators and RPC providers extract MEV of their own, the infrastructure they run to do it, and why the most extractive behavior on Solana isn't coming from searchers at all.

‍