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.

AMM v4 no longer shares liquidity to OpenBook. Pools have been switched off the hybrid orderbook-grid path; live swaps execute exclusively against the AMM curve via SwapBaseInV2 / SwapBaseOutV2. The MonitorStep crank, the on-chain limit-order grid, and the bound OpenBook market accounts remain in the program for backwards compatibility but are no longer maintained as an active liquidity source. Treat AMM v4 today as a pure constant-product AMM; the hybrid material below is preserved for context and for integrators reading older deployments.

​
One-paragraph summary

AMM v4 is the program Raydium launched with. It maintains a constant-product invariant (x · y = k). It was originally designed as a hybrid AMM: each pool sat on top of an OpenBook (formerly Serum) limit-order-book market and mirrored portions of its curve as limit orders on that book, so users and aggregators could swap directly against the pool (AMM path) or against the limit orders the pool owned on OpenBook (CLOB path). The OpenBook side has since been deactivated — pools no longer post or maintain orders on OpenBook, and all current swap traffic flows through the AMM-only V2 swap entrypoints. Token-2022 is not supported. AMM v4 is still fully operational as a constant-product AMM — every pool keeps trading, fees still accrue, LPs still earn — but the UI and SDK default new pool creation to CPMM because CPMM is cheaper and supports more mint types.

​
Hybrid history (context)

At launch, standing up a pool alongside Serum’s order book risked fragmenting liquidity. The hybrid design published the AMM’s curve onto the book as limit orders, so order-book routers saw the pool’s depth for free. After OpenBook forked Serum in late 2022, the program continued working against OpenBook with minimal changes. As CPMM and on-chain aggregators matured, the orderbook-side benefit faded, and AMM v4’s OpenBook integration was eventually turned off — the curve is now the pool’s only execution surface.

​
What AMM v4 gives you (that CPMM does not)

  • Deep liquidity for legacy pairs. Major pairs (SOL-USDC, mSOL-USDC, etc.) with large AMM v4 TVL remain the deepest venue for those trades.
(Historically, AMM v4 also offered orderbook-side visibility via the OpenBook hybrid mechanism, but that path is no longer active. Any integrator that previously routed through the AMM’s OpenBook orders should now route directly via the AMM swap entrypoints.)

​
What AMM v4 does not give you

  • Token-2022. Not supported. AMM v4 was written before Token-2022 existed; its account layouts presume classic SPL Token.
  • Low account count. A swap touches the pool, authority, vaults, plus the entire OpenBook event/request queue and bids/asks sides. Even a direct AMM swap (bypassing CLOB) drags all OpenBook accounts along because the instruction validates them.
  • Low compute usage. Account validation alone costs more than a full CPMM swap.
  • Default new-pool flow. The program is still functional and still accepts Initialize, but the Raydium UI, SDK, and api-v3.raydium.io no longer surface a “create AMM v4 pool” button — the default path for new pools is CPMM.

​
How AMM v4 differs from CPMM

DimensionAMM v4CPMM
CurveConstant productConstant product
OpenBook dependencyInert (originally yes; now disabled)No
Token-2022NoYes
Account count per V2 swap~9~11
Compute units per swap~80k–120k (V2 path)~60k–100k
LP fee0.22% of volumeVaries by AmmConfig
Protocol fee0.03% of volume (fixed)Varies by AmmConfig
Fund feeNoneYes
TWAP oracleNo native observation accountobservation ring buffer
Default for new poolsNo (still accepted)Yes
More detail on fees: products/amm-v4/fees and reference/fee-comparison.

​
Mental model

An AMM v4 pool today is a constant-product x · y = k AMM. Both vaults are entirely available to the curve — no fraction is committed to OpenBook orders, because the OpenBook integration is no longer active. Operations are swap (user ↔ pool, via SwapBaseInV2 / SwapBaseOutV2), deposit / withdraw (LP ops), and a now-vestigial crank (MonitorStep, retained on-chain but no longer needed and not posted by Raydium’s keeper). Historical mental model (pre-deactivation): a fraction of each vault was escrowed as open-book orders; settlement of filled orders happened during swap and LP operations; routed swaps could fill against the pool’s own OpenBook orders. None of this is in operation today. CPMM drops the OpenBook dependency. The tradeoffs:
  • CPMM transactions are 2×–3× cheaper in compute.
  • CPMM supports Token-2022 mints.
  • Aggregators now integrate CPMM directly via Raydium SDK, so the order-book-visibility benefit is largely moot.
  • Operational risk: OpenBook outages or pauses degrade AMM v4 pools (CrankError, stale orders). CPMM has no such coupling.
See protocol-overview/versions-and-migration for the migration guidance.

​
When AMM v4 is the right choice

  • You are routing a swap and one of the candidate pools is an AMM v4 pool with the best price.
  • You are providing or managing liquidity in an existing AMM v4 pool — migration is a choice, not required; the pool continues to function as a pure AMM.
  • You maintain an integration built against AMM v4 and have no reason to migrate.
(Order-book visibility on OpenBook is no longer a reason to pick AMM v4 — that integration is off.) For a fresh constant-product pool, CPMM is the simpler default.

​
Where to go next

  • Accounts — the AMM’s accounts plus the OpenBook accounts it serves.
  • Math — constant-product swap math with AMM v4’s fee convention.
  • Instructions — the instruction surface: Initialize, Swap, Deposit, Withdraw, crank helpers.
  • Fees — the 0.25% split and how it’s collected.
  • Code demos — TypeScript examples for swap and LP flows.
Sources:
  • reference/program-addresses for the canonical program ID
  • OpenBook program repository for the counterparty accounts this page references