Jupiter volume bot routing: when the best price is the worst deal

Jupiter does one thing extremely well: it finds the best available price by searching across every venue and splitting your trade wherever that helps. For a trader moving size, that is close to strictly good. For a volume campaign it introduces two problems that never appear in a quote, and both of them cost money. The first is that longer routes fail more often. The second is that a split route spreads your activity across several pools, which is the opposite of what a campaign is usually trying to achieve.

Volion Research Updated Jul 30, 2026 6 sections

What Jupiter actually does to your swap

Jupiter is a router, not a pool. It holds no liquidity of its own. When you request a swap it searches the venues it knows about, works out which combination gives the best output, and builds a transaction that executes that combination. That combination is frequently more than one hop and sometimes more than one venue at once.

A simple route is one hop: your token to SOL in a single pool. A multi-hop route passes through an intermediate asset, so token to USDC to SOL, using two pools. A split route divides the trade across several pools in parallel to reduce price impact on each. Jupiter will use any of these, and it picks purely on quoted output.

That optimisation target is the root of the mismatch. Jupiter is optimising the number that appears in the quote. It is not optimising the probability that the transaction lands, and it is not optimising where the resulting volume shows up. For a one-off trade those two things barely matter. For a campaign that will send thousands of transactions, they matter more than the quote does.

Why longer routes fail more often

Every hop is a separate pool with its own price that can move between quote and execution, and every hop is another program that can reject the transaction. A route through three pools has three independent chances to breach your slippage limit instead of one, and the transaction is atomic, so any single failure kills the whole thing.

The failure probabilities compound rather than average. If each hop has a modest chance of moving against you, a three-hop route carries close to three times that chance, and the whole transaction is discarded if any leg fails. You do not get a partial fill, and you still pay the fee.

Longer routes also consume more compute. A transaction that touches several programs uses far more compute units than a single swap, which means a higher priority fee to get scheduled and a real risk of hitting the compute limit outright on complex routes. Both show up as a higher median fee before a single failure is counted.

In the current window Jupiter v6 showed a median fee of 8,462 lamports and a 66.7% failure rate across 39 sampled transactions, which works out to roughly 25,411 lamports per swap that lands. That median fee sits about 1,807 lamports above a direct swap on Pump.fun AMM in the same window, before failure rates are taken into account at all.

None of this makes Jupiter badly built. It is doing exactly what it promises. The point is that the promise is about price, and a campaign is buying something else.

Jupiter measured against the venues it routes through

The table reads finalized mainnet blocks directly, recording the fee paid and the outcome for every transaction touching each program. Jupiter is shown next to the venues it actually routes into, so the comparison is between the aggregator and the pools it would have sent you to.

Jupiter against the venues it routes through, measured Sep 15, 2026 at 4:02 AM UTC across 1 finalized mainnet blocks. Fees in lamports.
Program	Sampled tx	Failure rate	Median fee	Cost per landed swap
Jupiter aggregator v6 low sample	39	66.7%	8,462	25,411
Raydium CLMM low sample	49	65.3%	10,570	30,461
Meteora DLMM	109	69.7%	8,450	27,888
Orca Whirlpools low sample	18	77.8%	5,225	23,536
Pump.fun AMM (post-graduation)	173	32.4%	6,655	9,845

The pattern to look for is not whether Jupiter is highest or lowest on any single column, but the gap between its cost per landed swap and that of the venue it would have routed you into. That gap is the real price of aggregation, and the quoted price improvement has to exceed it for the routing to have been worth taking.

The cross-venue picture is on which Solana DEX is cheapest for a volume bot, and the direct head-to-head arithmetic, including where the break-even actually sits, is in Jupiter versus direct pool swaps.

The split routing problem nobody mentions

When Jupiter splits a trade across several pools, the resulting volume is split too. If your campaign is meant to make one specific pair look active, routing that distributes activity across three venues has divided your effect by three while charging you a higher fee for the privilege.

This is the consideration most specific to volume campaigns and the one most often missed, because it is invisible in the quote. The quote shows a better output amount. It does not show that the trade which produced that amount landed as three smaller trades in three different places.

