> ## 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.

# CPMM overview

> What Raydium's CPMM (Standard AMM) is, what makes it different from AMM v4, and when to pick it.

## One-paragraph summary

CPMM — **C**onstant **P**roduct **M**arket **M**aker, 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`](/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`](/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](/reference/program-addresses) 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](/products/clmm).
* **Not hybrid.** Unlike [AMM v4](/products/amm-v4), CPMM pools do not place resting orders on an OpenBook market. Routing across CPMM pools happens through the [AMM Routing](/reference/program-addresses) 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](/products/launchlab), which graduates to a CPMM pool when it fills.

## How CPMM differs from AMM v4

| Dimension                 | AMM v4                                                                          | CPMM                              |
| ------------------------- | ------------------------------------------------------------------------------- | --------------------------------- |
| Curve                     | Constant product                                                                | Constant product                  |
| OpenBook dependency       | Inert (originally placed orders on an OpenBook market; integration deactivated) | No                                |
| Token-2022 support        | No (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 oracle               | No native oracle account                                                        | `observation` ring buffer         |
| New pool creation today   | Not the default (program still accepts it)                                      | Default                           |
| Status                    | Fully operational                                                               | Active, recommended               |

A deeper treatment of the migration story is in [`protocol-overview/versions-and-migration`](/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`](/products/cpmm/math) and the instruction set in [`products/cpmm/instructions`](/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](/products/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](/products/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](/products/cpmm/accounts) — the six PDAs of a CPMM pool and how to derive them.
* [Math](/products/cpmm/math) — `SwapBaseInput` vs `SwapBaseOutput`, Token-2022 transfer-fee handling, observation updates.
* [Instructions](/products/cpmm/instructions) — the complete instruction surface with account lists.
* [Fees](/products/cpmm/fees) — the four-way fee split and how to collect.
* [Code demos](/products/cpmm/code-demos) — runnable TypeScript snippets for create / swap / deposit / withdraw.

Sources:

* [Raydium CP-Swap source — `raydium-io/raydium-cp-swap`](https://github.com/raydium-io/raydium-cp-swap)
* [`reference/program-addresses`](/reference/program-addresses) for canonical program IDs