CLMM 指令参考

完整的 CLMM 指令参考：池生命周期、头寸管理、兑换与奖励流。

本页内容由 AI 自动翻译，所有内容以英文版本为准。

查看英文版 →

本页与 products/clmm/accounts（账户说明）和 products/clmm/math（数学原理）配套阅读。本页是参数与账户顺序的权威参考，具体字节布局以 IDL 为准。

​

指令总览

分组	指令	说明
Admin	CreateAmmConfig	创建新的费率档位。
Admin	UpdateAmmConfig	修改已有档位的费率。
Admin	UpdatePoolStatus	暂停/恢复池的操作。
Admin	CreateSupportMintAssociated	将 Token-2022 mint 扩展配置加入 CLMM 池的白名单。
Admin	CreateOperationAccount	初始化程序级别的操作账户（一次性操作）。
Admin	UpdateOperationAccount	修改操作账户白名单。
Admin	CreateDynamicFeeConfig	在 u16 索引下创建可复用的动态费率参数集。
Admin	UpdateDynamicFeeConfig	修改已有的 DynamicFeeConfig。已快照该配置的池不受影响。
Pool	CreatePool	初始化与 AmmConfig 绑定的 CLMM 池。标准 FromInput 费率路径，与 CreateCustomizablePool 共存。
Pool	CreateCustomizablePool	推荐用于新池。与 CreatePool 参数结构相同，新增 collect_fee_on 和可选的 enable_dynamic_fee 标志。
Position	OpenPosition / OpenPositionV2 / OpenPositionWithToken22Nft	铸造头寸 NFT。OpenPositionV2 取代 V1（新增 bitmap 扩展槽位）；OpenPositionWithToken22Nft 以 Token-2022 而非 SPL Token 形式发行头寸 NFT。新代码应使用 V2 或 Token-2022 变体。
Position	IncreaseLiquidity / IncreaseLiquidityV2	向已有头寸增加流动性。
Position	DecreaseLiquidity / DecreaseLiquidityV2	移除流动性，同时归集所欠费用。
Position	ClosePosition	销毁 NFT 并关闭 PersonalPositionState。
Position	CloseProtocolPosition	管理员专用，用于清理遗留 ProtocolPositionState PDA。当前程序不再创建或读取 ProtocolPositionState，该指令仅用于回收旧版本程序创建账户的租金。
Swap	Swap / SwapV2	恒定流动性兑换。两个变体均支持动态费率、单侧费率路由和限价单匹配；区别在于 SwapV2 支持 Token-2022 mint（V1 要求两个 vault 均为经典 SPL Token）。
Swap	SwapRouterBaseIn	多跳兑换，由路由器使用。
Limit order	OpenLimitOrder	在指定 tick 挂卖单。未成交的代币留在该 tick，撮合引擎在价格穿越时成交。
Limit order	IncreaseLimitOrder	追加到已有的挂单中。
Limit order	DecreaseLimitOrder	减少或取消挂单，返还未成交余额及已结算的输出部分。
Limit order	SettleLimitOrder	将已成交的输出代币推送给挂单所有者。可由所有者或运营 keeper 调用。
Limit order	CloseLimitOrder	关闭已完全成交的挂单账户。租金始终返回给挂单的 owner，可由所有者或 keeper 调用。
Fees	CollectProtocolFee	管理员归集协议费用。
Fees	CollectFundFee	管理员归集基金费用。
Rewards	InitializeReward	为池添加新的奖励流。
Rewards	SetRewardParams	修改已有奖励的释放速率/结束时间。
Rewards	UpdateRewardInfos	将奖励增长结算到当前时间（由所有兑换/头寸变更指令调用）。
Rewards	TransferRewardOwner	转让可设置或充值奖励流的权限。
Rewards	CollectRemainingRewards	奖励流 end_time 到期后，将未分配的代币归还给资助方。
Utility	InitTickArray	初始化 tick-array 账户（通常与 OpenPosition 打包）。

