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_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。
• 收集自上次接触以来应付的费用和奖励并将其记入 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：卖 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 来前进。

• 从所有者 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