Jupiter vs Raydium Routing: Where MEV Risk Hides

Route a 500 SOL swap through Jupiter and you might touch four pools across three programs before the tokens land in your wallet. Route the same swap directly through Raydium and you touch one. Both paths can get sandwiched. Neither is safe by default. But the shape of the risk is completely different, and most teams building execution bots get this wrong because they benchmark on price impact instead of MEV surface area.

This matters more than it sounds. If you're running a market-making bot, an arb bot, or anything that fires large swaps on a schedule, the router you pick determines what a searcher sees in the mempool and how many places they can insert a sandwich.

How Jupiter's routing actually works

Jupiter isn't a DEX. It's a routing layer that splits and chains swaps across Raydium, Orca, Meteora, Phoenix, and a dozen smaller venues, picking whichever combination of pools gives the best quote after simulating price impact. A single swap can become a 3-hop route: 40% through a Raydium CLMM pool, 60% through an Orca Whirlpool, recombined at the output token.

This split routing is genuinely good for price. It's also a bigger attack surface. Each hop is a separate instruction with its own pool state, and a searcher only needs one of those pools to be thin to extract value. Worse, Jupiter's routes are visible pre-execution once your transaction hits the mempool (or gets leaked by an RPC node before landing), so a searcher can simulate your exact multi-hop path and figure out which leg to attack.

The other wrinkle: Jupiter's slippage tolerance applies to the aggregate output, not per-hop. You can set 50 bps slippage on the whole route and still eat a bad fill on one leg if the other legs perform well enough to keep the total within tolerance. I've seen this misread as "Jupiter protected me" when actually one pool got sandwiched and the loss was masked by favorable pricing elsewhere.

How direct Raydium routing works

Sending a swap straight to a Raydium pool (CPMM or CLMM) skips the aggregation layer entirely. One instruction, one pool, one price curve. Simpler to reason about, and critically, easier to protect: you're setting per-transaction slippage against a single deterministic AMM curve, not a composite of multiple pools with different liquidity depths.

The tradeoff is obvious — you're stuck with whatever price that one pool offers, which on a Solana pair with fragmented liquidity (think a mid-cap SPL token split across Raydium and three other venues) can mean 1-3% worse execution than an aggregated route. For large size, that's real money.

Where direct Raydium wins on MEV: a single-pool swap is a known, well-studied sandwich pattern. Searchers running standard Jito bundle strategies target Raydium CLMM pools constantly, so the defenses are also more mature — private RPC submission, Jito bundles with tips, and slippage tuned tight against one curve all work predictably. Multi-hop Jupiter routes are harder to defend uniformly because each hop may need different slippage handling.

A concrete example

Say you're swapping 10,000 USDC for a token trading on both a deep Raydium CLMM pool and a shallower Orca pool.

Jupiter route:
  Hop 1: 7,000 USDC -> TOKEN via Raydium CLMM (0.04% price impact)
  Hop 2: 3,000 USDC -> TOKEN via Orca Whirlpool (0.31% price impact)
  Blended output: better than either pool alone

Direct Raydium route:
  10,000 USDC -> TOKEN via Raydium CLMM (0.09% price impact, all in one pool)

The Jupiter route nets you more tokens. But a searcher watching the mempool now has two viable sandwich targets instead of one, and the Orca leg — thinner, more price-sensitive — is the softer target. If you set slippage at 50 bps on the aggregate, the searcher can extract most of the value available on that Orca leg specifically, because your slippage budget doesn't know it's "supposed" to protect that leg more tightly.

Where the MEV actually hides

• Route disclosure timing. Jupiter routes are computed client-side and submitted as a single transaction, but if you're pulling quotes via the public API repeatedly before submission, that quote traffic is itself a signal generators can watch.
• Per-hop slippage blindness. Aggregate slippage settings hide which leg is vulnerable. Tight aggregate slippage doesn't mean tight per-pool protection.
• CLMM tick crossing. Raydium's concentrated liquidity pools sandwich differently than constant-product pools — a large swap that crosses several ticks creates a bigger, more predictable price gap for a searcher to exploit between the front-run and back-run.
• RPC leakage. Both routing paths are equally exposed if you're broadcasting through a public RPC instead of a private relay or Jito's block engine. This is the single biggest lever most teams ignore, and it matters more than which router you chose. If you haven't compared submission paths, the tradeoffs between Jito bundles and Flashbots-style auctions and the mechanics of how the Jito block engine actually runs its auction are worth understanding before you touch routing at all.
• RPC latency. If your bot's decision loop is reading state off a lagging RPC node, you're sandwiching yourself before an external searcher even gets involved — see the gap between Yellowstone gRPC and standard Solana RPC for MEV-sensitive latency.

Comparison

Dimension	Jupiter (aggregated)	Raydium (direct)
Price execution	Better on size, fragmented liquidity	Worse if liquidity is thin elsewhere
Attack surface	Multiple pools, multiple hops	Single pool
Slippage control	Aggregate only, per-hop blind spots	Precise, single-curve
Sandwich predictability	Harder to model, varies per route	Well-studied, standard patterns
Defense maturity	Needs per-hop-aware tooling	Private RPC / Jito bundles work cleanly
Best for	Large, illiquid, or exotic pairs	Deep, single-venue pairs; latency-sensitive bots

Which to pick, and when

For retail-sized swaps on major pairs (SOL/USDC, major SPL tokens with deep Raydium liquidity), route directly through Raydium. The MEV surface is smaller, your slippage setting means what you think it means, and standard bundle-based protection works without extra engineering.

For anything illiquid, exotic, or large enough that single-pool price impact actually costs you more than the added MEV surface, use Jupiter — but don't submit with default aggregate slippage on size. Split your own slippage budget per hop if the SDK allows it, or route through a private mempool submission path regardless of which aggregator you use.

If you're running this at production volume — a market maker, arb bot, or anything firing size regularly — the router choice is secondary to your submission infrastructure. Teams we've built Solana MEV and arbitrage bots for consistently see bigger loss reduction from fixing RPC exposure and bundle submission than from switching routers. If your execution stack still guesses at routing and slippage instead of measuring per-hop exposure, that's the actual place to start.

Building or auditing a Solana execution bot and want the routing and submission path reviewed for MEV exposure? Get in touch about a Solana MEV bot build.