大多数管理员专用指令（CreateAmmConfig、UpdateAmmConfig、UpdatePoolStatus、CreateSupportMintAssociated、CreateOperationAccount、UpdateOperationAccount、CloseProtocolPosition）由程序硬编码的 admin 公钥控制。奖励流管理指令（TransferRewardOwner、CollectRemainingRewards）由奖励资助方控制，而非程序管理员。

V2 后缀表示”支持 vault/NFT 的 Token-2022，需要 bitmap 扩展槽位”。SDK 默认对新池使用 V2。

​

CreatePool

参数

sqrt_price_x64: u128           // 初始价格
open_time:      u64            // 此时间之前拒绝兑换

账户（简略）

#	名称	W	S	说明
1	pool_creator	W	S
2	amm_config			选定的费率档位。
3	pool_state	W		在此 init。
4	token_mint_0			已排序。
5	token_mint_1
6	token_vault_0	W		在此 init，归属于池权限 PDA。
7	token_vault_1	W
8	observation_state	W		在此 init。
9	tick_array_bitmap_extension	W		在此 init（V2）。
10	token_program
11	token_program_2022
12	system_program, rent

前置条件

• token_mint_0 < token_mint_1（按字节序）。
• amm_config.disable_create_pool == false。
• Mint 未被 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

推荐用于新池。与 CreatePool 效果相同，额外支持每池费率归集模式和可选的动态费率。

参数

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

账户（简略） — 与 CreatePool 相同，当 enable_dynamic_fee = true 时额外需要：

#	名称	W	S	说明
N	dynamic_fee_config			用于快照的共享配置，必须已存在。

前置条件 — 与 CreatePool 相同。若 enable_dynamic_fee = false，则忽略 dynamic_fee_config。

后置条件

• pool_state.fee_on 设置为所选的 CollectFeeOn 变体。
• 若启用了动态费率：pool_state.dynamic_fee_info 从提供的 DynamicFeeConfig 初始化（复制五个校准参数，状态字段清零）。
• 否则：pool_state.dynamic_fee_info 清零（此池永久禁用动态费率）。

fee_on 和动态费率启用位仅在池创建时设置。没有就地升级路径——通过旧版 CreatePool 创建的池无法追溯获得动态费率或单侧费率。新部署应默认使用本指令。

​

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 为基准

账户（简略）

#	名称	W	S
1	payer	W	S
2	position_nft_owner
3	position_nft_mint	W	S（keypair）
4	position_nft_account	W		所有者持有 NFT 的 ATA。
5	metadata_account	W		Metaplex（可选，当 with_metadata 时）。
6	pool_state	W
7	protocol_position
8	tick_array_lower	W		未初始化时创建。
9	tick_array_upper	W		同上。
10	personal_position	W		在此创建。
11	token_account_0, token_account_1	W		用户源 ATA。
12	token_vault_0, token_vault_1	W
13	rent, system_program, token_program
14	associated_token_program
15	metadata_program			可选。
16	token_program_2022			V2。
17	vault_0_mint, vault_1_mint			V2。
18	tick_array_bitmap_extension	W		V2（如涉及）。

数学原理 — 参见 products/clmm/math。程序根据 base_flag 将 liquidity 或 (amount_0_max, amount_1_max) 解析为实际的 L 及实际消耗的代币数量。

前置条件

• 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-array 条目更新（liquidity_gross += L，liquidity_net ± L，维护费率增长快照）。
• 若头寸在区间内（tick_lower ≤ tick_current < tick_upper），pool_state.liquidity += L。

常见错误 — InvalidTickIndex、NotApproved、ZeroAmountSpecified、TransactionTooLarge（tick 数组过多）。

​

IncreaseLiquidityV2

向已开仓的头寸追加流动性。

参数

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

账户 — 与 OpenPosition 类似，无需 NFT mint（头寸已存在；NFT 以所有者持有 1 个代币的 ATA 形式传入）。

效果

• 将 amount_0_actual / amount_1_actual 从用户转入 vault。
• 递增 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

账户 — 结构与 IncreaseLiquidity 相同。

效果

