CLMM 指令

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

本页与 products/clmm/accounts（账户是什么）和 products/clmm/math（数学是什么）配套。本页对参数和账户顺序具有权威性；具体的字节布局来自 IDL。

指令清单

分组	指令	说明
管理员	`CreateAmmConfig`	定义新的费用等级。
管理员	`UpdateAmmConfig`	更改现有等级的费率。
管理员	`UpdatePoolStatus`	暂停/恢复池上的操作。
管理员	`CreateSupportMintAssociated`	允许列表 Token-2022 铸币扩展配置以在 CLMM 池中使用。
管理员	`CreateOperationAccount`	初始化程序级操作账户（一次性）。
管理员	`UpdateOperationAccount`	修改操作账户白名单。
管理员	`CreateDynamicFeeConfig`	在 u16 索引下创建可重用的动态费用参数集。
管理员	`UpdateDynamicFeeConfig`	修改现有 `DynamicFeeConfig`。已快照的池不受影响。
管理员	`CreatePermissionPda`	通过初始化其 `Permission` PDA，授予某个权限调用 `CreatePermissionedPool` 的资格。
管理员	`ClosePermissionPda`	通过关闭其 `Permission` PDA 撤销先前授予的权限；租金退款给调用者。
池	`CreatePool`	初始化绑定到 `AmmConfig` 的 CLMM 池。标准的 FromInput 费用路径。与 `CreateCustomizablePool` 共存。
池	`CreateCustomizablePool`	推荐用于新池。与 `CreatePool` 形式相同，加上 `collect_fee_on` 和可选启用的 `enable_dynamic_fee` 标志。
池	`CreatePermissionedPool`	为已有一个池的交易对创建额外池，使用客户端提供的 `seed_index` 折叠到池 PDA 中。支付者必须持有 `Permission` PDA。
头寸	`OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft`	铸造头寸 NFT。`OpenPositionV2` 取代 V1；`OpenPositionWithToken22Nft` 将 NFT 作为 Token-2022 发行。V2 路径仅在底层保管库铸币的冻结权限与受限发行者列表匹配时冻结 NFT 账户。否则账户保持解冻。
头寸	`IncreaseLiquidity` / `IncreaseLiquidityV2`	向现有头寸添加流动性。
头寸	`DecreaseLiquidity` / `DecreaseLiquidityV2`	移除流动性；收集应付费用。
头寸	`ClosePosition`	销毁 NFT 并关闭 `PersonalPositionState`。如果 NFT 账户被冻结，首先使用作为剩余账户提供的池 PDA 解冻。
头寸	`CloseProtocolPosition`	仅限管理员的旧版 `ProtocolPositionState` PDA 清理。当前程序不再创建或读取 `ProtocolPositionState` — 此指令仅用于回收由旧版程序版本创建的账户的租金。
交换	`Swap` / `SwapV2`	恒定流动性交换。两个变体都应用动态费用、单边费用路由和限价单匹配；唯一的区别是 `SwapV2` 接受 Token-2022 铸币（V1 变体要求两个保管库都是经典 SPL Token）。
交换	`SwapRouterBaseIn`	多跳，由路由器使用。
限价单	`OpenLimitOrder`	在某个 tick 处下卖单。未成交的代币留在 tick 上；匹配引擎在价格穿过时填充它们。
限价单	`IncreaseLimitOrder`	添加到现有开放订单。
限价单	`DecreaseLimitOrder`	减少或取消开放订单；支付未成交的剩余部分加上已结算的任何输出。
限价单	`SettleLimitOrder`	将已成交的输出代币推送给订单所有者。可由所有者或操作保管人调用。
限价单	`CloseLimitOrder`	关闭完全消耗的订单账户。租金始终返回给订单的 `owner`。可由所有者或保管人调用。
费用	`CollectProtocolFee`	协议费用的管理员清理。
费用	`CollectFundFee`	基金费用的管理员清理。
奖励	`InitializeReward`	将新的奖励流附加到池。
奖励	`SetRewardParams`	更改现有奖励的发放速率/结束时间。
奖励	`UpdateRewardInfos`	将奖励增长结算到现在（由任何交换/头寸变化调用）。
奖励	`TransferRewardOwner`	转移可以设置或充值奖励流的权限。
奖励	`CollectRemainingRewards`	在奖励流的 `end_time` 之后，将任何未分配的代币清理回资金提供者。
管理员	`CloseSupportMintAssociated`	移除某个铸币的 `SupportMintAssociated` 注册并退还其租金。

