CPMM math

The constant-product invariant, SwapBaseInput vs SwapBaseOutput, Token-2022 transfer-fee handling, and how the observation account is updated.

The invariant

CPMM maintains the classic constant-product invariant on its two vaults:

$$x \cdot y = k$$

where x is the vault0 balance after any Token-2022 transfer fees on receipt, and similarly for y. Every swap must leave k' ≥ k after accounting for trade fees credited to the LP (the protocol, fund, and creator buckets are not counted toward k — they sit in the vault but are excluded from the curve view, see Fees on the curve below). k therefore grows monotonically over time as LPs accrue fees.

LP shares are priced by the pool’s reserves, not by k:

$$\text{LP price in token0} = \frac{x}{\text{lpSupply}}, \qquad \text{LP price in token1} = \frac{y}{\text{lpSupply}}$$

Burning ΔLP LP tokens returns exactly ΔLP × x / lpSupply of token0 and ΔLP × y / lpSupply of token1. Neither the curve nor k moves on deposit or withdrawal — only swaps change the price.

Fee model on the swap path

CPMM applies two independently-rated fees on every swap:

• The trade fee is taken on the input side, charged at AmmConfig.trade_fee_rate. It is then split into LP, protocol, and fund shares (the LP share stays in the vault and grows k; the protocol and fund shares are extracted from vault accounting).
• The creator fee (active only when enable_creator_fee == true) is charged at AmmConfig.creator_fee_rate. It is taken on the input side or the output side depending on PoolState.creator_fee_on and the swap direction (see products/cpmm/fees). It is its own bucket — never a slice of the trade fee.

Let:

• FEE_RATE_DENOMINATOR = 1_000_000
• trade_fee_rate — from AmmConfig, e.g., 2500 = 0.25% of the relevant volume side
• creator_fee_rate — from AmmConfig, e.g., 1000 = 0.10% of the relevant volume side
• protocol_fee_rate, fund_fee_rate — denominated in units of 1/FEE_RATE_DENOMINATOR of the trade fee, not of volume

When the creator fee is on the input side:

total_input_fee = ceil(amount_in * (trade_fee_rate + creator_fee_rate) / FEE_RATE_DENOMINATOR)
creator_fee     = floor(total_input_fee * creator_fee_rate / (trade_fee_rate + creator_fee_rate))
trade_fee       = total_input_fee - creator_fee
amount_in_after_fees = amount_in - total_input_fee

When the creator fee is on the output side:

trade_fee            = ceil(amount_in * trade_fee_rate / FEE_RATE_DENOMINATOR)
amount_in_after_fees = amount_in - trade_fee
amount_out_curve     = curve_output(amount_in_after_fees, ...)
creator_fee          = ceil(amount_out_curve * creator_fee_rate / FEE_RATE_DENOMINATOR)
amount_out           = amount_out_curve - creator_fee

In both cases the trade fee is split the same way:

protocol_fee   = floor(trade_fee * protocol_fee_rate / FEE_RATE_DENOMINATOR)
fund_fee       = floor(trade_fee * fund_fee_rate     / FEE_RATE_DENOMINATOR)
lp_fee         = trade_fee - protocol_fee - fund_fee     // creator_fee is NOT subtracted here

The protocol_fee + fund_fee + creator_fee amount is held in the vaults but tracked separately on the pool state (protocol_fees_token*, fund_fees_token*, creator_fees_token*). When the constant-product invariant checks k' ≥ k, it uses vault balances minus all three accrued-but-unswept fees — so LPs capture only lp_fee.

See products/cpmm/fees for the collection instructions and the worked numerical examples.

SwapBaseInput (input-exact)

“The user gives us exactly amount_in of the input mint and receives at least minimum_amount_out of the output mint.”

Ignoring Token-2022 for a moment:

amount_in_after_trade_fee = amount_in - trade_fee
amount_out                = y − (x * y) / (x + amount_in_after_trade_fee)

By algebra:

