Versions and migration

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Status at a glance

The single most consequential takeaway from this table: AMM v4 is not deprecated, and CPMM is the new default — but they coexist deliberately. AMM v4 pools have years of trading history and are not being forcibly migrated. The choice of which program to launch a new pool on is a recommendation, not a constraint.

​

AMM v4 — status and trajectory

AMM v4 is the original Raydium pool design: constant-product pricing (x · y = k). It launched as a hybrid AMM with an OpenBook (formerly Serum) orderbook integration that mirrored portions of the curve as limit orders on a bound market. The OpenBook integration has since been deactivated — pools no longer share liquidity to OpenBook and all swaps execute purely against the curve via the V2 swap entrypoints. AMM v4 today is, in practice, a pure constant-product AMM with the OpenBook accounts preserved as inert state.

​

What’s frozen

• No more new fee tiers. The AMM v4 fee structure is per-pool and was set at deploy. New pools accept the same hardcoded ~0.25% trade fee, ~12% to protocol.
• No new feature work. The team has not added new instructions to AMM v4 since CPMM became the new default. The program is in stewardship mode — bug fixes only, no scope expansion.
• No Token-2022 support. AMM v4 was written before Token-2022 existed and the integration was never retrofitted. Token-2022 mints have to use CPMM (or CLMM, where appropriate).
• OpenBook integration deactivated. Every AMM v4 pool is still bound to a corresponding OpenBook market account on-chain, but the pool no longer posts or maintains orders on that market. An OpenBook outage no longer affects AMM v4 swaps.

​

What’s still working

• Existing pools trade normally. No state migration was forced; v4 pools created in 2021 are still the active venue for many high-volume pairs in 2026.
• LPs can deposit, withdraw, and harvest farm rewards as usual. Migration to CPMM is opt-in.
• Aggregators still route through it. Jupiter and the Raydium Trade API both index v4 pools as first-class venues.

​

When to still use AMM v4

Honestly: rarely. The cases where v4 is the better answer are narrow:

• The pair already has a deep, well-traded v4 pool and you want to add liquidity to existing depth rather than splitting a market.

(OpenBook-integrated routing is no longer a reason to choose AMM v4 — that integration is off.) In every other case, launch new pools on CPMM. See user-flows/choosing-a-pool-type for the full decision tree.

​

CPMM — adoption curve and the v4 → CPMM migration

CPMM (constant-product market maker, internal name raydium-cp-swap) was deployed in 2024 as a clean-room rewrite intended to be the new default constant-product pool. It is structurally the simplest of Raydium’s programs: pure x · y = k, no orderbook, native Token-2022 support, smaller transaction footprint.

​

What CPMM gets you over AMM v4

• Better LP economics by default. CPMM’s default AmmConfig routes 100% of trade fees to LPs (with the protocol fee toggleable per-tier). AMM v4 hardcodes ~12% to protocol.
• Lower pool-creation cost. No OpenBook market needed. Creation is one transaction, ~0.15 SOL of rent vs ~0.6 SOL for v4.
• Token-2022. Transfer-fee mints, transfer-hook mints (with caveats), confidential transfers — all supported on CPMM, none on v4.
• Cleaner integrator surface. CPMM has an Anchor-CPI-friendly published crate (raydium-cp-swap), a simpler account list, and a stable IDL. AMM v4 ships an IDL but never had a maintained Rust CPI crate.
• Smaller account list per swap. ~10 accounts vs ~17 for v4 (which carries the OpenBook market accounts even when not hitting them).

​

When migration is worth it

For an actively traded pool, the LP-fee uplift alone usually justifies migration within a few months. The arithmetic: a pool earning 0.25% × $X daily volume gives 0.03% to protocol on v4 (the missing 12%). On CPMM that returns to LPs. Over a year, that compounds meaningfully. For a low-volume pool, migration is more about future-proofing — better defaults, Token-2022 support if you ever need it, easier integrations.

​

How migration works

There is no in-place upgrade. Migration is a create-new-pool, drain-old-pool, refill-new-pool sequence. The full step-by-step is in user-flows/migrate-amm-v4-to-cpmm; the high-level shape:

1. Create a new CPMM pool for the same pair, on the same fee tier you want to preserve.
2. Coordinate LPs: announce a window during which the old pool is drained and the new pool seeded.
3. Each LP withdraws from the v4 pool and deposits into the new CPMM pool.
4. (Optional) Set up a CPMM-side farm to attract incentivized LPs to the new pool.
5. Watch volume migrate as aggregators reweight toward the deeper pool.

The chain itself doesn’t enforce any of this — Raydium’s API and frontend simply favor whichever pool is deeper, and aggregators route through whichever is cheapest to the user.

​

CLMM — single program, stable across versions

