CPMM 數學

本頁內容由 AI 自動翻譯，所有內容以英文版本為準。查看英文版 →

不變量

CPMM 在其兩個金庫上維持經典的常數乘積不變量：

x \cdot y = k

其中 x 是金庫 0 的餘額（在收到時扣除任何 Token-2022 轉帳費用之後），y 亦然。每次交換必須在計入分配給 LP 的交易費用後保持 k' ≥ k（協議、基金和創作者的費用桶不計入 k — 它們位於金庫中但被曲線視圖排除，見下方的曲線上的費用）。因此，隨著 LP 累積費用，k 會隨著時間單調增長。 LP 份額由池的儲備金定價，而不是由 k 定價：

\text{LP 在 token0 中的價格} = \frac{x}{\text{lpSupply}}, \qquad \text{LP 在 token1 中的價格} = \frac{y}{\text{lpSupply}}

燒毀 ΔLP 個 LP 代幣會返回恰好 ΔLP × x / lpSupply 的 token0 和 ΔLP × y / lpSupply 的 token1。曲線和 k 在存入或提取時都不會移動 — 只有交換會改變價格。

交換路徑上的費用模型

CPMM 在每次交換上應用兩個獨立計費的費用：

交易費用在輸入端收取，按 AmmConfig.trade_fee_rate 計費。然後將其分為 LP、協議和基金份額（LP 份額保留在金庫中並增長 k；協議和基金份額從金庫會計中提取）。
創作者費用（僅當 enable_creator_fee == true 時有效）按 AmmConfig.creator_fee_rate 計費。它在輸入端或輸出端收取，取決於 PoolState.creator_fee_on 和交換方向（見products/cpmm/fees）。它是自己的費用桶 — 永遠不是交易費用的一部分。

協議對創作者費用的份額不會出現在本頁的任何地方，這是有意的。 它在 CollectCreatorFee 在曲線已經排除的兩個計數器之間移動累積費用時應用 — 而不是在交換期間。交換數學、報價和 k 無論有無它都是相同的。見products/cpmm/fees。

設：

FEE_RATE_DENOMINATOR = 1_000_000
trade_fee_rate — 來自 AmmConfig，例如 2500 = 相關交易量端的 0.25%
creator_fee_rate — 來自 AmmConfig，例如 1000 = 相關交易量端的 0.10%
protocol_fee_rate、fund_fee_rate — 以 1/FEE_RATE_DENOMINATOR 交易費用的單位計，而不是交易量

當創作者費用在輸入端時：

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

當創作者費用在輸出端時：

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

在兩種情況下，交易費用的分割方式相同：

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 在此不被扣除

protocol_fee + fund_fee + creator_fee 的金額保留在金庫中，但在池狀態上單獨追蹤（protocol_fees_token*、fund_fees_token*、creator_fees_token*）。當常數乘積不變量檢查 k' ≥ k 時，它使用金庫餘額減去所有三個累積但未清掃的費用 — 因此 LP 只捕獲 lp_fee。見products/cpmm/fees了解收集指令和詳細的數值示例。

SwapBaseInput（輸入精確）

「用戶給我們恰好 amount_in 的輸入代幣，並接收至少 minimum_amount_out 的輸出代幣。」暫時忽略 Token-2022：

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

通過代數：

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

其中 Δx_net = amount_in_after_trade_fee。程序隨後更新金庫會計，使得 trade_fee 中欠協議/基金/創作者的部分位於「累積」費用桶中（不包括在曲線的下一個 x 中），而 LP 份額確實加入 x 用於下一次交換。

Token-2022 在輸入端

如果輸入代幣有轉帳費用擴展，代幣在從用戶轉帳到金庫時扣除其費用。因此金庫實際接收 amount_in − transfer_fee_in(amount_in)。CPMM 程序因此計算：

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

並針對 amount_in_after_trade_fee 運行曲線。這很重要，因為曲線價格是根據實際進入金庫的淨金額計算的，而不是根據用戶的標題金額。

Token-2022 在輸出端

如果輸出代幣有轉帳費用，池從其金庫向用戶發送 amount_out。代幣隨後會在途中扣除其費用，因此用戶接收 amount_out − transfer_fee_out(amount_out)。程序照常從曲線計算 amount_out，但當顯示報價時，集成商有責任將池的「金庫發送」數字轉換為「用戶接收」數字。

滑點檢查

計算 amount_out 後：

require(amount_out >= minimum_amount_out, "AmountSpecifiedLessThanMinimum")

如果輸出代幣收取轉帳費用，SDK 在設置 minimum_amount_out 之前應用轉帳費用，因此滑點常數以用戶實際接收的金額計，而不是金庫發送的金額。

SwapBaseOutput（輸出精確）

「用戶將恰好接收 amount_out 的輸出代幣，並願意支付最多 maximum_amount_in 的輸入代幣。」反轉曲線以求 Δx_net：

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

向上取整很重要 — 它保證在整數截斷後 k' ≥ k。然後：

// 從淨輸入反向計算到總輸入。
// 費用應用於總輸入，所以：
//   net = gross − ceil(gross * rate / D)
//       ≈ gross * (D − rate) / D
// 在正確的地方用向上取整反轉：
gross_needed = ceil(Δx_net * D / (D − trade_fee_rate))

