Skip to main content
AMM v4’s OpenBook / Serum dependency has been removed (2026-07 program upgrade). Live swaps execute exclusively against the AMM curve. The MonitorStep crank, the order-book CPIs, and the market-making instructions have been removed from the program and now revert if called; the serum_dex dependency is gone. The v1 SwapBaseIn / SwapBaseOut, Deposit, and Withdraw instructions keep their old account layouts (the market accounts are still accepted positionally but are no longer validated or used). Treat AMM v4 today as a pure constant-product AMM; the hybrid material below is preserved for historical context. See the 2026-07-22 changelog entry.

​
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 dependency has since been removed from the program — 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 on v1 swaps. The legacy SwapBaseIn / SwapBaseOut layouts still carry the OpenBook market accounts as positional placeholders (they are accepted but no longer validated or used). Use SwapBaseInV2 / SwapBaseOutV2 to drop them and shrink the transaction.
  • Low compute usage. Even a V2 swap costs more than a CPMM swap.
  • Default new-pool flow. New pools are created with Initialize2 (the legacy Initialize / PreInitialize entrypoints have been removed and now revert). 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

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 has been removed. Operations are swap (user ↔ pool, via SwapBaseInV2 / SwapBaseOutV2) and deposit / withdraw (LP ops). The old crank (MonitorStep) has been removed and now reverts if called. 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: historically OpenBook outages or pauses could degrade AMM v4 pools (stale orders). With the OpenBook dependency now removed from the program, that coupling is gone — but CPMM remains the recommended, lower-cost default.
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 (now-vestigial) OpenBook reference fields.
  • Math — constant-product swap math with AMM v4’s fee convention.
  • Instructions — the instruction surface: Initialize2, Swap (v1 / V2), Deposit, Withdraw, WithdrawPnl, SetParams.
  • 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