Jupiter V6 Routing Internals: How Arb Bots Use the API

Jupiter V6 is the backbone of most serious Solana DEX aggregation — it covers Orca Whirlpools, Raydium CLMM, Lifinity, Meteora, and a dozen other AMMs in a single quote call. If you are building a Solana arbitrage or market-making bot, understanding what happens inside that quote endpoint is not optional; it is the difference between capturing edge and donating it to someone who did the reading.

How the Route Graph Is Built

Jupiter maintains an in-memory directed graph where each node is a token mint and each edge is a liquidity pool. On startup — and on a rolling refresh cycle — it fetches on-chain account data for every indexed pool and computes a virtual reserve snapshot. V6 introduced indexed markets, which means Jupiter pre-filters edges by liquidity depth before the per-quote path search even begins. Pools below a configurable USD threshold are pruned from the live graph, which cuts search latency dramatically but also means very thin long-tail pools may be invisible to the router even when they theoretically offer a better price.

The path-finding algorithm itself is a modified Bellman-Ford over log-price space. Taking the negative log of each exchange rate converts multiplicative path costs into additive ones, and finding the maximum-output path becomes a shortest-path problem. Jupiter limits path depth to three hops by default. Beyond three hops, the cumulative slippage and fee drag almost always eliminates the output advantage, so the constraint is economically justified, not arbitrary.

Quote Caching and Staleness Windows

The /quote endpoint does not hit the chain on every call. Jupiter's backend maintains a quote cache with a TTL in the 400–800 ms range depending on market volatility signals. For a low-frequency integrator that is fine. For an arb bot, it is a critical detail: if you hammer /quote at 50 rps you will repeatedly receive the same cached response until the TTL expires, miss the price move you are trying to capture, and burn RPC budget on no new information.

The practical fix is to track the contextSlot field in every quote response. When contextSlot stops incrementing across sequential calls, you are reading stale cache. Under normal conditions you should see the slot advance every 400 ms in line with Solana's block time. If it freezes, back off and wait — or switch to a self-hosted Jupiter instance where you control the refresh loop and can tie cache invalidation directly to your own slot subscription.

Slippage, Price Impact, and the dynamicSlippage Flag

V6 exposes two distinct concepts that arb bots routinely conflate. Price impact is the route's estimated output degradation due to the trade's own size moving AMM reserves — it is deterministic given the current reserve snapshot. Slippage tolerance (slippageBps) is the maximum acceptable deviation between the quoted output and the on-chain execution output, covering reserve drift that happens between quote time and transaction landing.

Setting slippageBps too high means you accept fills far off the quoted price; too low and you get frequent transaction failures that waste compute budget and block landing. The sweet spot for most Solana arb strategies is in the 25–75 bps range, calibrated against the volatility of the specific token pair. Jupiter V6 also ships dynamicSlippage: true, which asks the router to compute a pair-specific tolerance based on recent price variance. It is worth enabling for pairs you trade infrequently; for your core pairs you should derive the tolerance from your own historical fill data — you will have better signal than a generic heuristic.

Transaction Assembly and Priority Fees

The /swap endpoint returns a base64-encoded, partially signed transaction. A common mistake is to deserialize it, add your priority fee instruction, and broadcast without checking whether the fee instruction was already included. Jupiter V6 always inserts a ComputeBudgetProgram.setComputeUnitPrice instruction; if you blindly prepend another one, the transaction will include two conflicting budget instructions and may be rejected by validators or process with unpredictable priority.

The correct pattern: deserialize the transaction, locate the existing ComputeBudgetProgram instructions, and replace the unit price value in place rather than appending. For latency-sensitive arb you want to compute your priority fee dynamically — typically the 75th-percentile recent fee for the accounts you are writing, not a static value baked into your config. Solana's getRecentPrioritizationFees RPC method gives you per-account recent fee history; use it.

Handling Route Failures and Fallback Logic

Production arb bots need a failure taxonomy. Jupiter quote failures broadly fall into three categories:

• No route found — the token pair has no connected path in the current graph. Either liquidity has dried up or the pool fell below the indexing threshold. Log and skip; retrying immediately will not help.
• Simulation failure — the assembled transaction failed preflight simulation. Usually caused by stale reserves between quote time and swap assembly. Re-quote immediately and retry once; if it fails again, the opportunity has closed.
• Landing failure — the transaction reached the validator but failed on-chain, typically due to slippage exceeded or another bot landed first. Track landing failure rate by pair; a persistently high rate means your slippage tolerance is too tight or your transaction is arriving consistently late, which is a fee or RPC topology problem.

Logging all three failure types with timestamps and contextSlot values gives you the data to distinguish infrastructure problems from market conditions — an essential separation when you are debugging a bot at 3 a.m.

---

If you want a team that has already worked through these integration details and runs bots in production across Solana and Hyperliquid, get in touch — we build and operate the infrastructure so you do not have to start from scratch.