Jupiter vs direct pool swaps: which volume bot route actually wins

This is a question with an arithmetic answer, not a philosophical one. Aggregated routing buys you a better price and charges you in higher fees and more failures. Direct routing does the opposite. There is a trade size at which the two break even, it is computable, and on either side of it one option is clearly better. Most campaigns never do the calculation and simply inherit whatever their tooling defaults to, which is how people end up paying an aggregator premium to save price impact they were never going to suffer.

Volion Research Updated Jul 30, 2026 6 sections

What each side is actually buying

Aggregated routing buys reduced price impact by splitting a trade across venues and by finding better paths. It pays for that with higher fees, since more programs means more compute, and with a higher failure rate, since more hops means more ways to breach slippage. Direct routing takes the price impact and keeps the fee and reliability.

The critical asymmetry is how the two sides scale with trade size. Price impact grows faster than linearly: double the trade against the same pool and you more than double the impact. Fee and failure costs, by contrast, are effectively fixed per transaction. A failed swap costs the same whether it was for a tenth of a SOL or ten SOL.

That difference in scaling is the whole answer. Below some size, the fixed cost of aggregation dominates and direct wins. Above it, impact dominates and aggregation wins. The only question is where the crossing point sits for your pool, and that is a number you can compute rather than guess.

The measured cost gap

Cost per landed swap is the median fee divided by the success rate. Comparing that figure for Jupiter against the direct venues gives you the fixed penalty aggregation charges, which is the number the price advantage has to beat.
ProgramSampled txFailure rateMedian feeCost per landed swap
Jupiter aggregator v6 low sample3966.7%8,46225,411
Pump.fun AMM (post-graduation)17332.4%6,6559,845
Raydium CLMM low sample4965.3%10,57030,461
Meteora DLMM10969.7%8,45027,888
Orca Whirlpools low sample1877.8%5,22523,536
Aggregated routing against direct venues, measured Sep 15, 2026 at 4:02 AM UTC across 1 finalized mainnet blocks. Fees in lamports.

This gap is the fixed side of the equation. It does not change with your trade size, which is exactly what makes the break-even computable. Note that it does move over time with congestion, so it is worth recomputing rather than treating as settled.

Working out the break-even trade size

Aggregation is worth it when the price impact it saves exceeds the fee and failure penalty it adds. On a constant-product pool, the cost of impact on a trade of size S against usable depth L is roughly S squared divided by L. If aggregation halves that impact, the saving is about half of S squared over L, and break-even is where that saving equals the measured fee gap.

Rearranged, break-even trade size is approximately the square root of twice the depth times the fee gap, with everything expressed in SOL. The formula is crude, because real pools are not perfectly constant-product and aggregation does not always halve impact, but it lands in the right order of magnitude and that is enough to make a decision with.

Working the current measurement through that formula: Jupiter cost about 25,411 lamports per landed swap against 9,845 on Pump.fun AMM (post-graduation), a gap of roughly 15,566 lamports. Against a pool holding around 100 SOL of usable depth, the break-even trade size works out near 0.056 SOL. Against a deeper pool holding around 500 SOL, it rises to roughly 0.125 SOL, because deeper liquidity means less impact for the aggregator to save you from.

Two things follow immediately. First, the deeper the pool, the larger a trade has to be before aggregation is worth it, since deep liquidity already gives you low impact for free. Second, most volume campaigns trade well below any plausible break-even, because campaigns are deliberately built from small trades. For them the answer is direct routing, and it is not close.

The reason campaigns use small trades in the first place, and why that is the correct design rather than a limitation, is covered in makers versus volume.

The factor the arithmetic misses

Split routing divides your volume across the pools it routes through. No price calculation captures that, because it is not a price effect. If the objective is to make one specific pair look active, a route that spreads activity across three venues has undermined the goal regardless of how the fee comparison came out.

This is where the decision stops being purely arithmetic. Two campaigns with identical budgets and identical settings can produce very different outcomes depending on whether their activity landed in one pool or was scattered across several, and the quote that produced them looked equally good in both cases.