• 根据当前 sqrt_price_x64 计算移除 L 对应的 (amount_0, amount_1)。
• 与 IncreaseLiquidity 相同，结算自上次操作以来累积的费用/奖励。
• 将 amount_0 + fees_owed_0 和 amount_1 + fees_owed_1 从 vault 转出给用户。
• 递减流动性计数器；若新的 personal_position.liquidity == 0，该头寸可调用 ClosePosition。

滑点 — amount_0_min 和 amount_1_min 是用户在输出端扣除 Token-2022 转账费用后可接受的最低金额。

​

ClosePosition

销毁头寸 NFT 并关闭 PersonalPositionState。

前置条件

• personal_position.liquidity == 0。
• tokens_fees_owed_{0,1} == 0。
• 所有奖励计数器 reward_amount_owed == 0。

（即：先归集所有收益并将流动性减至零。）

效果

• 销毁 NFT。
• 关闭 NFT mint 账户和 personal_position 账户，将租金退还给 payer。

​

SwapV2

沿流动性曲线执行兑换；根据 is_base_input 决定精确输入或精确输出模式。

参数

amount: u64                  // is_base_input=true 时为输入量，否则为输出量
other_amount_threshold: u64  // 最小输出或最大输入
sqrt_price_limit_x64: u128   // 硬边界；0 表示无限制
is_base_input: bool

账户（简略）

#	名称	W	S	说明
1	payer		S
2	amm_config
3	pool_state	W
4	input_token_account	W
5	output_token_account	W
6	input_vault	W
7	output_vault	W
8	observation_state	W
9	token_program
10	token_program_2022			V2。
11	memo_program			V2（某些 Token-2022 路径必需）。
12	input_vault_mint, output_vault_mint			V2。
13	tick_array_bitmap_extension（可选）	W		若兑换步入扩展区则需要。
14+	tick_array（remaining）	W		足够覆盖预期兑换范围的数组数量。

调用方传入一组按优先级排列的 tick 数组，覆盖预期的兑换路径；程序按需使用。SDK 通过 PoolUtils.computeAmountOutFormat 或 API 的报价端点计算此列表。

前置条件

• pool_state.status 允许兑换。
• now >= open_time。
• sqrt_price_limit_x64 在当前 sqrt_price_x64 的正确一侧（与兑换方向一致）。

常见错误 — ExceededSlippage、SqrtPriceLimitOverflow、TickArrayNotFound、LiquidityInsufficient。

调用方应了解的 SwapV2 内部逻辑（2025 年后版本）：

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 时，程序优先以 FIFO 顺序（按 order_phase）成交该 tick 的限价单流动性，再沿 LP 流动性曲线继续前进。成交金额更新 tick.unfilled_ratio_x64 和 tick.part_filled_orders_remaining，供后续结算使用；挂单本身直到所有者调用 SettleLimitOrder 前不会被消耗。
3. 单侧费率路由 — 当 pool.fee_on = Token0Only 或 Token1Only 时，兑换步骤计算的输入输出量不变，费用路由至配置的一侧。若配置的费率侧为输出方，费用从兑换输出中扣除（用户收到 out − fee）；若为输入方，行为与 FromInput 相同。详见 PoolState 上的 is_fee_on_input(zero_for_one) 和 is_fee_on_token0(zero_for_one)。

Swap（V1）与 SwapV2 实现了相同的动态费率、单侧费率路由和限价单匹配，唯一区别是不支持 Token-2022——两个 vault 必须为经典 SPL Token。任何包含 Token-2022 mint 的池必须通过 SwapV2 进行兑换。聚合器和 SDK 已对所有 CLMM 腿优先使用 V2，调用方无需根据 mint 类型进行分支判断。

​

OpenLimitOrder

在指定 tick 挂卖单。挂单进入该 tick 的 FIFO 队列，价格穿越时成交。

参数

nonce_index:    u8       // 用户选择的 nonce 账户索引（每个钱包 0..255）
zero_for_one:   bool     // true：卖出 token0 换 token1；false：卖出 token1 换 token0
tick_index:     i32      // 必须是 pool.tick_spacing 的整数倍
amount:         u64      // 输入代币数量

