Raydium AMM v4 vs CLMM: Which Pool Type to Bot in 2025

When you are building bots that route through Raydium AMM v4 vs CLMM, the two pool types are not interchangeable wrappers around the same math. They have different pricing curves, different fee structures, different on-chain account layouts, and — critically — different slippage behaviors under load. Getting this wrong costs you on every single trade.

The Core Mechanics: What Each Pool Actually Does

Raydium v4 is a constant-product AMM: x * y = k. The entire liquidity range from zero to infinity is always active. That means you always get a fill, depth is predictable as a function of the invariant, and price impact scales smoothly with swap size. The price before and after the swap is deterministic from the reserves alone — no tick math required.

Raydium CLMM (Concentrated Liquidity Market Maker) is a Uniswap v3 derivative implemented in Rust on Solana. Liquidity is deposited into discrete tick ranges, and a swap traverses those ticks one by one until the output amount is satisfied. The current active tick determines the spot price. If a swap crosses multiple ticks, it executes at different effective prices across each range — the final average is your fill price.

The distinction that matters for bots: v4 pools have continuous, predictable depth; CLMMs have fragmented depth that can shift sharply at tick boundaries.

Fee Tiers and When They Matter

Raydium v4 charges a flat 0.25% per swap, of which 0.22% goes to LPs and 0.03% to the protocol. There is no fee tier selection — you take it or leave it.

CLMMs on Raydium support multiple fee tiers: 0.01%, 0.05%, 0.25%, and 1%. The lowest tier (1 bps) is designed for stablecoin pairs where tight spreads matter. The 5 bps tier is competitive for blue-chip pairs like SOL/USDC. The 25 bps tier directly competes with v4 on mid-liquidity pairs.

For arbitrage bots, fee tier selection is path-dependent. If your arb route is v4 → CLMM, you pay 0.25% + the CLMM's tier. A 5 bps CLMM leg makes the combined cost 0.30%; a 25 bps leg makes it 0.50%. Your minimum profit threshold changes materially. Always model the full path cost before sizing your position.

Slippage Profiles Under Execution Load

This is where the behavior diverges most in production. In a v4 pool, slippage is a smooth function of the swap size relative to reserves. You can compute it precisely before submitting:

price_impact ≈ Δx / (x + Δx)

In a CLMM, slippage is a function of the liquidity distribution across ticks. In a well-concentrated pool near the spot price, you can get extremely tight fills — tighter than v4 for the same nominal TVL because more capital is deployed near the current price. But if the spot price has moved since you last queried the pool state and you are now crossing into a sparse tick range, slippage spikes sharply and unpredictably.

Practical implication: CLMM slippage estimates go stale faster than v4 estimates. For bots running at high frequency, the window between simulation and execution matters more on CLMMs. On a busy Solana slot with 50ms block times and validator-induced jitter, price can cross a tick boundary between your preflight simulation and your transaction landing. Your slippage tolerance setting needs to account for this — a setting of 50 bps that works on v4 may be too tight for a deep CLMM under volatile conditions.

On-Chain Account Structure and Compute Units

Reading pool state for routing decisions is not free. Both pool types require fetching specific accounts:

• v4 pools: one AmmInfo account holds reserves, fees, and status. A single getParsedAccountInfo call gives you everything you need to price a swap.
• CLMM pools: you need the PoolState account for base data, but you also need the TickArray accounts covering the swap range. A deep swap can traverse three or more tick arrays. Each is a separate account fetch, and each costs CUs to deserialize and iterate.

For a routing engine scanning dozens of pools simultaneously, this CU asymmetry adds up. v4 pools are cheaper to quote. CLMMs are cheaper to execute on (when liquidity is dense) but more expensive to simulate. If you are running a Solana MEV or arbitrage bot that evaluates hundreds of potential paths per second, the account-read overhead of CLMMs is a real constraint — you may need to cache tick arrays and invalidate on price movement rather than fetching fresh state on every evaluation.

Routing Logic: Which Pool Wins on a Given Trade

The answer depends on trade size and pair type. For any given pair where both pool types exist:

• Small swaps (< $1,000 notional): CLMM wins almost always. The concentrated liquidity means tighter spreads near the current price, and the lower fee tiers (0.01% or 0.05%) reduce costs significantly versus v4's fixed 0.25%.
• Large swaps (> $50,000 notional): v4 often wins or ties. The continuous liquidity curve means depth degrades gracefully. CLMMs can run out of in-range liquidity and cross into empty tick ranges, causing sudden price impact spikes that v4 never exhibits.
• Stablecoin pairs: Always prefer the CLMM 1 bps tier if one exists. The AMM v4 at 25 bps is uncompetitive here.
• New or thin pairs: v4 only. CLMMs for illiquid pairs often have tick arrays that are almost entirely empty, making them dangerous for automated execution.

Jupiter's routing engine makes this decision automatically and handles multi-hop paths across both pool types. But if you are building custom execution logic — for instance, a Solana sniper or arb bot that needs to bypass aggregators for latency reasons — you need to implement this decision tree yourself.

What This Means for Specific Bot Architectures

Snipers: New Raydium launches still default to v4. The migration path toward CLMM-native launches is ongoing but not complete. Your launch-detection logic must handle both pool types, and your buy simulation must branch correctly — the account layout for a v4 initialize2 instruction is different from a CLMM open_position.

Arbitrage bots: The most consistent edges appear in the spread between v4 and CLMM pools for the same pair. When a large swap moves the v4 price but the CLMM is slower to update (or the arbitrageur who moved v4 didn't close the CLMM leg), a brief window opens. These are typically sub-block windows closed by Jito bundle competition, but they are real and they occur on every major price move.

Market-making bots: Do not try to LP-manage a CLMM position from a bot without a robust rebalancing model. Out-of-range positions earn zero fees and create naked directional exposure. If you are building maker infrastructure on Raydium, v4 passive positions are simpler to model; CLMM positions require continuous tick management to stay productive.

---

If you are building execution infrastructure on Raydium and need the pool-type logic handled correctly in production — from account layout parsing to tick-aware slippage simulation — talk to us about a custom Solana bot build.