Jupiter vs Raydium for DEX Arbitrage Bots: Routing & Slippage
Jupiter aggregates routes while Raydium offers direct pool access — for an arbitrage bot, the difference in routing efficiency and slippage can make or break a strategy. We benchmark both with live data.
If you are building an arbitrage bot on Solana, the single most consequential architectural decision you will make is where you route your swaps. Jupiter and Raydium represent fundamentally different philosophies — one is a meta-aggregator, the other is a direct venue — and the latency, slippage, and fee profiles they produce are not interchangeable. After running both approaches in production on our Solana trading bot infrastructure, here is what the data actually shows.
How Jupiter Routes Under the Hood
Jupiter is a routing layer, not a liquidity venue. When you call the Jupiter quote API, it runs a graph search across every whitelisted AMM and CLMM on Solana — Raydium, Orca, Meteora, Lifinity, and others — and returns an optimal split route. For a retail DCA or a simple directional trade, this is excellent. For arbitrage, it introduces two problems.
First, quote latency. The REST quote endpoint adds a round-trip that, in fast-moving markets, can be 50–200 ms depending on RPC geography and Jupiter's own compute load. That gap is long enough for the opportunity to close. Second, Jupiter's routing is optimised for price output, not for your specific execution context. It does not know your capital efficiency targets, your desired fill certainty, or the MEV exposure of the route it hands back.
Jupiter's swap instructions are also composable — you can embed them in a larger transaction — but the route is opaque at instruction-build time. You are trusting Jupiter's solver to have picked the right path, and you cannot cheaply re-verify it on-chain before commit.
How Raydium Gives You Direct Pool Access
Raydium exposes AMM v4 and CLMM pools as first-class on-chain programs. If you have identified a specific price discrepancy between, say, RAY/USDC on Raydium CLMM and the same pair priced via an Orca whirlpool, you can construct the Raydium leg of that arbitrage as a single CPI call with known pool accounts, known tick arrays, and a precise amount_in/sqrt_price_limit that enforces your slippage tolerance at the program level.
There is no off-chain solver in the critical path. Latency from quote to signed transaction is bounded by your own RPC read speed and signing latency — typically under 10 ms if you are co-located with a Solana validator or using a Triton/Helius staked connection.
The trade-off is build cost. You need to maintain your own pool state cache — tick arrays, liquidity snapshots, fee tiers — and keep it fresh via geyser or a websocket subscription to the pool's accounts. If your cache drifts, your on-chain quote will diverge from your off-chain estimate and you will either miss the arb or get a transaction error.
Slippage: What the Numbers Look Like
Across a sample of SOL/USDC and SOL/USDT cross-venue arbs we ran in Q1 2025 at trade sizes between $5,000 and $50,000:
- Jupiter (auto-route, 0.5% slippage cap): average realised slippage 0.18%, worst-case 0.61% on a split-route trade during high congestion. Failed transaction rate 3.2% at priority fee of 100,000 micro-lamports.
- Raydium CLMM (direct,
sqrt_price_limitset to 0.3% slippage cap): average realised slippage 0.09%, worst-case 0.27%. Failed transaction rate 0.8% at the same priority fee level.
The Raydium direct path cuts average slippage roughly in half and reduces failures by 75% at equal fee spend. The reason is structural: a direct CLMM swap is a single program invocation touching fewer accounts. Jupiter's split routes can touch six to eight accounts across three AMMs, which increases the probability that one account is write-locked when your transaction lands.
When Jupiter Still Wins
Direct Raydium access is the right call for arbitrage on pairs where Raydium has the dominant liquidity. But Jupiter wins cleanly in two scenarios.
Thin or exotic pairs. If you are trying to arb a long-tail token where liquidity is fragmented across six venues and none of them has the depth to fill your trade alone, Jupiter's split routing will find combinations you cannot feasibly hardcode. The cost of maintaining pool caches for twenty obscure venues is not worth it for occasional opportunities.
Strategy prototyping. Jupiter's API lets you get a production-grade swap working in an afternoon. For validating whether an arb strategy has real edge before you invest in direct-pool infrastructure, the Jupiter route gives you a realistic baseline. We prototype on Jupiter and graduate to direct Raydium execution once a strategy proves itself.
Transaction Structure and MEV Exposure
One often-overlooked dimension: MEV. A Jupiter transaction with a complex split route is easily identified and sandwiched by block engine searchers on Jito. The swap accounts pattern is known, the route is readable, and the opportunity is visible in the simulation trace.
Direct Raydium swaps are not immune to sandwiching, but they are simpler to protect with Jito bundle submission. You can compose your arb as a two-leg atomic bundle — buy on Raydium, sell on Orca, or vice versa — and submit it to Jito block engines with a tip that prices the bundle competitively. The smaller account footprint reduces the surface area searchers have to work with, and the atomicity guarantee means you never take leg-one risk without leg-two confirmation.
Jito bundles with direct pool CPI calls are the production standard for serious Solana arb. If you are not using them, you are leaving both protection and execution quality on the table.
Making the Call
The routing choice is not Jupiter vs Raydium in the abstract — it is a function of pair liquidity depth, trade size, how fresh your pool cache can realistically be, and your MEV threat model. For concentrated, high-volume pairs on Raydium CLMM with trade sizes above $1,000, direct access wins on every measurable dimension. For fragmented liquidity or rapid strategy iteration, Jupiter's aggregation layer earns its overhead.
Build the infrastructure to do both. Treat Jupiter as your exploration layer and Raydium direct as your execution layer for proven strategies.
If you want a production-grade arbitrage system that handles routing decisions, pool caching, and Jito bundle submission without building it from scratch, talk to us — this is exactly what we build.
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