账户（简略）

#	名称	W	S	说明
1	payer	W	S	挂单所有者，支付租金。
2	pool_state	W
3	tick_array	W		包含 tick_index 的 tick 数组。
4	limit_order_nonce	W		PDA。init_if_needed——用户在此 nonce_index 下首次挂单时创建。
5	limit_order	W		PDA。在此 init。
6	input_token_account	W		用户的输入 ATA。
7	input_vault	W		池的输入 vault。
8	input_vault_mint			Token-2022 费用处理。
9	input_token_program			SPL 或 Token-2022。
10	system_program, rent

前置条件

• tick_index % pool.tick_spacing == 0 且在 [MIN_TICK, MAX_TICK] 范围内。
• tick_index 须在当前 pool.tick_current 的正确一侧（卖出 token0 时 tick 须高于当前价，反之亦然）。在已穿越的 tick 挂单会被立即撮合，因此会被拒绝。
• pool_state.status 允许限价单操作（位 5）。

后置条件

• limit_order 存在，快照开仓时的 tick.order_phase 和 tick.unfilled_ratio_x64。
• tick.orders_amount += amount（在当前队列中）。
• limit_order_nonce.order_nonce += 1。
• 触发 OpenLimitOrderEvent。

常见错误 — InvalidLimitOrderAmount（金额为零或低于池的最低限额）、InvalidTickIndex（超出 [MIN_TICK, MAX_TICK] 范围，或在选定方向下位于 tick_current 错误一侧）、TickAndSpacingNotMatch（tick_index % pool.tick_spacing != 0）、OrderPhaseSaturated。

​

IncreaseLimitOrder

向已有挂单追加金额。只能由挂单的 owner 调用。

参数

amount: u64    // 追加的输入代币数量

账户 — 与 OpenLimitOrder 类似，无需 nonce 账户；直接传入 limit_order PDA。

前置条件

• 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    // 输入侧提取的滑点下限

账户 — 包含输入和输出两侧代币：

#	名称	W	S
1	owner		S
2	pool_state	W
3	tick_array	W
4	limit_order	W
5	input_token_account	W
6	output_token_account	W
7	input_vault	W
8	output_vault	W
9	input_vault_mint, output_vault_mint
10	token_program, token_program_2022

效果

• 根据开仓以来队列的 unfilled_ratio_x64 重新计算挂单的已成交金额。
• 将已成交的输出发送至 output_token_account。
• 将 amount 数量的未成交输入退还至 input_token_account。
• 相应更新 limit_order。若新的未成交余额为零，程序关闭该账户并将租金退还给 owner。

​

SettleLimitOrder

将已成交的输出代币推送给所有者，不改变挂单的未成交余额。适用于 auto_withdraw keeper 对长期部分成交挂单进行分批支付的场景。

调用方 — 挂单的 owner，或程序的 limit_order_admin（运行自动化 keeper 循环的链下运营热钱包）。keeper 无其他权限——不能将用户资金转移至挂单 owner ATA 以外的地方。

账户

#	名称	W	S
1	signer		S	所有者或 limit_order_admin
2	pool_state
3	tick_array
4	limit_order	W
5	output_token_account	W		所有者的输出 ATA。
6	output_vault	W		池的输出 vault。
7	output_vault_mint
8	output_token_program

效果

• 使用 (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) 计算累计应付输出。
• 将差额转入 output_token_account。
• 更新 limit_order.settled_output。
• 不关闭挂单；剩余输入仍处于挂单状态。

​

CloseLimitOrder

关闭已完全成交的挂单账户。无论谁签名，租金始终返回给 limit_order.owner。

调用方 — owner 或 limit_order_admin。

前置条件

• 挂单未成交余额为零（即 amount == total_amount 已全部成交并结算，或所有者此前已将挂单减至零但未关闭）。

效果

• 关闭 limit_order；租金发送至 limit_order.owner。

​

CreateDynamicFeeConfig（admin）