在 Token-2022 輸入上，包裝為：

gross_needed_before_mint_fee
  = inflate_for_transfer_fee(gross_needed, input_mint)

以便用戶支付足夠的金額，使得在代幣的轉帳費用扣除後，池仍然接收 gross_needed。

滑點檢查

require(gross_needed_before_mint_fee <= maximum_amount_in, "AmountSpecifiedExceedsMaximum")

詳細示例

池狀態，忽略 Token-2022：

x = 1_000_000_000_000（1,000,000.000000 的 token0，6 位小數）
y = 2_000_000_000_000（2,000,000.000000 的 token1，6 位小數）
AmmConfig：trade_fee_rate = 2500、protocol_fee_rate = 120_000、fund_fee_rate = 40_000、creator_fee_rate = 0

用戶：SwapBaseInput，amount_in = 1_000_000_000（1,000.000000 的 token0）。創作者費用已禁用（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                                              // 已禁用

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_993_011_971

new_vault0_raw   = x + amount_in                                        = 1_001_000_000_000
new_vault1       = y − amount_out                                       = 1_998_006_988_029

// 在金庫 0 中接收的 1_000_000_000 中，400_000 是「累積費用」
// （協議 + 基金），曲線應該排除：
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_004_196_E24  ≥  k = 2.0E24   ✓

如果同一個池有 enable_creator_fee = true，creator_fee_rate = 1000（0.10%）在輸入端，程序會收取 total_input_fee = ceil(1_000_000_000 * 3500 / 1_000_000) = 3_500_000，然後將其分為 creator_fee = 1_000_000 和 trade_fee = 2_500_000。trade_fee 上的協議/基金/LP 算術與上面的示例相同 — 創作者費用是自己的費用桶，累積到 creator_fees_token0 並與協議和基金費用桶一起從 curve_x 中排除。如果輸入代幣有 1% 的 Token-2022 轉帳費用，金庫接收 990_000_000 個代幣而不是 1_000_000_000，所有後續計算都使用該淨金額。

觀察更新規則

在每次交換時，程序評估是否應將新觀察推送到環形緩衝區：

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';
}

兩個特性：

累積價格，而不是現貨價格。 單個觀察不是價格。要從時間 t0 到 t1 獲得 TWAP，讀取最接近每一端的觀察，並計算 (cumulative(t1) − cumulative(t0)) / (t1 − t0)。
樣本受速率限制。 同一個槽中的連續交換可能共享一個觀察。在交換後立即讀取觀察可能看起來陳舊一個槽 — 這是正常的。

更多內容見products/clmm/accounts。

曲線上的費用

這是微妙的部分，值得特別說明。曲線算術針對淨金庫餘額工作 — 即原始 SPL 餘額減去累積的協議、基金和創作者費用（所有三個都是獨立的費用桶 — 見products/cpmm/fees）。一個具體的圖景：

raw_vault_balance   = RPC getTokenAccountBalance 返回的內容
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

對集成商的影響：

不要從原始餘額報價。 先減去累積費用欄位，或調用 SwapBaseInput 作為模擬並取其返回值。
CollectProtocolFee 將代幣移出金庫。 收集後，raw_vault_balance 下降，但 curve_balance 保持不變；池的價格不會移動。這是有意的。

精度和溢出

所有曲線算術使用 u128 中間值以防止 x * y 上的溢出。
除法向零舍入，除了 SwapBaseOutput 的 Δx_net（向上舍入）和費用計算（在 trade_fee 上向上舍入，在子分割上向下舍入）。這些舍入方向被選擇以確保不變量由於整數截斷而永遠不會減少。
具有極端金庫比率（數十億：1）的池可能在小交易上達到精度下限；程序在這種情況下返回 ZeroTradingTokens。見reference/error-codes。

接下來去哪裡

products/cpmm/fees — 完整的費用層級和收集語義。
products/cpmm/instructions — 調用此數學的指令。
algorithms/constant-product — x · y = k 的推導和邊界情況，在 AMM v4 和 CPMM 中共享。

來源：

raydium-io/raydium-cp-swap — states/curve.rs 中的交換數學
Raydium 審計報告連結在security/audits

產品

演算法

不變量

交換路徑上的費用模型

SwapBaseInput（輸入精確）

Token-2022 在輸入端

Token-2022 在輸出端

滑點檢查

SwapBaseOutput（輸出精確）

滑點檢查

詳細示例

觀察更新規則

曲線上的費用

精度和溢出

接下來去哪裡

​不變量

​交換路徑上的費用模型

​SwapBaseInput（輸入精確）

​Token-2022 在輸入端

​Token-2022 在輸出端

​滑點檢查

​SwapBaseOutput（輸出精確）

​滑點檢查

​詳細示例

​觀察更新規則

​曲線上的費用

​精度和溢出

​接下來去哪裡

不變量

交換路徑上的費用模型

SwapBaseInput（輸入精確）

Token-2022 在輸入端

Token-2022 在輸出端

滑點檢查

SwapBaseOutput（輸出精確）

滑點檢查

詳細示例

觀察更新規則

曲線上的費用

精度和溢出

接下來去哪裡