Why is MEV a Cat and Mouse Game?

MEV is the most misunderstood concept in crypto. Some of it keeps markets efficient, some of it drains retail traders. MEV can't be removed from any blockchain with real financial activity. The part that matters is which kind dominates, who captures it, and whether the value flows back to users or gets extracted from them.

Arbitrage is the good kind of MEV. Bots spot price differences across DEXs, trade to close the gap, and keep prices consistent for everyone. Nobody's trade gets targeted, nobody gets a worse fill. The downside is arb bots spam aggressively, most attempts fail, and the failed ones still eat blockspace and network resources.

Sandwich attacks are where MEV turns predatory. And if you think it's just one bot placing two transactions around yours, that's the simplest version and it's increasingly rare. Wide sandwiches span across blocks. Multi-victim attacks catch dozens of traders in one squeeze. Evasive variants split trades across fresh wallets to dodge detection. The versions designed to be undetectable are the ones that dominate today.

MEV on Solana is a cat-and-mouse game. You patch one thing, they find another way in. That's been the pattern since 2024 and nothing suggests it's stopping.

When Anza announced Constellation in March 2026, a lot of people expected it to kill validator-level MEV. Research suggests it makes it significantly harder, but doesn't fully close the door. The ordering monopoly weakens, it doesn't disappear.

MEV attacks on Solana come in many forms, some helpful to the market, others straight-up predatory.

You have arbitrage bots fixing price gaps across DEXes, and on the other end you have sandwich attacks that deliberately make your trade worse so someone else can profit. In between sit liquidation hunting, token launch sniping, liquidity pool sniping, oracle exploits, and sneaky cross-slot or validator-level reordering tricks.

In this section we zoom in on the two types that dominate both the headlines and the on-chain data: arbitrage (the “good” side that actually improves the market) and sandwich attacks (the clearly bad side that hits retail users directly).

1. Arbitrage on Solana

Arbitrage is when a bot spots a price difference for the same token across two or more pools and trades to capture the spread.

SOL is quoted at $82 on Orca and $83 on Raydium, a bot buys on Orca, sells on Raydium, pockets the difference. Nobody gets targeted or trade gets manipulated. The bot is just cleaning up a pricing inefficiency that the market hasn't corrected yet.

In a recent 30-day window, Solana saw nearly 1.8 million successful arb trades, roughly 59,000 per day. Bots extracted about 41,000 SOL in revenue while spending only about 4,000 SOL in fees and tips. That's a 10x return on cost. And this only counts the arbs that landed, failed attempts, which are massive in volume, aren't included in these numbers.

Types of arbitrage

Cyclic arbitrage: The bot starts and ends with the same token (e.g., SOL → USDC → JLP → SOL). It hops through multiple pools, exploits price gaps along the way, and ends up with more SOL than it started with. Usually executed as a single atomic transaction or Jito bundle — if any leg fails, the whole trade reverts. Completely riskless.

Non-cyclic arbitrage: Same idea, but the bot ends up holding a different token (e.g., buy BONK cheap on one DEX and sell it for USDC on another). It still profits from the price gap, but now carries brief inventory risk because it holds a different asset.

DEX-DEX arbitrage: The bot spots a price difference for the same token across two on-chain venues. It buys on the cheaper one (e.g., Orca) and sells on the more expensive one (e.g., Raydium). Both legs are fully on-chain and visible. This is the most common and easiest-to-track form of arbitrage on Solana.

CEX-DEX arbitrage: The bot spots a price gap between a centralized exchange (like Binance) and a Solana DEX. It executes one leg on-chain and the other off-chain. Only the on-chain leg is visible on Solana (it just looks like a normal swap). Extremely hard to quantify and likely represents a massive but hidden portion of total arb activity.

Bundled arbitrage: The trade is split across two or more separate transactions that land in the same block. Slightly riskier because the legs are not atomic, one can succeed while the other fails. Harder to detect because you have to link multiple transactions from the same signer within a single block.

The Math Behind the Arb: How Bots Know When to Trade

Arbitrage bots don't guess. Before firing a single transaction, every bot solves the same core problem instantly: does this cycle make money, and if yes, how much should I trade?

