Sandwich Attacks on Solana: Raydium AMM vs Jupiter Aggregator
Jupiter's smart-routing and slippage guards behave very differently from raw Raydium pools under sandwich pressure. This post maps out where sandwiching remains viable on Solana in 2025, which pool types are hardest to sandwich, and why aggregators are not a complete shield.
Sandwich attacks on Solana behave fundamentally differently from their EVM counterparts, and the gap between hitting a raw Raydium pool versus routing through Jupiter is wider than most traders realise. The mechanics, the viable targets, and the defences all deserve a closer look — because understanding where the edge still exists changes how you build both the attacker and the defender.
How Sandwich Attacks Work on Solana
The classic sandwich: a searcher sees a pending swap, front-runs it to move the price, lets the victim fill at a worse rate, then back-runs to close the position. On EVM chains this is mempool-native. Solana has no public mempool — transactions are forwarded directly to the current leader — which eliminates the naive approach of watching a pending-tx feed and racing to include earlier.
What Solana searchers use instead is Jito's block-engine. Jito bundles let a searcher submit an ordered group of transactions to a Jito validator (roughly 50-60% of Solana stake runs Jito tip-infrastructure as of mid-2025). The bundle is atomic within the block: if any leg fails, the whole bundle reverts. The searcher tips the validator in SOL, and the leader includes the bundle and honours the ordering.
The result: sandwich attacks are very much alive on Solana, they just require a Jito-aware stack and a reasonable tip budget. The latency window is tighter — you're competing at the bundle-submission level, not the mempool-propagation level.
Raydium AMM: The Natural Hunting Ground
Raydium's CPMM (constant-product, x * y = k) pools are the closest thing Solana has to an unguarded EVM Uniswap v2 pool. A large swap moves the price along a deterministic curve, and the price impact is predictable from on-chain state.
Conditions that make a Raydium CPMM trade sandwich-viable:
- Loose slippage tolerance. Raydium's UI defaults to 0.5% for stable pairs and 1% for others, but many DeFi-native traders open it to 3-5% "to make sure it fills." That tolerance is the sandwich attacker's free money.
- Thin pools. A $50k pool gets moved meaningfully by a $5k trade. The attacker's front-run needs less capital and collects a larger spread before the victim's fill price degrades.
- No CLMM protection. Raydium's concentrated-liquidity pools (CLMM) are harder targets. If price moves out of the active tick range, the subsequent back-run leg stops collecting fees and the math breaks. In practice, most sandwich volume still hits CPMM, not CLMM.
The minimum profitable sandwich on a thin Raydium CPMM pool can be as low as a $20 victim trade at 2% slippage, once you account for Jito tips (~0.001 SOL) and transaction fees (~0.000005 SOL per tx). Margin is thin, but the volume is there — thousands of such trades happen every hour.
Jupiter: Smarter Routing, Not a Full Shield
Jupiter adds two layers that raise the cost of sandwiching: smart routing and dynamic slippage.
Smart routing splits a trade across multiple pools and DEXes to minimise price impact. A $100k USDC→SOL trade that would move a single Raydium pool by 2% might be split 40% Raydium CPMM, 30% Orca CLMM, 20% Meteora DLMM, 10% another venue. To sandwich the full order you would need to front-run every pool in the route simultaneously — that's multiple instructions in the same bundle, across accounts that may require different signers, with each leg needing to land before any Jupiter CPI executes. The attack surface is narrower per-pool, and the cross-pool coordination overhead often kills the edge.
Dynamic slippage (introduced on Jupiter in late 2024) samples recent price volatility on the output token and tightens the slippage tolerance automatically during low-volatility conditions. A searcher watching a pending Jupiter instruction and assuming 1% slippage headroom may find the actual tolerance is 0.3%, making the sandwich unprofitable before they've submitted anything.
Where Jupiter falls short as a shield:
- Large single-pool routes. If Jupiter's routing engine determines the best execution for a given pair is 100% through one deep Raydium CPMM pool, the trade is just as sandwichable as a direct Raydium swap. This happens most often for exotic small-cap tokens with liquidity concentrated on one venue.
- CPI visibility. Jupiter routes are built via CPI (cross-program invocation), and the full account keys — including which pools are touched — are visible in the transaction. A fast searcher can parse the instruction, identify single-pool routes, and target them.
- Slippage as a reveal. Dynamic slippage helps, but Jupiter still sets a
minimumAmountOutin the instruction. A searcher who can simulate the transaction (which is public once sent to a Jito relay) can infer the exact tolerance and set a front-run size accordingly.
Which Pool Types Are Hardest to Sandwich
Rank from most to least resistant:
- Meteora DLMM (dynamic liquidity market maker). Bin-based liquidity with discrete price steps. A front-run that crosses a bin boundary may push into a bin with no liquidity, making the back-run worthless. Effective slippage is also self-limiting.
- Raydium CLMM / Orca Whirlpool (concentrated liquidity). Multi-tick positions make price impact non-linear. The attacker's capital efficiency drops sharply as ticks are consumed in the front-run.
- Raydium CPMM (constant product). Predictable curve, easy to model, easiest to sandwich.
- Small single-venue meme tokens. Extreme thinness often means a sandwich is technically viable but size-limited — you can extract $2, not $200.
Jito bundles are the attacker's delivery mechanism regardless of pool type, but the opportunity set narrows significantly above CPMM.
What Actually Defends Against Sandwiching
Protocol-level defences matter more than aggregator routing:
- Private RPC endpoints / Jito block-engine directly. Submitting to a Jito bundle endpoint with a competitive tip, without broadcasting broadly, reduces the window for competing searchers to observe and wrap your transaction.
- Tight programmatic slippage. If you're building a bot that swaps on Raydium or through our MEV & arbitrage infra, setting
minimumAmountOutto 0.3-0.5% of expected output (not 1-3%) is often enough to make a sandwich unprofitable, at the cost of occasional failed transactions on volatile pairs. - Order size management. Breaking a $500k swap into twenty $25k tranches across separate blocks removes most of the sandwichable surface. Each sub-trade is individually small enough that tips eat the attacker's margin.
- CLMM preference when available. Routing directly to Raydium CLMM or Orca Whirlpool pools, rather than CPMM, raises the attacker's modelling complexity enough to price them out on thinner opportunities.
None of these eliminate the attack vector. They raise the minimum profitable victim size, which is usually enough for non-institutional flows.
The Real State of Solana MEV in 2025
Jito tip volume has grown consistently through 2024-2025, which is the clearest on-chain signal that MEV is profitable and active. Backrunning and arbitrage dominate by transaction count; sandwich attacks are a smaller slice but disproportionately harmful to retail swappers on thin pools. The validators running Jito earn the tips regardless of strategy type, creating a stable equilibrium where searchers compete on tip and latency rather than on finding unguarded infrastructure.
Jupiter's routing genuinely reduces the average slippage and sandwich exposure for a typical user, and is worth using as the default execution path. The mistake is treating it as a complete defence. If you're building execution infrastructure — whether that's a high-frequency bot, a token launch engine, or a Solana MEV strategy — you need to model the attack surface explicitly, not assume the aggregator handles it.
If you're building Solana execution infra and want the sandwich math modelled into your bot design from the start, talk to us.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article