不存在初始化 tick 数组的指令，也不需要。 tick 数组是在 OpenPosition* / IncreaseLiquidity* 内部由 TickArrayState::get_or_create_tick_array 创建的，费用由 payer 承担。把（可能仍未初始化、由系统程序拥有的）tick 数组 PDA 作为 tick_array_lower / tick_array_upper 传入，程序会在它缺失时分配它。OpenLimitOrder 对它唯一的 tick_array 做同样的事。

大多数仅限管理员的指令（CreateAmmConfig、UpdateAmmConfig、UpdatePoolStatus、CreateOperationAccount、UpdateOperationAccount、CloseProtocolPosition）由程序的硬编码 admin 公钥门控。CreatePermissionPda / ClosePermissionPda 接受 admin 公钥或专用的 permission_pda_admin 密钥；CreateSupportMintAssociated / CloseSupportMintAssociated 接受 admin 公钥或专用的 support-mint 所有者密钥。奖励流管理员指令（TransferRewardOwner、CollectRemainingRewards）由奖励资金提供者门控，而不是程序管理员。 V2 后缀表示”支持保管库/NFT 上的 Token-2022，需要位图扩展槽”。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`	W		`TickArrayBitmapExtension` PDA；在此处 `init`。
10	`token_program_0`			拥有 `token_mint_0` 的程序 —— SPL Token 或 Token-2022。
11	`token_program_1`			拥有 `token_mint_1` 的程序。
12	`system_program`
13	`rent`

槽位 10 和 11 是按铸币的，而不是”先 SPL Token 再 Token-2022”。每一个都受对应铸币上的 mint::token_program 约束，因此对于 token_mint_0 是 Token-2022 而 token_mint_1 是经典 SPL 的池，你必须在槽位 10 传入 Token-2022，在槽位 11 传入 SPL Token。 CreateCustomizablePool 和 CreatePermissionedPool 使用同样的这两个槽位。

前置条件

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`

推荐用于新池。与 CreatePool 效果相同，加上每池费用收集模式和可选的动态费用选择加入。参数

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

账户 — 恰好是 CreatePool 声明的那 13 个账户。dynamic_fee_config 不是一个声明的账户。

当 enable_dynamic_fee = true 时，要快照的 DynamicFeeConfig 必须作为最后一个 remaining_account 传入 —— 处理器读取的是 ctx.remaining_accounts.last()。因此任何 SupportMintAssociated 绕过 PDA 都必须排在它之前，否则程序会快照错误的账户并反序列化失败。在设置了该标志却省略它时，会以 AccountLack 失败。

前置条件 — 与 CreatePool 相同。如果 enable_dynamic_fee = false，则不需要任何 remaining_account，传入的账户只会被扫描是否为 support-mint 记录。 后置条件

pool_state.fee_on 设置为选定的 CollectFeeOn 变体。
如果启用了动态费用：pool_state.dynamic_fee_info 从提供的 DynamicFeeConfig 初始化（复制五个校准参数；状态字段清零）。
否则：pool_state.dynamic_fee_info 被清零（= 此池永远不活跃动态费用）。

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

`CreatePermissionedPool`

