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.
What each side is actually buying
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
| Program | Sampled tx | Failure rate | Median fee | Cost per landed swap |
|---|---|---|---|---|
| Jupiter aggregator v6 low sample | 39 | 66.7% | 8,462 | 25,411 |
| Pump.fun AMM (post-graduation) | 173 | 32.4% | 6,655 | 9,845 |
| 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 |
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
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
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
The measurement is straightforward and takes minutes rather than requiring any special tooling:
- 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.
- 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.
- 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.
- 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
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.