Raydium volume bot pool selection: which pair actually moves
A token can have several Raydium pools at once, across different programs and against different quote assets, and they are not interchangeable. Volume generated in the wrong one produces price movement instead of a useful chart, gets picked up inconsistently by the trackers people actually look at, and costs more per swap that lands. Choosing correctly takes a few minutes and is worth more than almost any other setting in a campaign.
Finding out what pools actually exist
The reliable way to enumerate them is to look at where swaps for your token are actually executing on chain rather than at which pools are listed somewhere. A pool that exists but sees no trading is not a venue, it is an entry in a database.
Once you have the list, the useful attributes for each are the program it runs on, the quote asset it pairs against, and the depth available at the current price. The measured cost characteristics of each Raydium program are covered in Raydium CLMM vs CPMM; this page is about choosing between pools once you know how the programs differ.
| Program | Sampled tx | Failure rate | Median fee | Cost per landed swap |
|---|---|---|---|---|
| Raydium AMM v4 low sample | 10 | 80% | 12,604 | 63,020 |
| Raydium CLMM low sample | 49 | 65.3% | 10,570 | 30,461 |
| Raydium CPMM low sample | 16 | 56.3% | 5,129 | 11,737 |
SOL pairs against USDC pairs
The practical difference is where price discovery happens. If the SOL pair carries the depth and the trading, that is the pool whose price everything else follows. Activity in a thin USDC pool does not move that reference and is often reported separately or not at all.
There is a second consideration specific to campaigns. Trading against SOL means your own fleet is holding and spending SOL, which is what it already needs for fees. Trading against USDC adds a conversion step for every wallet, more transactions, more failure surface, and more complexity in balance management for no benefit unless the USDC pair is genuinely the main market.
The rare case where the USDC pair is primary does exist, usually for tokens with an established userbase rather than newly launched ones. The test is the same either way: which pool actually carries the trading.
Testing depth instead of reading TVL
This test replaces reading a TVL figure, which on concentrated pools can be almost unrelated to whether a swap will succeed. Liquidity parked in ranges the pair is not trading in counts toward the total and is unavailable to you.
- Smooth and shallow across all three means the pool is usable at your size with room to spare.
- Bends below your intended size means size down or pick another pool. Trading past the bend generates price movement, not volume.
- Impact even on the smallest test means the pool is thin here regardless of headline figures, and a campaign will move the price rather than the chart.
Worth repeating rather than doing once, since providers rebalance and depth changes through the day. A pool that passed in the morning can fail in the evening after a move.
Why the biggest pool is often the wrong choice
The nuance is that these are two different goals that pull in opposite directions. Not moving the price is desirable, because a campaign that visibly pushes price is both expensive and obvious. Producing no visible effect at all is not the objective either.
The resolution is that the pool to choose is the one where trading actually happens, at a trade size that does not move the price. That combination gives you activity recorded where observers are looking, without the price distortion that comes from oversizing in a thin pool. Depth and attention together, rather than depth alone.
What a chart actually reflects, and why transaction count matters more than notional size, is in makers versus volume.
The new pool trap
This matters most right after a token graduates or when someone creates an additional pool on another program. The pool exists, it appears in interfaces, and it has almost no usable depth. A campaign pointed at it will produce a chart that moves violently on small trades, which is the opposite of the intended effect.
The same caution applies to settings derived immediately after creation. Depth changes quickly in the early hours, so a trade size that was appropriate at creation may be far too cautious a day later, or far too aggressive if liquidity was pulled instead.
What changes at the graduation boundary specifically is covered in what changes the day your token migrates.
When more than one pool qualifies
Splitting a campaign across two pools is occasionally suggested and is usually a mistake for the same reason aggregated split routing is: it divides the effect. Two half-strength patterns in two places is generally worse than one coherent pattern in the place that matters.
The exception is a token whose liquidity is genuinely fragmented with no dominant venue, which does happen as tokens mature and market makers provide in several places. There, concentrating everything in one pool creates an imbalance that arbitrage will trade against, and spreading is correct.
Selecting a venue is not something you have to do by hand: entering a token address in the dashboard resolves the pool from on-chain depth on every campaign rather than once at setup. What you control is trade size, interval and tolerance. Modelling the cost first is what the calculator is for, and the reasoning behind routing by measured depth rather than by quoted price is explained on the page for our measured Solana volume bot.