$$\text{amount\_out} = \frac{y \cdot \Delta x_{\text{net}}}{x + \Delta x_{\text{net}}}$$

where Δx_net = amount_in_after_trade_fee.

The program then updates the vault accounting such that the portion of trade_fee owed to protocol/fund/creator sits in “accrued” buckets (not included in the curve’s next x), while the LP share does join x for the next swap.

Token-2022 on the input side

If the input mint has a transfer-fee extension, the mint deducts its fee on the transfer from user → vault. So the vault actually receives amount_in − transfer_fee_in. The CPMM program therefore computes:

amount_actually_received = amount_in − transfer_fee_in(amount_in)
trade_fee                = ceil(amount_actually_received * trade_fee_rate / FEE_RATE_DENOMINATOR)
amount_in_after_trade_fee = amount_actually_received − trade_fee

and runs the curve against amount_in_after_trade_fee. This matters because the curve price is computed off the net amount that landed in the vault, not off the user’s headline amount.

Token-2022 on the output side

If the output mint has a transfer fee, the pool sends amount_out from its vault to the user. The mint will then skim its fee on the way out, so the user receives amount_out − transfer_fee_out(amount_out). The program computes amount_out from the curve as usual, but it is the integrator’s responsibility to convert the pool’s “vault send” number into a “user receive” number when showing quotes.

Slippage check

After computing amount_out:

require(amount_out >= minimum_amount_out, "AmountSpecifiedLessThanMinimum")

If the output mint charges a transfer fee, the SDK applies the transfer fee before setting minimum_amount_out so the slippage constant is denominated in what the user will actually receive, not in what the vault sends.

SwapBaseOutput (output-exact)

“The user will receive exactly amount_out of the output mint and is willing to pay up to maximum_amount_in of the input mint.”

Inverting the curve for Δx_net:

$$\Delta x_{\text{net}} = \left\lceil \frac{x \cdot \text{amount\_out}}{y - \text{amount\_out}} \right\rceil$$

The ceiling is important — it guarantees k' ≥ k after integer truncation. Then:

// Work backwards from the net in to the gross in.
// fee is applied on the gross, so:
//   net = gross − ceil(gross * rate / D)
//       ≈ gross * (D − rate) / D
// inverting with ceiling in the right places:
gross_needed = ceil(Δx_net * D / (D − trade_fee_rate))

On Token-2022 input, wrap with:

gross_needed_before_mint_fee
  = inflate_for_transfer_fee(gross_needed, input_mint)

so the user pays enough that after the mint’s transfer-fee deduction the pool still receives gross_needed.

Slippage check

require(gross_needed_before_mint_fee <= maximum_amount_in, "AmountSpecifiedExceedsMaximum")

Worked example

Pool state, ignoring Token-2022:

• x = 1_000_000_000_000 (1,000,000.000000 of token0, 6 decimals)
• y = 2_000_000_000_000 (2,000,000.000000 of token1, 6 decimals)
• AmmConfig: trade_fee_rate = 2500, protocol_fee_rate = 120_000, fund_fee_rate = 40_000, creator_fee_rate = 0

User: SwapBaseInput with amount_in = 1_000_000_000 (1,000.000000 of token0). Creator fee is disabled (enable_creator_fee = false).

trade_fee                = ceil(1_000_000_000 * 2500 / 1_000_000)       = 2_500_000
  protocol_fee           = floor(2_500_000 * 120_000 / 1_000_000)       = 300_000
  fund_fee               = floor(2_500_000 *  40_000 / 1_000_000)       = 100_000
  lp_fee                 = 2_500_000 − 300_000 − 100_000                 = 2_100_000
creator_fee              = 0                                              // disabled

amount_in_after_trade_fee = 1_000_000_000 − 2_500_000                    = 997_500_000

amount_out = y − (x * y) / (x + Δx_net)
           = 2_000_000_000_000
             − (1_000_000_000_000 * 2_000_000_000_000)
               / (1_000_000_000_000 + 997_500_000)
           ≈ 1_995_015_009

