Sandwiched on Solana: protecting swaps from MEV

A sandwich attack is simple. A bot sees your swap before it lands, buys the token just ahead of you so your trade fills at a worse price, then sells straight after. You receive less; the bot keeps the difference. The only limit is the slippage you allowed.

The problem on Solana

Solana does not have a public mempool like Ethereum's, which led many to assume sandwiching was an Ethereum problem. It is not.

• Private order flow replaced the public mempool. Jito switched off its public mempool in March 2024 after a wave of sandwiching, but attacks moved to private channels. A talk on the state of Solana MEV at Accelerate 2025 described that shift: extraction became less visible, not less common. Public estimates of what sandwich bots have taken from Solana traders run into the hundreds of millions of dollars.
• Attacks spread across slots. In wide sandwiches, the front-run and back-run land in different slots, which makes them harder to detect and attribute.
• Users carry the defence. Most apps leave protection to a slippage setting. Memecoin and launchpad traders routinely set high slippage to make sure trades fill, which is exactly what a bot needs.

The proposal: protect in the protocol and the app

1. 01Oracle-bounded minimum output. Programs can compare the expected output against an oracle or TWAP price and reject fills that deviate beyond a bound, regardless of what slippage the user typed.
2. 02Smart default slippage. Compute slippage per trade from pool depth and volatility, rather than a fixed 1 percent or a user's habit of 20 percent. Show the expected and worst-case output in money, not percentages.
3. 03Bundle or route privately. Submitting a swap as part of a bundle prevents a third party from inserting a transaction before it within that bundle. Route through providers with credible anti-sandwich policies, and measure.
4. 04RFQ and batch execution for size. Large orders filled by quotes from market makers, or batched and cleared at one price, leave nothing to sandwich.
5. 05Measure your users' losses. Index your own swaps, detect sandwiches around them and publish the number. What gets measured gets fixed, and it builds trust.

What changes with faster finality

Alpenglow, Solana's new consensus protocol, replaces TowerBFT; Solana's upgrade page lists its first phase activating on mainnet in October 2026, with finality targeted at around 150 milliseconds. Faster finality shortens how long a transaction is exposed, but block producers still order transactions within a slot. The Foundation's roadmap also points to encrypted transaction submission, which would remove the information bots rely on. Until then, the defences above are in builders' hands.

What to measure

• Sandwich rate. The share of your users' swaps that were sandwiched, by pair and by size.
• Value extracted. Total and per-trade loss to sandwiches, the number that makes the case internally.
• Realised versus expected output. The gap between the quote shown and what users received, before and after the changes.
• Failure rate. Swaps that revert because protection was too tight; protection that blocks trades is not protection.

How we would start

Add a sandwich detector to your indexer and look at a week of your own users' swaps; the number usually makes the case. Then move protection from the user's settings into the program and the router. This is part of our Solana and DeFi work, and the same indexing approach powers Meme Wallet.