CLMM 指令

​

指令清單

​

CreatePool

sqrt_price_x64: u128           // 初始價格
open_time:      u64            // 此時間之前拒絕交換

• token_mint_0 < token_mint_1（按位元組順序）。
• amm_config.disable_create_pool == false。
• 鑄幣未被 Token-2022 擴展允許列表拒絕。

• pool_state.sqrt_price_x64 = sqrt_price_x64，tick_current = floor(log_{1.0001}(price))。
• pool_state.liquidity = 0（尚無頭寸）。
• pool_state.fee_on = FromInput（舊版預設）。
• pool_state.dynamic_fee_info 被清零（動態費用禁用）。

​

CreateCustomizablePool

pub struct CreateCustomizableParams {
    pub sqrt_price_x64:    u128,
    pub collect_fee_on:    CollectFeeOn,   // FromInput | Token0Only | Token1Only
    pub enable_dynamic_fee: bool,
}

• pool_state.fee_on 設置為選定的 CollectFeeOn 變體。
• 如果啟用了動態費用：pool_state.dynamic_fee_info 從提供的 DynamicFeeConfig 初始化（複製五個校準參數；狀態欄位清零）。
• 否則：pool_state.dynamic_fee_info 被清零（= 此池永遠不會啟用動態費用）。

​

CreatePermissionedPool

customizable_params: CreateCustomizableParams   // 與 CreateCustomizablePool 相同的結構
seed_index:          u16                          // 必須非零；折疊到池 PDA 種子中

• seed_index != 0。seed_index 為 0 保留給舊版池並在此被拒絕；[0, 0] 種子分量是使舊版池地址折疊為經典四種子形式的原因。
• payer 的 permission PDA 存在（由管理員通過 CreatePermissionPda 創建）。
• 與 CreatePool 相同的鑄幣/允許列表規則。

• 新的 pool_state 存在於 seed_index 派生的地址，pool_state.seed_index = seed_index。
• 所有其他後狀態與 CreateCustomizablePool 匹配（費用模式、可選動態費用）。

​

OpenPositionV2 / OpenPositionWithToken22Nft

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // 所需 L（或 0 以使用下面的金額）
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // 寫入 NFT 元數據（Metaplex）
base_flag: Option<bool>       // true = 適應 amount0；false = 適應 amount1

• tick_lower < tick_upper，都是 pool.tick_spacing 的倍數，在 [MIN_TICK, MAX_TICK] 內。
• 所需 tick 陣列已傳遞並初始化（或在交易中通過 InitTickArray CPI 創建）。
• 用戶在源 ATA 中至少有 amount_0_max 和 amount_1_max。

• personal_position 存在，liquidity 設置，fee_growth_inside_last 快照。
• Tick 陣列條目在 tick_lower 和 tick_upper 處更新（liquidity_gross += L，liquidity_net ± L，費用增長快照維護）。
• 如果頭寸在範圍內（tick_lower ≤ tick_current < tick_upper），pool_state.liquidity += L。
• 位置 NFT 鑄幣記錄 pool_state 作為凍結權限。鑄幣權限在單個 NFT 鑄造後被移除。記錄凍結權限不會改變 NFT 代幣帳戶的狀態。
• NFT 代幣帳戶保持未凍結，除非指令是 OpenPositionV2 或 OpenPositionWithToken22Nft 且任一保管庫鑄幣的凍結權限與 CLMM 的受限發行人列表匹配。只有該匹配的 V2 路徑凍結帳戶。OpenPosition V1 不凍結。

​

IncreaseLiquidityV2

liquidity: u128
amount_0_max: u64
amount_1_max: u64
base_flag: Option<bool>

• 從用戶轉移 amount_0_actual / amount_1_actual → 保管庫。
• 增加 personal_position.liquidity 和 pool_state.liquidity（如果在範圍內），以及端點 tick 的 liquidity_gross / liquidity_net。
• 收集自上次觸及以來應付的費用和獎勵並將其記入 tokens_fees_owed_{0,1} / reward_amount_owed。這些僅在 DecreaseLiquidity 或 CollectReward 時支付，而不是在增加時。

​

DecreaseLiquidityV2

liquidity: u128
amount_0_min: u64
amount_1_min: u64

• 給定當前 sqrt_price_x64，計算移除的 L 的 (amount_0, amount_1)。
• 結算自上次觸及以來累積的費用/獎勵，與 IncreaseLiquidity 相同。
• 從保管庫轉移 amount_0 + fees_owed_0 和 amount_1 + fees_owed_1 到用戶。
• 遞減流動性計數器；如果新的 personal_position.liquidity == 0，頭寸符合 ClosePosition 的條件。

​

ClosePosition

• 未凍結 NFT：不需要；額外的池帳戶無害，因為處理程序不讀取它。
• 凍結 NFT：附加 personal_position.pool_id 作為第一個剩餘帳戶。程序將其加載為 PoolState 並使用其 PDA 種子簽署解凍。

• personal_position.liquidity == 0。
• tokens_fees_owed_{0,1} == 0。
• 所有獎勵計數器 reward_amount_owed == 0。

• 如果 NFT 代幣帳戶被凍結，驗證第一個剩餘帳戶等於 personal_position.pool_id，然後使用池 PDA 解凍。
• 銷毀 NFT。
• 關閉 NFT 代幣帳戶和 personal_position，將租金退款給 nft_owner。如果頭寸 NFT 使用 Token-2022，它也關閉 NFT 鑄幣；經典 SPL Token 鑄幣無法關閉，供應量保持為零。

​

SwapV2

amount: u64                  // 如果 is_base_input=true 則輸入，否則輸出
other_amount_threshold: u64  // 最小輸出或最大輸入
sqrt_price_limit_x64: u128   // 硬邊界；0 ⇒ 無邊界
is_base_input: bool

