MEV — maximal extractable value — gets discussed like an exotic corner of blockchain research. For anyone actually trading, it's simpler than that: it's a tax. Every time your buy or sell becomes visible to the wrong party before it's finalized, someone can reorder the world around it and take a cut. One Solana operator extracted roughly $13 million in a single month sandwiching retail trades. On BNB Chain, sandwich bots have hit over 120,000 DEX traders in a single week. This is not an edge case. It's a standing toll booth on order flow.

For a token team running market operations, the tax compounds. You're not making one trade — you're making thousands, from wallets that attackers can watch, with strategies that attackers can model. Every basis point you leak per trade is treasury you don't have when it's time to defend a level.

This post covers the MEV that hits trades — buys and sells. Not liquidations, not LP-side games like JIT liquidity. We'll walk through the four ways a trade gets eaten, how the attack surface differs between Solana and EVM chains, and the defense playbook that actually works. We build Sumo, so read this as an operator's argument, not a neutral survey — but every claim about the attacks links to public sources, and every claim about our defenses is checkable in our execution behavior.

The four ways your trade gets eaten

The sandwich. The headline attack. A bot sees your pending buy, buys before you, lets your order push the price up, and sells immediately after — pocketing the difference. You get the worst fill your slippage tolerance allows. That last clause is the entire economics of the attack, and it's worth making the mental model explicit: your slippage setting is the attacker's budget. Set 10% slippage and you've posted a public bounty worth up to 10% of your trade to anyone fast enough to claim it.

The frontrun. The sandwich without the second slice. Snipers and copy-trade bots race your visible order to capture the move you're about to cause — common around launches, large buys, and any trade that signals information. You still fill, but the price you created was harvested before you got there.

The backrun. The invisible one. An arbitrage bot fills immediately after your trade, closing the price gap your order opened. Your fill isn't touched, so most traders never notice — but the value your trade created went to someone else. On Ethereum, entire systems exist to auction backrun rights and rebate the proceeds, which tells you how much money is in it.

The pattern attack. The one nobody writes about, and for market makers the most expensive. The first three attacks target a transaction. This one targets a strategy. If your bot sells a fixed 20% into every buy, an attacker can measure that, then feed you trades to farm your responses. If your DCA bot runs on a schedule, the schedule gets learned and traded against. A market-making tool that mechanically reacts to every trade in the pool — including trades made by MEV bots — isn't running market operations. It's running a faucet.

Chain by chain: where the attack lives

Ethereum is the classic hunting ground. Transactions sit in a public mempool, visible to everyone, before a block includes them. Sandwich and frontrun bots simply watch the pool and bid for position. The countermeasure is equally direct: don't use the public mempool. Private submission services like Flashbots Protect and MEV Blocker route transactions straight to block builders, invisible until included.

Solana has no public mempool, which produced a comfortable myth that it has no sandwich problem. What actually happened is the attack moved upstream. Sandwiching on Solana runs through infrastructure: validators running modified clients, and private mempool cartels that sell transaction visibility to attackers — Helius' MEV research attributes nearly half of all Solana sandwich attacks to a single such operation, the one behind that $13M month. The Solana Foundation has removed validator operators from its stake delegation program over it. The defense on Solana is Jito bundles: your transaction goes through a sealed auction and is only visible to the block producer after ordering is already decided, plus a marker enforced at the block-building layer (more on jitodontfront below) that forbids builders from placing anything in front of you.

BSC is the worst of both worlds: an Ethereum-style public mempool, historically fewer protections, and an active sandwich-bot economy — hence 120,000 victims. The ecosystem's answer is a network of private builders and relays — 48 Club, BlockRazor, and similar — that accept transactions directly, bypassing the mempool entirely.

The rest of the EVM world inherits one of these two models. Chains with open mempools inherit Ethereum's problem wholesale. Sequencer-based chains like Base don't expose a public mempool, which closes the classic attack — but it moves the trust question rather than answering it: whoever can see your transaction before inclusion can still act on it, and RPC operators, sequencer infrastructure, and copy bots watching confirmed flow all remain in the picture. The posture that works is the same everywhere.

Different chains, one lesson: transaction visibility is not a technical detail. It's the difference between trading and broadcasting your intentions to your counterparties in advance.

The defense playbook

Everything that works against trade-level MEV reduces to five principles. They apply whether you trade by hand or run a fleet of bots.

1. Never touch the public mempool. On Solana, that means Jito bundles — sealed until ordered. On EVM chains, it means private relays: your signed transaction goes directly to block builders and never appears in the public pool, so there is nothing for a sandwich bot to see. A transaction that was never visible can't be frontrun. This is the single highest-leverage defense on every chain, and on EVM chains it's essentially free — private relay endpoints cost nothing extra to use.

2. Make sandwiching structurally impossible, not just unlikely. Privacy has edge cases — some paths race a fast public route against a protected one, and infrastructure can leak. Solana offers a second, harder guarantee: a transaction carrying the jitodontfront marker account will not be placed behind another transaction in any Jito bundle. The builder refuses the ordering. That converts "probably not sandwiched" into "not sandwichable through the bundle path at all."

3. Enforce your worst price on-chain, not in your app. Slippage checks that live in your bot's code protect nothing — by the time your bot sees the fill, the money is gone. The minimum-out amount must be baked into the swap instruction itself so the chain reverts the trade rather than filling it badly. And the tolerance should be tight by default: every extra percent of slippage is budget you're offering to attackers.