So the practical rule has two parts. Run the break-even calculation to find out whether aggregation is even paying for itself in cost terms. Then, if your objective is concentrated activity on a specific pair, weight the answer further toward direct routing, because concentration is a benefit the arithmetic never counted.

The mechanics of how Jupiter builds those split routes, and the failure modes specific to them, are in Jupiter volume bot routing.

How to run this comparison on your own token

Quote the same trade both ways, record the output difference, then send a small batch through each route and count how many land. Multiply the failure difference by the fee to get the penalty, compare it to the output difference, and you have your answer for your pool at today's conditions rather than a general rule.

The measurement is straightforward and takes minutes rather than requiring any special tooling:

  1. Quote both routes at your intended size. Request an aggregated quote and a direct quote for the same swap. The difference in expected output is the price advantage, and on small trades it is frequently close to nothing, which already answers the question in many cases.
  2. Send a sample through each. Twenty or thirty transactions per route is enough to see a difference in landing rate if one exists. Fewer than that and you are measuring noise.
  3. Count landed swaps, not sent ones. Divide the total fees paid by the number that succeeded on each route. That single number is what you are actually comparing, and it is the number no quote will show you.
  4. Repeat under different conditions. A comparison run during a quiet hour will favour aggregation more than one run during congestion, because failure rates diverge as the network gets busier.

One detail worth watching while you do this: compute usage. Aggregated routes consume substantially more compute units than direct swaps, which is part of why their priority fees run higher. If your failures cluster on the most complex routes rather than spreading evenly, the limit rather than slippage is what you are hitting, and the fix is constraining route complexity rather than widening tolerance.

The percentile distribution of fees, which is what tells you whether you are bidding sensibly in the first place, is on the measured transaction costs page.

The practical answer

For volume campaigns built from small trades, direct routing wins on cost, on reliability and on concentration of effect. For single large trades against thin liquidity, aggregation wins clearly. The break-even sits between those cases and moves with pool depth and current fee conditions.

Our routing resolves the venue from where a token actually holds depth and executes there directly, rather than accepting whichever path quotes best. That is a deliberate choice and it is occasionally the wrong one, specifically when a token has genuinely fragmented liquidity with no dominant venue. When that is the case, the honest answer is that aggregation serves it better.

The rest of the venue comparison is on which Solana DEX is cheapest for a volume bot. To put your own numbers through it, the calculator converts a target volume into cost at current measured rates, and campaigns are configured in the dashboard. Why we publish the inputs rather than a single headline figure is explained on the page for the volume bot on Solana itself.

Questions

Is Jupiter or a direct swap cheaper for a volume bot?
For the small trades a campaign is built from, direct swaps are almost always cheaper per swap that lands. Aggregation adds fee and failure cost that is fixed per transaction, while the price impact it saves grows with trade size. Below the break-even size the fixed penalty dominates.
How do I calculate the break-even trade size?
Take the measured cost gap per landed swap between the aggregator and the direct venue, in SOL. Break-even is roughly the square root of twice the usable pool depth multiplied by that gap. Deeper pools push the break-even higher, because they already give low impact without help.
Does direct routing mean worse prices?
On small trades, barely. Price impact is negligible at small sizes, so there is little for an aggregator to improve. The price advantage becomes meaningful only as trades grow large relative to pool depth, which is precisely when aggregation starts being worth its cost.
Why does split routing matter for a volume campaign?
Because it splits the resulting volume as well as the trade. If you are trying to make one pair look active, activity divided across three pools is a third as effective there, and no price comparison will show you that.
When should I definitely use Jupiter?
When a single trade is large relative to available depth, when your pair has no usable direct pool and must be reached through an intermediate asset, or when liquidity is genuinely fragmented with no dominant venue. Those are the cases aggregation was built for.
Do these numbers change over time?
Yes. Fee levels and failure rates move with congestion and with which venues are busy, so the measured gap and therefore the break-even size move with them. The tables here carry the window they were measured over rather than presenting a fixed answer.