new_vault0_raw   = x + amount_in                                        = 1_001_000_000_000
new_vault1       = y − amount_out                                       ≈ 1_998_004_984_991

// Of the 1_000_000_000 received in vault0, 400_000 is "accrued fee"
// (protocol + fund) that the curve should exclude:
curve_x          = new_vault0_raw − (protocol_fees_token0 + fund_fees_token0)
                 = 1_001_000_000_000 − 400_000
                 = 1_000_999_600_000

k' = curve_x * new_vault1 ≈ 2.000_002_501_E24  ≥  k = 2.0E24   ✓

If the same pool had enable_creator_fee = true with creator_fee_rate = 1000 (0.10%) on the input side, the program would charge total_input_fee = ceil(1_000_000_000 * 3500 / 1_000_000) = 3_500_000, then split it as creator_fee = 1_000_000 and trade_fee = 2_500_000. The protocol/fund/LP arithmetic on trade_fee is unchanged from the example above — the creator fee is its own bucket, accrued to creator_fees_token0 and excluded from curve_x along with the protocol and fund buckets.

If the input mint has a 1% Token-2022 transfer fee, the vault receives 990_000_000 tokens instead of 1_000_000_000, and every subsequent calculation uses that net amount.

Observation update rule

On every swap, the program evaluates whether to push a new observation into the ring buffer:

let since_last = now − observations[head].block_timestamp;
if since_last >= MIN_OBSERVATION_INTERVAL {
    let price0 = (vault1 << 32) / vault0;            // Q32.32-ish
    let price1 = (vault0 << 32) / vault1;
    let head' = (head + 1) % OBSERVATION_NUM;
    observations[head'] = Observation {
        block_timestamp: now,
        cumulative_token0_price_x32:
            observations[head].cumulative_token0_price_x32 + price0 * since_last,
        cumulative_token1_price_x32:
            observations[head].cumulative_token1_price_x32 + price1 * since_last,
    };
    head = head';
}

Two properties:

• Cumulative price, not spot price. A single observation is not a price. To get a TWAP from time t0 to t1, read the observations closest to each end and compute (cumulative(t1) − cumulative(t0)) / (t1 − t0).
• Samples are rate-limited. Back-to-back swaps in the same slot may share one observation. Reading an observation immediately after a swap can therefore look stale by one slot — this is normal.

More in products/clmm/accounts.

Fees on the curve

This is the subtle part and worth calling out. The curve arithmetic works against the net vault balances — i.e., raw SPL balance minus accrued protocol, fund, and creator fees (all three are independent buckets — see products/cpmm/fees). A concrete picture:

raw_vault_balance   = what an RPC getTokenAccountBalance returns
accrued_fees        = protocol_fees_token{0,1} + fund_fees_token{0,1} + creator_fees_token{0,1}
curve_balance       = raw_vault_balance − accrued_fees
invariant           = curve_balance0 * curve_balance1

Consequences for integrators:

• Do not quote from raw balances. Subtract the accrued-fee fields first, or call SwapBaseInput as a simulation and take its return.
• CollectProtocolFee moves tokens out of the vault. After collection, raw_vault_balance drops but curve_balance is unchanged; the pool’s price does not move. This is deliberate.

Precision and overflow

• All curve arithmetic uses u128 intermediates to prevent overflow on x * y.
• Division rounds toward zero except for SwapBaseOutput’s Δx_net, which rounds up, and fee computation, which rounds up on the trade_fee and down on the sub-splits. These rounding directions are chosen so the invariant never decreases due to integer truncation.
• Pools with extreme vault ratios (billions : 1) may hit precision floors on small trades; the program returns ZeroTradingTokens in that case. See reference/error-codes.

Where to go next

• products/cpmm/fees — the full fee tier and collection semantics.
• products/cpmm/instructions — the instructions that invoke this math.
• algorithms/constant-product — the derivation and edge cases of x · y = k shared across AMM v4 and CPMM.

Sources:

• raydium-io/raydium-cp-swap — swap math in states/curve.rs
• Raydium audit reports linked in security/audits