CreatePool 和 CreateCustomizablePool 都从 ["pool", amm_config, token_mint_0, token_mint_1] 派生池 PDA，因此每个 (config, mint0, mint1) 三元组恰好有一个规范池地址 — 在相同种子处的第二个 init 失败。CreatePermissionedPool 通过将客户端提供的 seed_index: u16 折叠到池 PDA 种子中来解除此限制，允许同一交易对和费用等级的多个池 — 每个在其自己的地址处。因为任意池地址是特权能力，支付者必须持有授权它的 Permission PDA。关于池的其他一切与 CreateCustomizablePool 相同：它采用相同的 CreateCustomizableParams 并支持单边费用和动态费用选择加入。参数

customizable_params: CreateCustomizableParams   // 与 CreateCustomizablePool 相同的结构
seed_index:          u16                          // 必须非零；折叠到池 PDA 种子中

账户（简化） — 与 CreateCustomizablePool 相同，加上前面的：

#	名称	W	S	说明
1	`payer`	W	S	支付租金。必须是下面 `permission` PDA 的权限。
2	`pool_creator`			记录为 `pool_state.owner`。可能与 `payer` 不同。
3	`permission`			PDA `["permission", payer]`。如果不存在/不由程序拥有，Anchor 拒绝调用。
…	（`amm_config`、`pool_state`、铸币、保管库、`observation_state`、`tick_array_bitmap`、代币/系统程序）			如 `CreateCustomizablePool` 中所示。

pool_state PDA 从 ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()] 派生。 前置条件

seed_index != 0。seed_index 为 0 保留给旧版池并在此处被拒绝；[0, 0] 种子分量是使旧版池地址折叠到经典四种子形式的原因。
payer 的 permission PDA 存在（由管理员通过 CreatePermissionPda 创建）。
与 CreatePool 相同的铸币/允许列表规则。

后置条件

新的 pool_state 存在于 seed_index 派生的地址处，pool_state.seed_index = seed_index。
所有其他后置状态与 CreateCustomizablePool 匹配（费用模式、可选动态费用）。

此指令不扩大一般池创建访问 — 无权限创建继续通过 CreatePool / CreateCustomizablePool，每对仍为一个池。CreatePermissionedPool 存在于白名单操作者需要同一交易对的多个池（例如不同的初始价格或启动队列）并持有由管理员授予的 Permission PDA 的特定情况。