4. Never leak a protected transaction while trying to land it. The subtle one. Landing rates on congested chains are a real problem, and the standard fix is rebroadcasting. But if your system submits through a protected path and then retries through public RPC, it just undid its own protection at the worst moment — while the transaction is pending and maximally attackable. Protection has to hold through the retry path, not just the first send.

5. Don't feed the bots, and don't be predictable. For anyone running automated strategies: detect MEV wallets and refuse to trade against them — reacting to a sandwich bot's trades is how reactive strategies get farmed. Randomize response sizes so your pattern can't be measured. And break the wallet graph: if attackers can trivially map which wallets belong to your operation, they can profile and target your flow before you ever hit send.

Run this list against any trade you made this week. If you can't say which principles were in effect, the answer is probably none of them.

How Sumo implements this

Sumo is a market-making and treasury platform for token teams, so we don't get to treat MEV protection as a feature checkbox — it has to hold across every path a transaction can take: strategies, instant trades, treasury operations, snipes, launches. Here's how the playbook maps to what actually ships.

Private-by-default submission on every chain. On Solana, trades route through Jito bundles across five block-engine regions with automatic failover, with bloXroute and Helius bundle paths as alternatives. On EVM chains — Ethereum, BSC, Base — private relays are the default execution strategy, not an opt-in toggle buried in settings. Your swap goes from Sumo's signer to a private relay to the block builder, and the public mempool never sees it. Where we bundle on EVM, we multiplex: Flashbots plus an 18-builder allowlist on Ethereum, and simultaneous submission to 48 Club, BlockRazor, and JetBldr on BSC, succeeding when any one accepts.

Honest labeling where speed trades against protection. Not every path can be both maximally fast and maximally private, and pretending otherwise is how users get hurt. Sumo's execution layer explicitly classifies each submission route — guaranteed MEV protection (Jito bundles), best-effort (dual-path racing where the fast route may be visible), or none (raw RPC with priority fees) — and the defaults pick protection unless you deliberately choose otherwise.

The jitodontfront guard. Sumo attaches the anti-sandwich marker to Solana transactions — unconditionally on treasury and wallet-hub flows, and automatically on trades taking any frontrunnable path. Builders that see it cannot place your transaction behind anyone else's.

Worst price enforced by the chain. Default slippage is 1% platform-wide, and the minimum-out threshold is computed from the live quote and baked into the swap instruction — the on-chain program reverts rather than filling you badly. If a caller supplies their own floor, it can only make the guard tighter, never looser. On EVM, every router call carries its minimum-out, plus a five-minute deadline on venues that support one — so a stale transaction dies instead of filling at whatever the price became.

Protection that survives the retry path. Sumo rebroadcasts in-flight transactions to improve landing rates — but the rebroadcaster refuses to re-send a Jito-routed transaction over public RPC; leaking one requires a deliberate, explicit override, never a silent fallback. A protected trade stays protected until it lands or dies. This rule sounds obvious. Check whether your current tool follows it.

MEV detection wired into the strategies themselves. Sumo's engine watches every pool it trades: when one wallet takes opposite sides in the same slot — the sandwich signature — that wallet is flagged and automatically blacklisted for the strategy. Counter Trade ships with MEV exclusion on by default, so it never counter-trades bot flow, and its capture percentage can be randomized so the response pattern can't be measured and gamed. Your Live Trading view tags trades as MEV Actor and MEV Victim, so you can see exactly who is attacking your pool instead of guessing.

Breaking the wallet graph. Sumo's privacy swaps route funds to trading wallets through third-party swap providers, with splits across destinations and time-delayed legs. This isn't mempool protection — it's the complement to it: attackers who can't map your wallets can't profile your operation and lie in wait for its flow.

Most trading tools fail this test

Here's the uncomfortable checklist. Ask any market-making, DCA, or trading tool vendor — including us — these six questions:

  1. Does it submit through bundles or private relays by default, or does it fire swaps at a public RPC and hope?
  2. On Solana, does it attach jitodontfront — or has the vendor never heard of it?
  3. Is minimum-out enforced on-chain from a live quote, or is "slippage protection" a number checked after the fact? What's the default — 1%, or 15% so the bot "always fills"?
  4. When a transaction is slow to land, does it retry through the same protected path — or leak it to public RPC at the most attackable moment?
  5. Does it detect MEV wallets and refuse to feed them, or does it react to every trade in the pool, bot or not?
  6. Can you see MEV activity against your token in its reporting, or is the tape a black box?

Most tools in this market fail four or more. The typical DCA bot is the perfect MEV victim by construction: wide slippage so fills never fail, a single public RPC because it's simple, a fixed schedule anyone can learn, and no visibility because who's asking. Every one of those design shortcuts is money moving from your treasury to a sandwich bot — silently, on every trade, forever.

Protection is an execution property, not a feature toggle

The through-line of this post is that MEV protection isn't one thing you turn on. It's a property that has to hold across the entire life of a transaction — how it's built, where it's sent, what happens when it's slow, and whether the strategy generating it can itself be gamed. A checkbox that says "anti-MEV" on a system that leaks transactions on retry and counter-trades sandwich bots is worse than nothing, because it buys false confidence with your treasury.

We built Sumo's execution layer around that property because our users' trades are exactly the flow MEV bots hunt: token teams, trading from known pools, at meaningful size. If you're running market operations on Solana or any EVM chain and you can't answer the six questions above about your current stack, that's what Sumo is for. And if you want to see what protected reactive trading looks like in practice, read how Counter Trade sells into buy waves without printing red candles — with the MEV filters this post just explained doing the quiet work underneath.