CLMM is on its first program version. There has been no v2 — improvements have shipped as in-place upgrades to the same program ID (behind the 24h timelocked multisig), not as a new generation. That means there is no CLMM migration story: existing positions stay where they are, and the program’s behavior may change subtly when an upgrade ships, but the account layouts and PDAs are stable. What has changed across CLMM upgrades:

• SwapV2 instruction added to support Token-2022 transfer-fee math correctly. Old Swap is still callable; new integrations should target SwapV2.
• Reward stream extensions — the RewardInfo slot count was bumped (the original 3 → still 3 currently, but the reservation pattern was tightened). No data migration needed.
• Tick-array compaction — internal optimization to reduce CU on swap-crossing-many-ticks. Externally invisible.

The IDL lives in the dedicated raydium-idl repository (see sdk-api/anchor-idl). If you are running an older SDK against the current program, the worst case is missing the new instructions.

​

Farm v3 → v5 → v6

Of all Raydium programs, Farm has the most explicit version history and the only forced migration path. The three generations are separate programs with separate program IDs and separate state layouts.

​

Generations

​

Why three generations exist

• v3 → v5: needed multiple concurrent reward streams (e.g., dual-incentive farms). v3’s single-stream design couldn’t support it without a redesign.
• v5 → v6: v5’s u64 integer emission rate caps the minimum expressible rate at “1 token-unit per second.” For a 9-decimal mint, that’s 1 lamport/sec — far too coarse for low-emission programs. v6’s Q64.64 fractional rate fixes this. v6 also lifted the slot-based update to wall-clock, and added Token-2022 support.

​

What stays the same across generations

• The “deposit LP, accrue per-share counter, claim on withdraw” accounting pattern is identical across v3/v5/v6. The math doesn’t change; only the precision of the rate counter and the number of supported streams.
• UserStake (v3/v5) and UserLedger (v6) are conceptually the same record, with different layouts. The SDK normalizes both.

​

Migration path

There is no in-place migration between farm versions. To move from v3/v5 to v6:

1. Wait for the existing farm’s emissions to end (or run them down).
2. Stakers withdraw and claim pending rewards on the old farm.
3. The farm operator creates a new v6 farm against the same staking mint.
4. Stakers re-stake into the new farm.

The on-chain reality is two unrelated farm accounts. A user with stake in both has two UserLedger (v6) / UserStake (v5) records.

​

What “wind-down” means for v3 and v5

• The v3 and v5 programs are still deployed and callable. Existing farms can still distribute pending rewards and accept withdrawals.
• The Raydium UI still surfaces v3 and v5 farms with active rewards; once a v3/v5 farm’s end_time passes, the UI hides it from “active” but keeps it claimable.
• The team will not create new v3/v5 farms. SDK helpers for “create farm” route to v6 only.
• v3 and v5 are receiving security upgrades but not feature work. If a critical bug is found, it is fixed; if a feature could be useful, it is added to v6 instead.

Full detail per version is in products/farm-staking/accounts and products/farm-staking/instructions.

​

LaunchLab — single program, evolving config

LaunchLab is on its first program version. Like CLMM, improvements ship as in-place upgrades behind the 24h timelock — not as new generations. What has evolved through upgrades:

• Creator-fee slot. Added so launches can route a portion of post-graduation CPMM trading fees to the original creator. See products/launchlab/creator-fees.
• Curve-formula configurability. Originally hardcoded quadratic; now the LaunchConfig selects from a small set of curve shapes.

Existing LaunchLab launches are not affected by upgrades — once a launch is initialized, its parameters are frozen until graduation.

​

Cross-program version compatibility

A few cross-product compatibility notes integrators routinely hit:

• CLMM SwapV2 is not the same instruction as Swap. If your client speaks Swap only, it will silently mishandle Token-2022 transfer fees — the math is wrong by the fee amount. Update to SwapV2.
• Farm v6 staking with CLMM positions is not supported the way LP-token staking is. CLMM positions are NFTs, not fungible LP tokens. CLMM has its own native reward mechanism instead — see products/clmm/fees.
• CPMM pools backed by Token-2022 mints work in farms only on Farm v6. v3 and v5 reject Token-2022 staking mints.
• AMM v4 pools never have Token-2022 LP mints. If you see one, it’s a fake — AMM v4 doesn’t support that combination.

​

Where to read more

• introduction/history-and-milestones — the chronological release timeline and why each version landed when it did.
• user-flows/migrate-amm-v4-to-cpmm — the operator runbook for the v4 → CPMM move.
• user-flows/choosing-a-pool-type — decision tree for new pool deployments.
• products/farm-staking/accounts — side-by-side schema for v3 / v5 / v6.
• reference/changelog — what has changed in this documentation as program versions have evolved.

Sources:

• Per-product chapter pages cited inline above.
• Raydium SDK v2 — version-aware dispatch logic confirms which program a given pool belongs to.
• reference/program-addresses — canonical IDs per version.