在 u16 索引下创建可复用的参数集。

参数

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   // 上限

账户

#	名称	W	S	说明
1	owner	W	S	硬编码的 admin 公钥。
2	dynamic_fee_config	W		PDA，在此 init。
3	system_program

常见错误 — 若 decay_period <= filter_period 或任何值为 0 的字段超出范围，返回 InvalidDynamicFeeConfigParams。

​

UpdateDynamicFeeConfig（admin）

修改已有的 DynamicFeeConfig。已在创建时快照该配置的池不会被追溯更新；只有新创建的引用此配置的池才会使用新值。

参数 — 与 CreateDynamicFeeConfig 相同的五个校准字段（filter_period、decay_period、reduction_factor、dynamic_fee_control、max_volatility_accumulator）；index 在创建时固定，此处无需重传。

​

CollectProtocolFee / CollectFundFee

与 CPMM 的 CollectProtocolFee / CollectFundFee 结构相同。签名者须匹配 AmmConfig.owner / AmmConfig.fund_owner。将池 vault 中累积的协议/基金费用归集到指定接收方，并将对应的 PoolState.protocol_fees_* / fund_fees_* 字段清零。

​

InitializeReward

为池添加新的奖励流。最多可同时激活 3 个奖励流。

参数

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

账户

#	名称	W	S
1	reward_funder	W	S
2	funder_token_account	W
3	amm_config
4	pool_state	W
5	operation_state			CLMM 操作状态 PDA，控制奖励创建权限。
6	reward_token_mint
7	reward_token_vault	W		在此 init。
8	reward_token_program
9	system_program, rent

前置条件

• 池当前激活的奖励流少于 3 个。
• 资助方在本指令中将 total_emission = emissions_per_second × (end_time − open_time) 数量的奖励代币存入 vault。
• 奖励 mint 须在 operation_state 中列入白名单。

​

SetRewardParams

延长、充值或修改已有奖励流的释放速率。通常由池创建者或 Raydium 多签调用。链上约束：通常可以延长 end_time 或提高释放量，但不能追溯降低。请参阅 operation_state 的所有者列表。

​

UpdateRewardInfos

纯状态更新——通过计算 emissions_per_second × Δt / liquidity 将 reward_growth_global_x64 结算到当前时间。由所有涉及流动性变更的指令内部调用。同时作为独立指令对外暴露，供 UI、crank 等外部参与方主动触发。

​

CollectReward

头寸所有者领取应得的奖励代币。

账户

#	名称	W	S
1	nft_owner		S
2	nft_account			所有者持有头寸 NFT 的 ATA。
3	personal_position	W
4	pool_state	W
5	protocol_position
6	reward_token_vault	W
7	recipient_token_account	W
8	token_program
9	token_program_2022

效果

• 结算奖励增长（与费用结算模式相同）。
• 将应付金额转入接收方 ATA，将 reward_amount_owed[i] 清零。

​

状态变更矩阵

指令	pool.liquidity	pool.fee_growth_global	pool.reward_growth_global	personal_position.liquidity	Tick array
CreatePool	0	0	—	—	—
OpenPosition	在区间内则 +	—	—	新建	增加 liquidity_gross/net
IncreaseLiquidity	在区间内则 +	结算欠付	结算欠付	+	调整
DecreaseLiquidity	在区间内则 −	结算欠付	结算欠付	−	调整
ClosePosition	—	—	—	销毁	—
SwapV2	穿越时 ±	+	—	—	穿越并翻转 outside；匹配限价单队列
OpenLimitOrder	—	—	—	—	目标 tick 的 orders_amount += amount
IncreaseLimitOrder	—	—	—	—	orders_amount += amount
DecreaseLimitOrder	—	—	—	—	orders_amount -=，可能关闭队列
SettleLimitOrder	—	—	—	—	—（tick 只读）
CloseLimitOrder	—	—	—	—	—
CreateCustomizablePool	0	0	—	—	—
UpdateRewardInfos	—	—	+	—	—
CollectReward	—	—	结算欠付	—	—

​

延伸阅读

• 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