Does the opportunity exist? For any circular path, say SOL → USDC → ORCA → SOL, the bot multiplies all exchange rates and fees around the full loop. If the combined product is profitable after fees, the arb is on. If not, skip it and move on. Fees matter a lot here because in a three-hop cycle you're compounding three fees on top of three exchange rates. A seemingly profitable set of rates can easily flip unprofitable once fees are included.

How much to trade? There's always a sweet spot. Too little leaves money on the table. Too much and you move the pool price against yourself, destroying your own profit. The optimal amount balances the size of the price gap against how deep the liquidity is across all pools. Bots compute this exactly, not by feel.

Is it worth executing? Expected profit minus fees minus any Jito tip has to be positive. If not, the transaction never fires. This decision happens in under a millisecond.

This is why cyclic arb is completely riskless. It's one atomic transaction, either all legs execute at the expected profit, or the whole thing reverts and you lose nothing but a tiny fee. The bot knows the outcome before it ever submits anything.

How bots land their arbs, Direct vs Jito

Solana doesn't have a public mempool. Transactions don't wait in a queue like on Ethereum. They get forwarded directly to the current slot leader via Gulf Stream. ~400ms slot times. The whole game is speed.

Two paths to get an arb into a block.

1. Direct submission

The bot sends a transaction straight to the validator's TPU over QUIC/UDP, bypassing Jito's auction entirely.

Top bots run staked RPC nodes with SWQoS for priority bandwidth during congestion. They colocate bare-metal servers in the same data centers as major validators, Frankfurt, New York, London. They use Yellowstone/Geyser gRPC for real-time account state instead of slower WebSocket polling. With the right setup, submission times drop below 50ms.

The bot only pays base priority fees, which keeps costs near zero. The downside is there's nothing protecting you if the arb fails, you still eat the transaction fee. But at 0.000005 SOL per transaction, bots can afford to spam aggressively and absorb the failures.

2. Jito submission

The bot packages its arb as a bundle (up to 5 transactions, executed atomically) and routes it through Jito's block engine with a tip attached.

Jito runs an off-chain auction roughly every 50ms. The highest-paying bundle wins and gets forwarded to the validator. If the arb fails, the bundle doesn't land and you pay nothing, full revert protection. Sequencing is also guaranteed, which matters for multi-step arbs across multiple DEXs. But the auction adds 50-200ms of overhead compared to direct, and bots typically give up 50-60% of expected profit as a tip to win inclusion.

Direct dominates.

Circular.fi data as of April 2026 shows direct accounts for ~80% of arb transactions and a similar share of revenue. Jito handles the remaining ~20%.

Most Solana arbs are single-transaction, thin-margin plays averaging ~$1.58 profit. Giving up 50-60% of that as a Jito tip makes most of them unprofitable. Direct lets bots keep nearly all the profit and absorb cheap failures at scale.

SWQoS also closed the reliability gap. Before it, direct submission was unreliable during congestion, transactions would just get dropped. Now staked nodes get guaranteed bandwidth proportional to their stake. Direct became dependable, and bots migrated.

Jito still matters for multi-step arbs needing guaranteed sequencing, for high-value opportunities where revert protection justifies the tip, and as a parallel backup. Top bots fire the same opportunity to both paths simultaneously, whoever lands first wins.

Arbitrage is the good form of MEV, bots scan DEXes, fix price gaps, and push prices back together. Tighter spreads, better price discovery, more efficient markets. The bot exploits a market inefficiency, not anyone's trade. Sandwich attacks are the opposite — direct extraction from retail users, not market fixing.

2. Sandwich attacks, the actually bad MEV

A sandwich attack is exactly what it sounds like. Your trade gets squeezed between two transactions placed by the same bot.

You submit a swap on a Solana DEX. A bot spots your pending transaction, front-runs you with a buy that pushes the price up, lets your swap execute at that inflated price, then immediately back-runs with a sell to pocket the difference. You get filled at the worst possible price your slippage settings would allow. The bot profits, you lose.

