Sandwich attacks on Solana

What a sandwich actually is

Three transactions in a row, two of them belonging to someone else. They buy the token immediately before your buy lands. Your buy then executes against a pool whose price they just pushed up, so you receive fewer tokens than you would have. They sell immediately after, into the price your own order created.

The profit is the difference between what the pool was before and what your order made it. Nothing was broken into. The searcher needed exactly one thing: knowledge of your order before it settled, and enough confidence about its size and destination to size their own around it.

That framing matters because it points at the real defence. You are not trying to stop an exploit; you are trying to stop being predictable.

Why Solana is different, and why that is not a solution

On networks with a shared public mempool, pending transactions sit in the open and anyone can read them. Solana does not work that way. Transactions are forwarded toward the upcoming block leaders rather than gossiped into a public waiting room, which removes the simplest form of the attack.

What it does not remove is everything else. Order flow still passes through infrastructure, and infrastructure can observe. More importantly, a large amount of predictability lives on-chain in plain sight: a series of swaps arriving at regular intervals, in similar sizes, into the same pool, is a pattern that can be anticipated without seeing a single pending transaction.

So the honest position is that Solana's design raises the cost of the naive attack and does nothing about the version that reads your behaviour instead of your mempool.

Why volume campaigns are attractive targets

A single retail swap is a one-off opportunity, and small ones are not worth automating against. A campaign is different in exactly the way that matters.

• It repeats. Hundreds of swaps rather than one, so the opportunity is a stream rather than an event.
• It is often regular. Evenly spaced timing is the easiest thing in the world to anticipate.
• It is often uniform. Identical sizes mean the profitable counter-position can be computed once and reused.
• It frequently concentrates. One pool means one place to watch.

Notice that these are the same four properties that make a campaign legible to anyone examining it afterwards. The configuration that invites extraction and the configuration that looks obviously manufactured are the same configuration, which is a useful thing to know because one set of fixes addresses both at once.

There is a size threshold underneath all of this that decides whether you are a target at all. Extraction has to cover the searcher's own fees and risk, so a swap that barely moves the pool is not worth positioning around. This is why the same defence list keeps pointing back at swap size relative to depth: below a certain ratio the attack stops being profitable, and you are protected by arithmetic rather than by infrastructure. Campaigns configured with many wallets and small swaps sit under that threshold naturally.

What it actually costs you

The damage is rarely dramatic per swap, which is why it goes unnoticed. It is a small worsening applied consistently.

Each sandwiched buy fills slightly worse than quoted. Each sandwiched sell realises slightly less. Across hundreds of swaps that becomes a meaningful share of the budget transferred to someone who added nothing, and because it shows up as a slightly lower confirmed volume rather than as an error, it is easy to attribute to something else.

There is a second cost that is easier to see once you know to look for it. Sandwiching adds volatility around your own trades, which makes the chart choppier than the underlying flow warrants. A campaign that should have produced a smooth line produces a jagged one, and the jaggedness is doing persuasion work against you.

Four defences that genuinely help

1. Private relay submission. Sending through a relay rather than broadcasting widely removes the easiest observation path. This is the single highest-leverage change and it is why bundled submission is on by default in most serious tooling.
2. Vary size and spacing. A size band rather than a constant, and uneven intervals rather than a metronome. This attacks predictability directly and costs nothing.
3. Spread across venues. Smaller swaps into several pools are individually less worth attacking and collectively harder to anticipate. It also lowers price impact and slippage failures at the same time.
4. Keep swaps small relative to depth. The profit available from sandwiching scales with how far your order moves the pool. A swap that barely moves it is barely worth sandwiching, which is another reason thin pools are expensive in ways that do not appear on any invoice.

Slippage tolerance deserves a separate mention because it is often described as a defence and is not one. A tight tolerance means an attempted sandwich is more likely to push price past your limit and revert your transaction. You avoid the bad fill and pay the fee for nothing, which is a different outcome rather than a better one. The trade-off between the two is covered in the failure guide.

There is a fifth thing that helps and costs nothing, which is simply not announcing your schedule. Teams sometimes post that a campaign is starting, or run activity at the same hour every day for a week. Both hand away the one thing the defences above are trying to protect, which is unpredictability, and they do it in a form that is easier to read than anything on-chain. If the timing of your activity is discoverable from your own posts, no submission path helps.

What none of these fix

Two things are worth stating plainly so the defences are not oversold.

Nothing makes you invisible after the fact. Every transaction is permanent and public. Private submission changes who can act on your order before it lands; it changes nothing about who can read it afterwards.

Nothing fixes a pool that is too thin. If a modest order moves the price several percent, you are exposed to extraction, to slippage failures and to a bad chart simultaneously, and all three have the same root cause. The liquidity guide covers the ten-second test that tells you whether this applies to your token, and it is worth running before spending anything on execution sophistication.