`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	新的密钥对。
4	`position_nft_account`	W		所有者的 NFT ATA。
5	`metadata_account`	W		Metaplex 元数据 PDA。无条件声明，即使 `with_metadata = false` 时也是如此。
6	`pool_state`	W
7	`protocol_position`			遗留字段；只读的 `UncheckedAccount`。
8	`tick_array_lower`	W		如果未初始化则在此处创建。
9	`tick_array_upper`	W		相同。
10	`personal_position`	W		在此处创建。
11	`token_account_0`	W		用户源 ATA。
12	`token_account_1`	W
13	`token_vault_0`	W
14	`token_vault_1`	W
15	`rent`
16	`system_program`
17	`token_program`
18	`associated_token_program`
19	`metadata_program`			Metaplex Token Metadata。
20	`token_program_2022`
21	`vault_0_mint`
22	`vault_1_mint`

OpenPositionWithToken22Nft 是同一列表，但移除了 metadata_account（5）和 metadata_program（19）—— 它改为通过 NFT 铸币上的 Token-2022 元数据扩展写入头寸的元数据 —— 共 20 个账户。它的 position_nft_mint 是一个纯 Signer，position_nft_account 是 UncheckedAccount。

tick_array_bitmap_extension 在两个变体上都不是声明的账户。 当头寸的范围落在池子内联的 tick_array_bitmap（±512 个 tick 数组）之外时，请把种子为 ["pool_tick_array_bitmap_extension", pool_state] 的 TickArrayBitmapExtension PDA 作为 remaining_accounts[0] 追加。

数学 — 见 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 数组 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 不冻结。

常见错误 — TickInvalidOrder（tick_lower >= tick_upper）、TickAndSpacingNotMatch（某个端点不是 tick_spacing 的倍数）、InvalidTickIndex（超出 [MIN_TICK, MAX_TICK]）、MissingTickArrayBitmapExtensionAccount（范围在内联位图之外且未追加扩展账户）、NotApproved（pool_state.status 阻止开仓）、ZeroAmountSpecified。

头寸冻结不添加声明的指令账户或参数。客户端可以使用现有的 V2 布局打开这些头寸。行为在链上从 vault_0_mint 和 vault_1_mint 选择。

`IncreaseLiquidityV2`

向已打开的头寸添加流动性。参数

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

账户 — 15 个，并且无法从 OpenPosition 推导出来：没有 rent、没有 system_program、没有 associated_token_program，也没有元数据账户。

#	名称	W	S
1	`nft_owner`		S
2	`nft_account`
3	`pool_state`	W
4	`protocol_position`
5	`personal_position`	W
6	`tick_array_lower`	W
7	`tick_array_upper`	W
8	`token_account_0`	W
9	`token_account_1`	W
10	`token_vault_0`	W
11	`token_vault_1`	W
12	`token_program`
13	`token_program_2022`
14	`vault_0_mint`
15	`vault_1_mint`

当头寸的范围在内联位图之外时，把 TickArrayBitmapExtension PDA 作为 remaining_accounts[0] 放在最前面。效果

从用户转移 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

账户 — 16 个，并且与 IncreaseLiquidityV2 既不同形也不同序：personal_position 和 pool_state 互换，保管库排在 tick 数组之前，用户侧账户命名为 recipient_token_account_*，另外多了一个 memo_program。

#	名称	W	S
1	`nft_owner`		S
2	`nft_account`
3	`personal_position`	W
4	`pool_state`	W
5	`protocol_position`
6	`token_vault_0`	W
7	`token_vault_1`	W
8	`tick_array_lower`	W
9	`tick_array_upper`	W
10	`recipient_token_account_0`	W
11	`recipient_token_account_1`	W
12	`token_program`
13	`token_program_2022`
14	`memo_program`
15	`vault_0_mint`
16	`vault_1_mint`

剩余账户 — 每个正在收取的活跃奖励三个，顺序为 reward_token_vault(W)、recipient_token_account(W)、reward_vault_mint。当头寸的范围在内联位图之外时，把 TickArrayBitmapExtension PDA 放在最前面。

这也是收取费用和奖励的唯一方式。要在不改变头寸的情况下收取，请以 liquidity = 0、 amount_0_min = 0、amount_1_min = 0 调用它。

效果

给定当前 sqrt_price_x64，计算移除的 L 的 (amount_0, amount_1)。
结算自上次接触以来累积的费用/奖励，与 IncreaseLiquidity 相同。
从保管库转移 amount_0 + fees_owed_0 和 amount_1 + fees_owed_1 到用户。
递减流动性计数器；如果新的 personal_position.liquidity == 0，头寸符合 ClosePosition 的条件。

滑点 — amount_0_min 和 amount_1_min 是用户在输出端 Token-2022 转移费用净额后接受的最小值。

`ClosePosition`

销毁头寸 NFT 并关闭 PersonalPositionState。 声明的账户

#	名称	W	S	说明
1	`nft_owner`	W	S	必须拥有持有金额 `1` 的 NFT 代币账户。
2	`position_nft_mint`	W		必须与 `personal_position.nft_mint` 匹配。
3	`position_nft_account`	W		NFT 所有者的账户；可能是经典 SPL Token 或 Token-2022。
4	`personal_position`	W		关闭到 `nft_owner`。
5	`system_program`			关闭头寸状态。
6	`token_program`			必须拥有 NFT 铸币和代币账户。

剩余账户

解冻的 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 铸币无法关闭，保持供应量为零。

解冻、销毁和关闭是原子的。NFT 在这些步骤之间无法变为可转移。 条件客户端中断 — 声明的 IDL 布局未改变，因此旧版客户端继续关闭现有和解冻的头寸。省略池剩余账户的旧版构建器在关闭冻结头寸时失败，出现 AccountLack。为每次关闭传递池是最简单的兼容策略。

`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`（剩余）	W		足够的数组来跨越行走的预期范围。

调用者传递覆盖预期交换行走的排序 tick 数组列表；程序使用所需的数量。SDK 通过 PoolUtils.computeAmountOutFormat 或 API 的报价端点计算此列表。 前置条件

pool_state.status 允许交换。
now >= open_time。
sqrt_price_limit_x64 在 sqrt_price_x64 的正确一侧用于该方向。

常见错误 — TooLittleOutputReceived（精确输入的滑点）、TooMuchInputPaid（精确输出的滑点）、SqrtPriceLimitOverflow、NotEnoughTickArrayAccount、InvalidFirstTickArrayAccount、MissingTickArrayBitmapExtensionAccount、LiquidityInsufficient、NotApproved（pool_state.status 上设置了交换位）。CLMM 没有 ExceededSlippage 变体 —— 那是 CPMM 的名字 —— 也没有 TickArrayNotFound。 SwapV2 在内部做什么调用者应该知道的（2025 年后发布）：

动态费用附加费 — 如果 pool.dynamic_fee_info 非零，程序使用自上次交换以来遍历的 tick 距离更新波动率累加器（使用 products/clmm/fees 中的过滤/衰减规则）并在 AmmConfig.trade_fee_rate 之上添加 dynamic_fee_component。总费用上限为 10%（MAX_FEE_RATE_NUMERATOR / 1_000_000）。
限价单匹配 — 当价格行走穿过持有开放限价单的 tick 时，程序首先在该 tick 处填充可用的限价单流动性（按 order_phase 的 FIFO），然后沿 LP 流动性曲线继续。已填充的金额更新 tick.unfilled_ratio_x64 和 tick.part_filled_orders_remaining 以供后续结算；订单本身保持未花费，直到其所有者调用 SettleLimitOrder。
单边费用路由 — 当 pool.fee_on = Token0Only 或 Token1Only 时，交换步骤仍计算相同的输入-输出交易；费用随后被路由到配置的一侧。对于配置的费用侧是输出的方向，费用从交换输出中扣除（用户接收 out − fee）；对于配置的费用侧是输入的方向，行为与 FromInput 匹配。见 pool_state 上的 is_fee_on_input(zero_for_one) 和 is_fee_on_token0(zero_for_one)。

Swap（V1）实现与 SwapV2 相同的动态费用、单边费用路由和限价单匹配；它缺少的唯一功能是 Token-2022 支持 — 两个保管库都必须是经典 SPL Token。任何 Token-2022 铸币的池必须通过 SwapV2 交换。聚合器和 SDK 已经为每个 CLMM 腿优先选择 V2，所以调用者不必根据铸币类型分支。

`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。检查 `frozen`。
7	`output_token_account`	W		用户的输出 ATA。在打开时不扣除 — 仅需要以便程序可以确认它不是 `frozen`（即填充可以稍后交付）。
8	`input_vault`	W		池输入保管库。
9	`output_vault`	W		池输出保管库。识别输出铸币以进行 `output_token_account` / `output_vault_mint` 检查。
10	`input_vault_mint`			Token-2022 费用处理。
11	`output_vault_mint`			输出侧的铸币（冻结检查配对）。
12	`input_token_program`			SPL 或 Token-2022。
13	`system_program`			为 `limit_order`、`limit_order_nonce` 以及——如有需要——`tick_array` 的分配出资。