This isn't a bot finding a price gap between two venues. This is a bot seeing your specific trade, engineering a price movement against you, and extracting value directly from your execution.

Types of sandwich attacks

Sandwiches on Solana come in different structures, use different execution methods, and increasingly use evasion techniques to avoid detection.

By structure

Single (tight) sandwich‍

The classic version. Bot brackets one victim transaction. Front-run, victim swap, back-run, all consecutive in the same block, usually bundled atomically. If any leg fails, the whole thing reverts. In the last 30 days, Sandwiched.me tracked 67,048 single sandwiches extracting 7,657 SOL from 42,998 victims. Cost to the attackers was 314 SOL. That's a 24x return.

Wide (blind/optimistic) sandwich

‍This is where most people's understanding of sandwich attacks falls short. Wide sandwiches don't need the front-run and back-run right next to the victim's transaction. They're sent 50-300ms apart, landing in roughly the right order but with other transactions between them, sometimes spanning across different blocks entirely. Because they're not bundled atomically and don't follow the neat front-run → victim → back-run pattern, they're significantly harder to detect on-chain. That's by design.

Wide sandwiches dwarf single ones in every way. Roughly 15x more frequent, 10x more value extracted, and hitting nearly 8x more victims. Ghost's year-long analysis found 93% of all sandwich attacks on Solana are now wide. The version that's hardest to detect is the one doing the most damage.

Multi-victim sandwich

‍A variant of wide sandwiching where the bot catches multiple victims between a single front-run and back-run. One set of costs, extraction from every victim in between. The Sandwiched.me stream regularly shows attacks with 5-10+ victims squeezed in a single sandwich. Each successive victim's swap executes at a progressively worse price because the front-run plus every preceding victim's trade has already moved the price further.

By execution method

Jito bundle sandwich

‍The bot creates a Jito bundle containing their buy, the victim's transaction, and their sell, all executed atomically. This was the primary method before Jito shut down their public mempool in March 2024. When the mempool was live, transactions would sit there for roughly 200ms, giving bots plenty of time to identify targets and construct sandwich bundles. After the shutdown, sandwich activity dropped off a cliff. Then came back within a month as attackers adapted.

Validator-run sandwich

‍The validator itself reorders transactions during the banking stage using a modified client. The vanilla Solana validator is open-source, so anyone can fork the code and modify how transactions are ordered when they're the leader. No external bot needed. The validator is the attacker. This is what bloXroute's research calls the "new frontier" of Solana MEV, where the threat has moved from the mempool to the validator set itself.

Private mempool sandwich

‍A validator or entity operates a private mempool where they see pending transactions before they're committed to a block. DeezNode is the most documented case. Multiple validator operators reported receiving proposals from DeezNode offering profit shares for participating in their private mempool. Jito's internal analysis found that nearly half of all sandwich attacks on Solana could be attributed to a single program (vpeNAL) connected to DeezNode's mempool. Over one 30-day window, that program executed 1.55 million sandwich transactions for a profit of 65,880 SOL.

Cross-slot sandwich

‍The front-run lands at the end of one leader slot and the back-run lands at the beginning of the next. Only possible when the attacker controls consecutive leader slots. This exploits validator-level privileges that relay protections can't touch. Cross-slot sandwiches have surged from a rare edge case to one of the most common attack patterns, aligning with Ghost's finding that 93% of current sandwiches are now wide.

By evasion technique

As detection tools got smarter, sandwich bots evolved to hide in plain sight.

Evasive/obfuscated sandwich

‍Instead of one clean front-run and one clean back-run, the bot breaks things up. The front-run gets split into multiple smaller buys. Tokens get transferred to a fresh wallet before the back-run. The back-run itself might be split across multiple sells. To anyone scanning the chain, each individual transaction looks like normal trading activity. The sandwich pattern only becomes visible when you piece them all together, which is exactly what most detection tools fail to do. Sandwiched.me built a v2 detector to catch these. It flagged 82 validators running sandwich strategies, 27 of which were completely invisible to the original detector. 64% of sandwiching stake had shifted to evasive techniques. When the v2 results went public, several flagged validators shut down or raised their commission to 100%, basically confirming they were caught.