Whether that matters depends on what you are trying to affect. If the objective is a chart on a particular pair, splitting works directly against it. If the objective is broad token-level activity across everything a data aggregator reports, splitting is neutral or occasionally helpful. Most campaigns are the first kind and are configured as though they were the second.

The related question of what a chart actually reflects, transaction count against notional size, is covered in makers versus volume, and how third-party trackers pick up activity is in how DEXScreener trending works.

When Jupiter routing is the right call

Use Jupiter when price impact dominates the decision: a single large trade, a thin direct pool, or a pair whose best liquidity genuinely sits behind an intermediate asset. Avoid it when the trades are small and numerous and you know exactly which pool you want the activity to appear in.

Large single trades. When the trade is big enough that price impact on a single pool would be severe, splitting across venues is worth the added failure risk, because the impact saved is larger than the failure cost.
No usable direct pool. If the only meaningful liquidity for your pair is reachable through an intermediate asset, a multi-hop route is not a preference, it is the only way to trade at all.
Genuinely fragmented liquidity. Some tokens have real depth spread across several venues with none dominant. Aggregation is designed for exactly that situation.

Against that, the campaign case for direct routing is straightforward. Small trades have negligible price impact, so the price advantage Jupiter can offer on them is tiny. Meanwhile the failure rate difference is not tiny, and neither is the effect of splitting activity you wanted concentrated. When your trades are small, direct routing usually wins on both counts at once.

Settings that matter if you do route through Jupiter

Cap the number of hops, keep quotes fresh, set slippage from observed pair movement rather than a default, and treat a failure as a signal to re-quote rather than resubmit. The minimum output is signed into the instruction, so an expired quote fails identically every time you send it.

Limit route complexity. If you can restrict the router to direct or single-hop routes, do. The price given up is usually small and the reliability gained is not.
Keep the quote-to-submit gap short. Every second between quoting and broadcasting is another second for any pool on the route to move. Build, sign and send in one pass.
Re-quote on failure, do not resubmit. The signed minimum output cannot succeed once price has moved past it. Resubmitting the same transaction reproduces the failure and pays the fee again.
Watch compute limits. Complex routes can exhaust the compute budget outright. If failures cluster on the most complex routes rather than being spread evenly, that is the cause rather than slippage.

Our own routing resolves the venue from where a token actually has depth rather than from whichever path quotes best, which is a different objective and produces different choices. Why we make that trade, and what it costs when we are wrong, is set out on the Solana volume bot routing page. To put numbers against your own token first, the calculator converts a target volume into cost at current measured rates, and a campaign is configured in the dashboard.

Questions

Does Jupiter make volume bot swaps cheaper?

It usually gets a better quoted price and often a worse landed cost. Aggregated routes touch more programs, so they use more compute, need a higher priority fee, and fail more often. Whether the price improvement covers that gap depends almost entirely on trade size, and for the small trades a campaign uses, it typically does not.

Why do Jupiter swaps fail more than direct swaps?

A route through several pools has several independent chances to move past your slippage limit, and the transaction is atomic, so any one leg failing discards the whole thing. Longer routes also consume more compute, which adds a second failure mode when the budget runs out.

Does aggregated routing split my volume across pools?

Yes, when Jupiter chooses a split route. The trade is divided across several pools and so is the volume it produces. If the goal is to make one specific pair look active, that division works directly against it.

Should I use Jupiter for a large one-off swap?

Usually yes. When price impact on a single pool would be severe, splitting across venues saves more than the higher failure rate costs. The calculation only flips for small trades, where impact is negligible and there is little price advantage left to capture.

Can I stop Jupiter from using multi-hop routes?

Routing complexity can generally be constrained, and doing so is often worth it for a campaign. The price you give up on a small trade is minimal, while the reliability you gain from a shorter route is not.

Why did my Jupiter swap fail with a slippage error?

The route was still valid but the output fell below the minimum you signed for, most often because one of the pools on the route moved between quote and execution. Resubmitting cannot help since that minimum is baked into the instruction; you need a fresh quote.

Jupiter versus direct pool swaps Jupiter aggregator routing Cheapest DEX for a volume bot Makers versus volume Measured transaction costs How DEXScreener trending works