• pool_state.status 允許交換。
• now >= open_time。
• sqrt_price_limit_x64 在 sqrt_price_x64 的正確一側用於方向。

1. 動態費用附加費 — 如果 pool.dynamic_fee_info 非零，程序使用自上次交換以來遍歷的 tick 距離更新波動率累加器（使用 products/clmm/fees 中的過濾/衰減規則），並在 AmmConfig.trade_fee_rate 之上添加 dynamic_fee_component。總費用上限為 10%（MAX_FEE_RATE_NUMERATOR / 1_000_000）。
2. 限價單匹配 — 當價格行走穿過持有開放限價單的 tick 時，程序首先填充該 tick 處可用的限價單流動性（按 order_phase 的 FIFO），然後沿著 LP 流動性曲線進行。已成交金額更新 tick.unfilled_ratio_x64 和 tick.part_filled_orders_remaining 以供稍後結算；訂單本身保持未花費，直到其所有者調用 SettleLimitOrder。
3. 單邊費用路由 — 當 pool.fee_on = Token0Only 或 Token1Only 時，交換步驟仍計算相同的輸入輸出交易；費用隨後被路由到配置的一側。對於配置費用側是輸出的方向，費用從交換輸出中扣除（用戶收到 out − fee）；對於配置費用側是輸入的方向，行為與 FromInput 匹配。見 pool_state 上的 is_fee_on_input(zero_for_one) 和 is_fee_on_token0(zero_for_one)。

​

OpenLimitOrder

nonce_index:    u8       // 用戶選擇的 nonce 帳戶索引（每個錢包 0..255）
zero_for_one:   bool     // true：用 token1 出售 token0；false：用 token0 出售 token1
tick_index:     i32      // 必須是 pool.tick_spacing 的倍數
amount:         u64      // 輸入代幣金額

• input_token_account 和 output_token_account 都未被凍結（否則 NotApproved）。
• pool_state.status 允許交換（位 4）和限價單（位 5）操作（否則 NotApproved）。
• tick_index % pool.tick_spacing == 0 並在 [MIN_TICK, MAX_TICK] 內。
• tick_index 在所選方向的 pool.tick_current 的正確一側（出售 token0 → tick 必須在當前上方，反之亦然）。在已穿過的 tick 處出售會立即匹配並被拒絕。

• limit_order 存在，快照打開時的 tick.order_phase 和 tick.unfilled_ratio_x64。
• tick.orders_amount += amount（在當前隊列中）。
• limit_order_nonce.order_nonce += 1。
• 發出 OpenLimitOrderEvent。

​

IncreaseLimitOrder

amount: u64    // 額外的輸入代幣金額

• limit_order.owner == signer。
• 訂單仍在同一隊列中（tick.order_phase == limit_order.order_phase）。如果隊列已開始填充，訂單已部分結算 — 調用者應首先調用 DecreaseLimitOrder 或 SettleLimitOrder 以向前推進。

• 從所有者 ATA 轉移 amount 到 input_vault。
• limit_order.total_amount += amount；tick.orders_amount += amount。

​

DecreaseLimitOrder

amount:     u64    // 要提取的輸入代幣金額（最大 = 未成交剩餘）
amount_min: u64    // 輸入端提取的滑點下限

• 從打開以來隊列的 unfilled_ratio_x64 重新計算訂單的已成交金額。
• 將已成交輸出發送到 output_token_account。
• 將 amount 的未成交輸入發送回 input_token_account。
• 相應地更新 limit_order。如果新的未成交剩餘為零，程序關閉帳戶並將租金退款給 owner。

​

SettleLimitOrder

• 使用 (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) 計算累積應付輸出。
• 將增量轉移到 output_token_account。
• 更新 limit_order.settled_output。
• 不關閉訂單；它對任何剩餘輸入仍然開放。

​

CloseLimitOrder

• 訂單的未成交剩餘為零（amount == total_amount 已成交並結算，或所有者之前將訂單減少到零並忘記關閉）。

• 關閉 limit_order；租金發送到 limit_order.owner。

​

CreateDynamicFeeConfig（管理員）

index:                       u16
filter_period:               u16   // 秒；例如 30
decay_period:                u16   // 秒；例如 600。必須 > filter_period
reduction_factor:            u16   // 1..10_000；例如 5_000 = 每個衰減窗口 50% 保留
dynamic_fee_control:         u32   // 1..100_000；波動率到費用曲線的增益
max_volatility_accumulator:  u32   // 上限

​

UpdateDynamicFeeConfig（管理員）

​

CollectProtocolFee / CollectFundFee

​

InitializeReward

open_time:     u64
end_time:      u64
emissions_per_second_x64: u128   // Q64.64

• 池上當前活躍的流少於 3 個。
• 資金提供者作為此指令的一部分將 total_emission = emissions_per_second × (end_time − open_time) 價值的獎勵代幣存入保管庫。
• 根據 operation_state 白名單獎勵鑄幣。

​

SetRewardParams

​

UpdateRewardInfos

​

CollectReward

• 結算獎勵增長（與費用相同的模式）。
• 將應付金額轉移到收件人 ATA，將 reward_amount_owed[i] 清零。

​

狀態變更矩陣

​

後續步驟

• products/clmm/code-demos — 可運行的 TypeScript 示例。
• products/clmm/fees — 費用和獎勵累積的詳細信息。
• reference/error-codes — 完整的 CLMM Anchor 錯誤表。

• raydium-io/raydium-clmm — programs/amm/src/instructions
• Raydium SDK v2 — @raydium-io/raydium-sdk-v2