Authority-hop sandwich

‍This one goes a step further in hiding the attacker's identity. The bot temporarily transfers token account ownership to a different wallet mid-attack. The front-run comes from address A, the tokens move to address B, and the back-run executes from address B. On-chain, there's no obvious link between the two sides of the attack. You'd have to trace the token ownership transfer to connect them, which most explorers and detection tools don't do automatically.

The pattern across all of these is the same. Every time detection improves, attackers adapt. Every time a new protection ships, bots find the gap around it.

The cat-and-mouse game

Every protection mechanism introduced on Solana has been met with adaptation.

March 2024, Jito shuts down their public mempool. Sandwich activity drops off a cliff. Within a month, it's back. Bots found alternative ways to see pending transactions through private mempools and validator-level access.

Jito introduces jitodontfront, a sentinel account users can include in transactions to prevent front-running in bundles. Wide sandwiches increase 30x in response. Bots just stopped using tight bundles and switched to optimistic, non-consecutive attacks instead.

Dozens of validators adapt, splitting front-runs into multiple smaller buys, transferring tokens to different wallets mid-attack, running multiple back-runs from separate addresses. All designed to look like normal trading activity to detection algorithms.

The pattern is consistent. Detection improves, attackers adapt, new tools catch the adapted behavior, attackers evolve again. The cycle continues because the profitability justifies the effort.

Does Constellation solve MEV?

Umberto published a detailed research series analyzing whether Constellation, Anza's upcoming protocol upgrade for Solana, actually eliminates front-running and sandwich attacks.

Right now, the leader sees your transaction directly and has total control over ordering. They can peek at what you're swapping, insert their own front-run, and include both in the same block. One entity, full visibility, zero friction. This is why validator-run sandwiches and private mempool attacks work so well today.

Constellation adds layers between you and the leader. Your transaction goes to proposers first, who break it into cryptographic pieces and distribute them to attesters across the network. Attesters sign off on what they've seen and forward the pieces to the leader. The leader can only include your transaction once it gets enough attestations, at least 64 out of 256 attesters.

By the time the leader reconstructs what you're trading, the information has already traveled through a distributed set of participants. The leader's private window of visibility shrinks dramatically.

What Constellation actually solves

Same-cycle front-running becomes nearly impossible under normal conditions. The simulations show that if the leader reconstructs your transaction after the first ~20ms of the cycle, there's simply not enough time left for a front-run to travel through proposers, reach enough attesters, and come back before the cycle closes. Under realistic network latencies with geographically distributed validators, this timing almost never works out.

This is specifically about validator-level MEV, the kind where the block producer uses their position to reorder or insert transactions. Constellation directly addresses this because it changes how the leader receives and processes transactions.

It does not address searcher-level MEV. Arb bots trading against price gaps across DEXs, backrun bots capturing post-trade dislocations, JIT liquidity plays, none of that changes under Constellation. Those strategies don't depend on the leader's ordering power. They depend on reading on-chain state and submitting transactions fast. Constellation has nothing to say about that.

What Constellation doesn't solve

Cross-cycle front-running remains a real surface. Some transactions arrive to the leader after the current cycle has closed. The leader now knows what you're trading and can position a front-run in the next cycle. This is essentially the same vulnerability that powers wide sandwiches today, and those already account for 93% of all sandwich attacks on Solana.

The leader can also still attempt same-cycle front-running by sending their transaction to all active proposers simultaneously, hoping at least one reaches enough attesters in time. Most proposers can't pull it off under normal latency conditions. But a few with favorable network positions sometimes can.

The difference is cost. Today, front-running is free and private. Under Constellation, the leader has to pay inclusion fees to multiple proposers, the attempt is visible to more network participants, and the MEV revenue gets distributed rather than captured entirely by the leader.

And to sum it up Constellation weakens the leader's monopoly over transaction ordering. It doesn't eliminate MEV.

Constellation's primary goal is censorship resistance, making sure no single leader can exclude your transaction. On that front, it delivers. On MEV, it changes the structure of extraction rather than removing it.

‍