Skip to main content

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.

​
One-paragraph summary

CPMM — Constant Product Market Maker, officially the “Standard AMM” in Raydium’s UI — is a native Solana implementation of the classic x · y = k AMM. No OpenBook order book, no Serum legacy, no external dependencies beyond SPL Token and Token-2022. Every pool is a triple of (two token vaults, one LP mint) governed by a program-owned authority PDA, priced by the product of the vault balances. It is the AMM Raydium recommends for all new constant-product pools, and it is what the /pools/create endpoint and the web UI’s “Create pool” flow target by default.

​
What CPMM gives you

  • Token-2022 with a vetted extension allow-list. CPMM does not accept arbitrary Token-2022 mints. The program enforces a whitelist of safe extensions at pool creation: TransferFeeConfig, MetadataPointer, TokenMetadata, InterestBearingConfig, and ScaledUiAmount. Any other extension on the mint causes Initialize to reject with NotSupportMint — unless the mint itself is on a small hard-coded mint allow-list maintained in the program (used to onboard specific mints case-by-case). Transfer fees in particular affect swap math and are applied on the correct side of the trade — see algorithms/token-2022-transfer-fees.
  • Predictable fees. Each pool references an AmmConfig selected at creation. The config carries a trade-fee rate (split between LPs, protocol, and fund) and a separate, independent creator-fee rate. The creator fee is its own bucket — never a slice of the trade fee. Pools opt into charging it at creation. Defaults and the full split math are in products/cpmm/fees.
  • On-chain TWAP via an observation ring buffer. Every swap updates an observation account. External contracts can read a cumulative-price observation to compute a TWAP without a custom oracle.
  • Flat account layout. A pool is fully described by six PDAs (authority, pool state, LP mint, two vaults, observation). No per-market OpenBook account, no event queue, no request queue. Transactions are cheaper in both compute and account count than AMM v4.
  • Burn-and-earn compatible. LP tokens can be locked under the LP Lock program so the pool creator can keep claiming fees without retaining the right to withdraw liquidity. Used for “permanent” liquidity launches.

​
What CPMM is not

  • Not concentrated. Liquidity is spread evenly across the whole price range, like Uniswap v2. If you need capital-efficient market making — i.e., concentrating liquidity near the current price — use CLMM.
  • Not hybrid. Unlike AMM v4, CPMM pools do not place resting orders on an OpenBook market. Routing across CPMM pools happens through the AMM Routing program, not through a CLOB.
  • Not launchable for arbitrary curves. The curve is hard-coded to constant product. If you want a bonding curve for a token launch, use LaunchLab, which graduates to a CPMM pool when it fills.

​
How CPMM differs from AMM v4

DimensionAMM v4CPMM
CurveConstant productConstant product
OpenBook dependencyInert (originally placed orders on an OpenBook market; integration deactivated)No
Token-2022 supportNo (SPL Token only)Yes (including transfer fees)
Account count per V2 swap~9~11
Compute units per swap~80k–120k (V2 path)~60k–100k
TWAP oracleNo native oracle accountobservation ring buffer
New pool creation todayNot the default (program still accepts it)Default
StatusFully operationalActive, recommended
A deeper treatment of the migration story is in protocol-overview/versions-and-migration.

​
Mental model

A CPMM pool is a program-owned object holding three balances: vault0 (token0), vault1 (token1), and the supply of the LP mint. The LP mint’s supply tracks depositors’ claim on the pool; the token vaults hold the actual assets. Everything else — the authority PDA, the observation account, the fee-config pointer — is bookkeeping to make that three-variable relationship tradable, fee-collecting, and observable. Every user-facing operation collapses to a well-defined state transition:
  • Deposit: transfer token0 and token1 in, mint LP to user, no change to price.
  • Withdraw: burn LP from user, transfer token0 and token1 out in the pool’s current ratio, no change to price.
  • Swap: transfer one token in, transfer the other out; the ratio moves along the x · y = k curve (minus fees); the observation account samples the new price.
Fee collection (CollectProtocolFee, CollectFundFee) is a separate transaction signed by the respective authority; it does not happen on every swap. The math is spelled out in products/cpmm/math and the instruction set in products/cpmm/instructions.

​
When to choose CPMM

Pick CPMM when:
  • You are launching a new token or a new pair and do not have strong opinions about which range will see trading.
  • One or both of the tokens uses Token-2022 extensions.
  • You want a simple fee-per-trade model over a dynamic, tick-based one.
  • You are integrating and want to route through Raydium without taking on the complexity of CLMM positions.
Prefer CLMM when:
  • The pair is stable or highly correlated (stablecoin-stablecoin, LST-SOL) and you want to concentrate liquidity around parity.
  • You are a market-making team willing to actively manage ranges for higher fee APR per dollar of TVL.
Prefer AMM v4 when:
  • You are migrating existing AMM v4 tooling and are not creating a new pool.
(Note: AMM v4’s OpenBook hybrid mode is no longer active — that’s not a reason to choose AMM v4 anymore.)

​
Where to go next

  • Accounts — the six PDAs of a CPMM pool and how to derive them.
  • Math — SwapBaseInput vs SwapBaseOutput, Token-2022 transfer-fee handling, observation updates.
  • Instructions — the complete instruction surface with account lists.
  • Fees — the four-way fee split and how to collect.
  • Code demos — runnable TypeScript snippets for create / swap / deposit / withdraw.
Sources: