Jupiter volume bot: the convenience that costs the most

Jupiter is not a venue. It is a router that finds a path across the venues, and for a person making one swap that is straightforwardly useful. For a fleet making thousands of swaps it is the most expensive routing decision available, and our block measurements show why: aggregated routes produce larger transactions touching more accounts, and larger transactions lose the contention race more often. Every one of those losses is charged in full.

Volion Research Updated Jul 30, 2026 4 sections

What an aggregator actually does to your transaction

Jupiter computes a route across one or more pools and builds a transaction that executes it. A single-hop route is close to a direct swap. A split or multi-hop route touches several pools in one transaction, which means more account references, more compute and a bigger transaction. Every one of those factors raises the chance of failure under contention.

The routing itself is genuinely good. If a token has liquidity scattered across several pools, an aggregator will usually find better execution than any single pool provides, and for large trades that price improvement is real money. The question for a campaign is whether the improvement covers the additional failure risk, and at the trade sizes a volume campaign uses, it usually does not.

A volume campaign makes many small trades. Small trades barely benefit from route optimisation because price impact is negligible either way. What they are sensitive to is the per-transaction cost of landing at all, and that is exactly what aggregation makes worse.

Measured: the highest failure rate we sample

Jupiter v6 transactions in our latest sample failed at 55.9%, against a network-wide 27.9%. The median fee was 9,097 lamports, which puts the cost per swap that actually landed at 20,628 lamports. Direct routing to the Pump.fun AMM measured 23.3% in the same sample, so aggregator routing failed roughly 2.4 times as often on comparable traffic. A failed swap pays its fee and produces no volume, so this is a direct multiplier on campaign cost rather than an abstract reliability concern.

Aggregator routing measured against the direct venues it routes into, from the same block sample. The comparison is the point: a route that touches more pools is a larger transaction, and larger transactions lose more often under contention.
Program	Sampled tx	Failure rate	Median fee	Cost per landed swap
Jupiter aggregator v6	286	55.9%	9,097	20,628
Pump.fun AMM (post-graduation)	2,341	23.3%	8,243	10,747
Meteora DLMM	863	38.9%	6,642	10,871
Orca Whirlpools low sample	35	31.4%	5,432	7,918
Raydium CLMM	54	48.1%	5,081	9,790

This is one of the findings we did not expect when the sampler was first written, and it is the reason the routing control in the console defaults to direct rather than aggregated. The fee per attempt on aggregator routing is not dramatically higher. The share of attempts that produce nothing is.

Two mechanisms explain most of it. First, a transaction referencing more writable accounts collides with more other transactions competing for the same accounts, and the loser is dropped. Second, aggregated routes carry tighter execution constraints, so a route computed a moment ago can fail its own slippage check by the time it lands. Both effects scale with how busy the venue is, which is why the gap widens during launch windows.

Method, sample size and slot range are published on the measurement page. Every figure here is read from finalized blocks rather than estimated.

When routing through an aggregator is still right

Use it when liquidity for your token is genuinely fragmented across several pools, when individual trades are large enough that price improvement outweighs the failure premium, or when you do not know which venue holds the depth. Avoid it for small, high-frequency trades against a single deep pool.

The rule of thumb: aggregation buys execution quality and costs reliability. Volume campaigns care about reliability, so the default should be direct.
Situation	Better path	Why
One deep pool holds the liquidity	Direct	Nothing to aggregate; you pay the failure premium for no benefit
Liquidity split across several pools	Aggregated	Route improvement can exceed the failure premium
Many small trades	Direct	Price impact is negligible at small size, so there is nothing to improve
Few large trades	Aggregated	Slippage saved on size outweighs the extra failures
Contested launch window	Direct	Contention is exactly when big transactions lose most often

Volion resolves the deepest routing target from the mint and routes directly to it by default, with aggregation available as an explicit choice rather than a silent one. The console shows which program it resolved to and prices the campaign against that program measured failure rate, so switching routing changes the estimate you see before funding.

Does routing through Jupiter change what aggregators show

No. DexScreener, Birdeye and GeckoTerminal index pool activity. A swap that reaches a pool is indexed the same way whether a router or a wallet sent it. Routing through an aggregator does not add visibility, and routing directly does not remove any.

This matters because it removes the only argument for paying the failure premium on a volume campaign. If aggregated routing produced better indexing, the extra cost would buy something. It does not. The pool records a trade, the indexer picks it up, and the transaction path that produced it is not part of what gets counted.

What does affect how activity is read is the shape of it: how many distinct wallets traded, how spread out the trades were, and whether the sizes look chosen by people or generated by a loop. What aggregators index and how fleets get identified both go into that in detail.

For the venue-by-venue picture, the Solana volume bot overview links every routing target we measure, and the pricing page shows what each one costs at current rates.

Questions

Can a volume bot route through Jupiter?

Yes, and many do by default. Our measurements suggest it is the most expensive default available for a campaign, because aggregated transactions fail more often than direct swaps and failures are charged in full.

Why do aggregator transactions fail more often?

They reference more accounts and use more compute, which makes them collide with more competing transactions for the same writable accounts. They also carry tighter execution constraints, so a route can fail its own slippage check between computation and landing.

Does routing through Jupiter improve DexScreener visibility?

No. Aggregators index pool activity, not the path a transaction took to reach the pool. A direct swap and an aggregated swap that both land are indexed identically.

When should I use aggregated routing?

When liquidity for your token is genuinely spread across several pools, or when individual trades are large enough that the execution improvement outweighs the higher failure rate. For many small trades against one deep pool, direct routing is cheaper.

Is Jupiter charging me a fee?

The router itself does not take a fee on a standard swap; the cost is the pool fee of whichever venue the route lands in, plus the Solana network fee. The expensive part in our data is not a router fee, it is the share of attempts that never land.

Which routing does Volion use?

It resolves the deepest venue from the mint and routes directly by default. Aggregated routing is available as an explicit choice, and the cost estimate in the console updates to the measured failure rate of whichever path you pick.

Measured transaction costs Meteora DLMM routing Orca Whirlpool routing Pricing