剩余账户 — [0] tick_array_bitmap_extension，仅在需要初始化一个起始索引落在池子内联位图之外的 tick 数组时才需要。否则什么都不用传。

这里没有 rent 账户：该结构体到 system_program 就结束了，共 13 个声明的账户。位置 14 上多出来的 rent 正好落在读取可选位图扩展的地方，所以订单看起来能用，直到第一次需要创建内联位图之外的 tick 数组时 —— 然后就失败了。

账户列表变化（2026-07 发布）。 OpenLimitOrder 现在也采用输出侧账户 — output_token_account、output_vault 和 output_vault_mint — 除了输入侧。它们仅用于验证：如果所有者的输入或输出代币账户被冻结，程序拒绝订单。这保证填充实际上可以结算到所有者的输出 ATA，这对于允许列表/默认冻结的 Token-2022 铸币（例如许可代币）很重要，其中账户可能尚未解冻。针对旧版单侧账户列表构建的客户端必须添加三个输出账户。

前置条件

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。

常见错误 — NotApproved（输入或输出代币账户冻结，或池禁用交换/限价单）、ZeroAmountSpecified（扣除输入侧转账费后 amount == 0）、InvalidLimitOrderAmount（该数量在该 tick 上会产生低于 1 个基础单位的输出，或溢出 u64）、InvalidTickIndex（超出 [MIN_TICK, MAX_TICK]，或在 tick_current 的错误一侧用于选定的方向）、TickAndSpacingNotMatch（tick_index % pool.tick_spacing != 0）、OrderPhaseSaturated。

