Raydium CLMM vs CPMM for a volume bot
Saying a token is "on Raydium" does not say much. Raydium runs three separate swap programs with different maths, different fee behaviour and noticeably different failure rates, and a volume campaign that treats them as interchangeable will overpay on at least one of them. This page explains what actually differs between AMM v4, CLMM and CPMM, shows what each one costs in a measured sample, and gives you a way to tell which pool your own pair is in before you commit a budget.
Raydium is three programs, not one
The distinction is not academic. It determines how much a given trade moves the price, how likely that trade is to fail, and what a sensible trade size looks like. Two tokens both described as "trading on Raydium" can behave completely differently under an identical campaign.
AMM v4 is the pool most people picture. Liquidity sits on a constant-product curve, depth is spread across the entire price range, and the pool can quote any price. It is predictable and forgiving, and it is also capital inefficient, which is why liquidity providers increasingly prefer the alternatives.
CLMM lets a provider concentrate their capital in a narrow band around the current price. That produces far better depth where trading actually happens, at the cost of leaving other prices uncovered. When price leaves the covered band, the pool behaves as though liquidity has vanished, because for that price it has.
CPMM returns to constant-product maths but removes the friction v4 carried. Creating a v4 pool required an OpenBook market, an expensive and slow step. CPMM pools can be created directly, and they support Token-2022 tokens that v4 cannot handle. For newly launched tokens this is increasingly the default landing spot.
What each Raydium program actually costs
| 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 |
One honest caveat before the numbers are used for anything: in the current window Raydium AMM v4 (10 transactions) and Raydium CLMM (49 transactions) and Raydium CPMM (16 transactions) had too few transactions to support a conclusion. A median computed from a handful of swaps is a description of those swaps, not of the program. We mark those rows rather than quietly presenting them as equivalent to the well sampled ones.
What is worth noticing is that the differences here are not driven by the fee. Base fees are identical everywhere on Solana at 5,000 lamports per signature. The gaps come from priority fees, which reflect how contested each program is, and from failure rates, which reflect how sensitive each design is to price movement between quote and execution.
The wider picture across all venues, not just Raydium, is on which Solana DEX is cheapest for a volume bot, and the full fee percentile distribution is on the measured transaction costs page.
Why concentrated liquidity fails more often
The failure mode is specific and worth understanding. You fetch a quote, the quote is computed against the liquidity currently in range, and between that moment and execution someone else trades, moving the price toward or past a range boundary. Your swap now needs liquidity that is not there at the price you signed for, so the slippage check rejects it.
This gets worse with trade size, and much worse on tokens whose providers have concentrated tightly. A tight range means excellent depth in normal conditions and a cliff edge just outside it. Aggregate TVL tells you nothing about where that edge is.
For a volume campaign the consequence is straightforward: on CLMM pools, smaller trades are not merely cheaper, they are more likely to land at all. This is one of the few places where the cautious setting and the cheap setting are the same setting.
Raising slippage tolerance masks the problem and creates another, because a wider tolerance is a wider window for someone to profit at your expense. That trade-off is covered in sandwich MEV protection.
When your token is on CPMM and what it means
For volume generation this is the friendliest of the three designs. There is no range to leave, so failures come only from genuine price movement, and price impact is a smooth function of trade size rather than a step at a boundary. Predictability is worth more to a campaign than the last few basis points of quoted price.
The catch is depth. A new CPMM pool often has thin liquidity simply because it is new and nobody has provided much yet. Constant-product maths handles thin liquidity gracefully in the sense that it never fails for structural reasons, but it will move the price hard on any trade that is large relative to the pool. Graceful failure is replaced by expensive success, which is worse if you are not watching for it.
So the rule for CPMM is the opposite of the rule for CLMM. On CLMM, size down to stay inside the range. On CPMM, size down to avoid moving the price. Same instruction, entirely different reason.
How to tell which pool your token is in
Three practical checks, in order of reliability:
- Read the program id from a real swap. Open a recent transaction for your pair and look at which program executed the swap. This is definitive, because names can be reused and aggregator interfaces hide the venue entirely.
- Check whether depth changes with price. Request quotes for several sizes. If price impact grows smoothly, you are on a constant-product pool. If it is flat and then jumps sharply, you are crossing a range or bin boundary and you are on a concentrated design.
- Check the token standard. Token-2022 tokens cannot be in a v4 pool at all, which narrows the answer immediately.
A token can have pools on several programs at once, and often does. In that case the question is not which pool exists but which one has real depth at the current price, since that is where volume will actually land. When you enter a token address in the dashboard, this resolution happens automatically: it finds where liquidity actually sits rather than asking you to choose a venue by name.
What this changes in a campaign
- Trade size. On CLMM, size to stay well inside the active range. On CPMM and v4, size to keep price impact invisible. Both point to smaller trades than most people start with, and smaller trades also produce more distinct transactions per SOL spent, which is what a chart actually reflects.
- Slippage. A tolerance that works on a deep v4 pool will fail constantly on a tightly concentrated CLMM pool. Set it from the pair's observed per-block movement, not from a number carried over from another token.
- Retries. A CLMM failure caused by leaving a range will repeat until the price returns or the range is rebalanced. Retrying immediately burns fees on a condition that has not changed. Backing off and re-quoting is cheaper.
- Timing. Concentrated pools are most fragile when price is moving fast, which is also when campaigns are most tempting to run. Running through genuine volatility on a CLMM pool is the most expensive combination available.
The relationship between transaction count and what a chart displays is covered in makers versus volume, and what all of this does to a budget is worked through in the cost breakdown. To put actual numbers against your own token, the calculator takes a target volume and returns cost at current measured rates.
So which one should you run volume on
In practice the choice is usually made for you, because liquidity is where it is and volume generated away from it moves the price instead of the chart. What you genuinely control is how you trade into whichever pool your token lives in, and that is where the measured differences above become actionable rather than academic.
The one decision that is genuinely yours arises when a token has meaningful depth on more than one Raydium program at once. Then, compare cost per landed swap rather than quoted fee, check depth at the current price rather than aggregate TVL, and prefer the constant-product pool when the two are close. That is the order our routing follows, using the same measured inputs published on this page rather than a fixed preference for one venue, and the reasoning behind it is set out on the Solana volume bot overview.
For the broader comparison across every venue we track, see which Solana DEX is cheapest for a volume bot. For Raydium-specific routing behaviour, see Raydium volume bot routing.