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 陣列 PDA。它們不需要已經存在 — get_or_create_tick_array 在此指令內以 payer 的費用分配缺失的。沒有單獨的初始化 tick 陣列指令。
• 使用者在來源 ATA 中至少有 amount_0_max 和 amount_1_max。

• personal_position 存在，liquidity 設定，fee_growth_inside_last 快照。
• tick_lower 和 tick_upper 處的 Tick 陣列條目已更新（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 相應地。
• 收集自上次觸及以來應付的費用和獎勵並將其記入 token_fees_owed_{0,1} / reward_amount_owed。這些僅在 DecreaseLiquidity / DecreaseLiquidityV2 上支付，不在增加時 — 沒有獨立的收集指令。

​

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 相符。見 is_fee_on_input(zero_for_one) 和 is_fee_on_token0(zero_for_one) 在 PoolState 上。

​

OpenLimitOrder

nonce_index:    u8       // 使用者選擇的 nonce 帳戶索引（每個錢包 0..255）
zero_for_one:   bool     // true：賣 token0 換 token1；false：賣 token1 換 token0
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 以向前推進。

• 轉移 amount 從所有者 ATA 到 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

​

CollectExcessLamports