`IncreaseLimitOrder`

添加到现有开放订单。仅由订单的 owner 调用。参数

amount: u64    // 额外的输入代币金额

账户 — 8 个，只有输入侧。它去掉了 nonce 账户、全部三个输出侧账户以及 system_program。

#	名称	W	S
1	`owner`		S
2	`pool_state`	W
3	`tick_array`	W
4	`limit_order`	W
5	`input_token_account`	W
6	`input_vault`	W
7	`input_vault_mint`
8	`input_token_program`

前置条件

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

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

#	名称	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 保管人想要滴流支付长期运行的部分填充时很有用。 调用者 — 订单的 owner，或程序的 limit_order_admin（运行自动保管人循环的离线操作热钱包）。保管人没有其他权限 — 它无法将用户资金移出推送已填充的输出到订单的 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		池输出保管库。
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`（管理员）

在 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	硬编码管理员公钥。
2	`dynamic_fee_config`	W		PDA，在此处 `init`。
3	`system_program`

常见错误 — 如果 decay_period <= filter_period 或任何 0 值字段超出范围，则 InvalidDynamicFeeConfigParams。

`UpdateDynamicFeeConfig`（管理员）

修改现有 DynamicFeeConfig。已在创建时快照配置的池不被追溯更新；仅引用此配置的新创建池将获取新值。参数 — 与 CreateDynamicFeeConfig 相同的五个校准字段（filter_period、decay_period、reduction_factor、dynamic_fee_control、max_volatility_accumulator）；index 在创建时固定，此处不重新传递。

`CollectProtocolFee` / `CollectFundFee`

将累积的协议/基金费用从池的保管库清扫给接收方，并把相应的 PoolState.protocol_fees_* / fund_fees_* 字段清零。这不是 CPMM 的布局 —— CLMM 没有 authority 账户，接收方字段命名为 recipient_token_account_{0,1}，而不是 recipient_token_{0,1}_account。参数 — amount_0_requested: u64、amount_1_requested: u64。

#	名称	W	S	备注
1	`owner`		S	`amm_config.owner`（基金变体则为 `amm_config.fund_owner`），或程序管理员；否则报 `NotApproved`。
2	`pool_state`	W
3	`amm_config`			`address = pool_state.amm_config`。
4	`token_vault_0`	W
5	`token_vault_1`	W
6	`vault_0_mint`
7	`vault_1_mint`
8	`recipient_token_account_0`	W
9	`recipient_token_account_1`	W
10	`token_program`
11	`token_program_2022`

`InitializeReward`

向池添加新的奖励流。最多 3 个流可能同时活跃。参数

pub struct InitializeRewardParam {
    pub open_time:                u64,
    pub end_time:                 u64,
    pub emissions_per_second_x64: u128,   // Q64.64
}

线路编码就是这三个字段依次排列，因此手工构建的指令不受影响 —— 但由 IDL 驱动的客户端必须传入一个 param 对象，而不是三个位置参数。账户

#	名称	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) 价值的奖励代币存入保管库。
按 operation_state 白名单的奖励铸币。

`SetRewardParams`

扩展、充值或更改现有奖励流的发放速率。通常由池创建者或 Raydium 多签调用。约束在链上：你通常可以扩展 end_time 或增加发放，而不是追溯缩小它们。检查 operation_state 的所有者列表。

`UpdateRewardInfos`

纯簿记 — 通过乘以 emissions_per_second × Δt / liquidity 将 reward_growth_global_x64 结算到当前时间。由每个接触流动性的指令在内部调用。作为独立指令公开，因为外部参与者（UI、cranks）有时想要触发它。

Collecting rewards

不存在独立的收取奖励指令。 程序没有暴露 CollectReward 入口点，公布的 IDL 里也没有。

头寸应得的奖励由 DecreaseLiquidity / DecreaseLiquidityV2 支付。要在不改变头寸的情况下收取，请以 liquidity = 0、amount_0_min = 0、amount_1_min = 0 调用它。奖励保管库和接收账户放在 remaining_accounts 中，每个活跃奖励三个一组，顺序为 reward_token_vault(W)、recipient_token_account(W)、reward_vault_mint。 CollectRemainingRewards 是另一回事：它让奖励的资金方在某个奖励流的 end_time 之后，清扫从未分配给任何头寸的代币。

状态变化矩阵

指令	`pool.liquidity`	`pool.fee_growth_global`	`pool.reward_growth_global`	`personal_position.liquidity`	Tick 数组
`CreatePool`	0	0	—	—	—
`OpenPosition`	+ 如果在范围内	—	—	新建	添加 liquidity_gross/net
`IncreaseLiquidity`	+ 如果在范围内	结算应付	结算应付	+	调整
`DecreaseLiquidity`	− 如果在范围内	结算应付	结算应付	−	调整
`ClosePosition`	—	—	—	销毁	—
`SwapV2`	± 在穿过时	+	—	—	穿过并翻转外部；匹配限价单队列
`OpenLimitOrder`	—	—	—	—	目标 tick 上 `orders_amount += amount`
`IncreaseLimitOrder`	—	—	—	—	`orders_amount += amount`
`DecreaseLimitOrder`	—	—	—	—	`orders_amount -=`，可能关闭队列
`SettleLimitOrder`	—	—	—	—	—（tick 上只读）
`CloseLimitOrder`	—	—	—	—	—
`CreateCustomizablePool`	0	0	—	—	—
`UpdateRewardInfos`	—	—	+	—	—

接下来去哪里

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

产品

算法

指令清单

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig`（管理员）

`UpdateDynamicFeeConfig`（管理员）

`CollectProtocolFee` / `CollectFundFee`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

状态变化矩阵

接下来去哪里

​指令清单

​CreatePool

​CreateCustomizablePool

​CreatePermissionedPool

​OpenPositionV2 / OpenPositionWithToken22Nft

​IncreaseLiquidityV2

​DecreaseLiquidityV2

​ClosePosition

​SwapV2

​OpenLimitOrder

​IncreaseLimitOrder

​DecreaseLimitOrder

​SettleLimitOrder

​CloseLimitOrder

​CreateDynamicFeeConfig（管理员）

​UpdateDynamicFeeConfig（管理员）

​CollectProtocolFee / CollectFundFee

​InitializeReward

​SetRewardParams

​UpdateRewardInfos

​Collecting rewards

​状态变化矩阵

​接下来去哪里

指令清单

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig`（管理员）

`UpdateDynamicFeeConfig`（管理员）

`CollectProtocolFee` / `CollectFundFee`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

状态变化矩阵

接下来去哪里