CLMM 指令

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

本页与 products/clmm/accounts（账户是什么）和 products/clmm/math（数学是什么）配套。它是参数和账户顺序的权威参考；具体的字节布局来自 IDL。2026-09 程序升级在 Anchor 1.0.2 / Solana 3.1.10 上重建了 CLMM，添加了管理员指令 CollectExcessLamports，并改变了 CreateAmmConfig 写入 owner / fund_owner 的内容。没有用户面向的指令改变了其账户、参数或数学。参见 2026-09-30 更新日志条目。

指令清单

分组	指令	说明
管理员	`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` 注册并退款其租金。
管理员	`CollectExcessLamports`	从一个池的 `PoolState` 和保管库中清理超过租金豁免最低限额的 lamports，加上任何传入的 CLMM 拥有的 PDA。`admin` 或专用的清理 lamports 钱包。添加于 2026-09。

没有初始化 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 公钥或专用的支持铸币所有者密钥；CollectExcessLamports 接受 admin 公钥或专用的清理 lamports 钱包。奖励流管理员指令（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，任何传入的都仅被扫描以查找支持铸币记录。 后置条件

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

账户 — 两个变体有不同的账户列表。OpenPositionV2 声明 22；OpenPositionWithToken22Nft 声明 20。 OpenPositionV2，按顺序：

#	名称	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 匹配。参见 PoolState 上的 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：用 token1 卖 token0；false：用 token0 卖 token1
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`

在 2026-09 中更改：新配置不再从签署者获取其费用所有者。 create_amm_config 现在将程序的硬编码 protocol_fee_owner::ID 写入 owner 并将 fund_fee_owner::ID 写入 fund_owner。之前，它将管理员签署者的密钥复制到两者。在主网上，这些已经是存储在所有 21 个现有配置上的相同密钥。地址在 reference/program-addresses 中。上面接受的签署者未改变。管理员仍可以从任何配置收集，现有的 AmmConfig 账户不被重写。从账户读取 owner / fund_owner 而不是假设任一值。UpdateAmmConfig 参数 3 和 4 仍然轮换它们。

`CollectExcessLamports`

管理员清理 CLMM 控制的账户上超过租金豁免最低限额的 lamports。它在 2026-09 升级中添加，以回收 SIMD-0437 租金减少在每个步骤之前创建的账户上留下的过度资金。仅多余部分移动。代币余额、账户数据、所有者、池状态和价格曲线保持不变。已在其最低限额的账户保持原样，因此指令可以在每个推出步骤后安全地重新运行。参数：无。账户

#	名称	W	S	说明
1	`collect_lamports_wallet`	W	S	接收每个清理的 lamport。必须是 CLMM 程序管理员或专用的清理 lamports 钱包（参见 `reference/program-addresses`）。任何其他签署者失败，出现 `NotApproved`。
2	`pool_state`	W		被清理的池。其 PDA 种子签署代币程序 CPI，账户始终被清理自己。
3	`token_program`			SPL Token。
4	`token_program_2022`			Token-2022。两个程序都需要；指令为每个源账户选择一个。
5..	`remaining_accounts`	W		`M` 个源账户，任意数量，任意顺序。

范围：每次调用一个池。 CLMM 没有程序范围的保管库权限。每个池的保管库由其自己的 PoolState 拥有。每个代币程序源必须因此在槽 2 处有 pool_state 作为其权限：token_vault_0、token_vault_1 或该池的奖励保管库之一。如果你传递另一个池的保管库或用户的代币账户，代币程序的所有者检查失败，整个指令恢复。它不被跳过。头寸 NFT 铸币无法被清理，因为当头寸打开时其铸币权限被撤销。 每个源账户如何处理 程序对 remaining_accounts 进行两次传递：首先是每个代币程序 CPI，然后是直接借记。交错两者会中止运行时的 UnbalancedInstruction 错误，因此顺序在程序中是固定的，你不必自己排序列表。

传递	源账户所有者	处理
1	SPL Token 或 Token-2022，非本地代币账户	C

产品

算法

指令清单

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig`（管理员）

`UpdateDynamicFeeConfig`（管理员）

`CollectProtocolFee` / `CollectFundFee`

`CollectExcessLamports`

​指令清单

​CreatePool

​CreateCustomizablePool

​CreatePermissionedPool

​OpenPositionV2 / OpenPositionWithToken22Nft

​IncreaseLiquidityV2

​DecreaseLiquidityV2

​ClosePosition

​SwapV2

​OpenLimitOrder

​IncreaseLimitOrder

​DecreaseLimitOrder

​SettleLimitOrder

​CloseLimitOrder

​CreateDynamicFeeConfig（管理员）

​UpdateDynamicFeeConfig（管理员）

​CollectProtocolFee / CollectFundFee

​CollectExcessLamports

指令清单

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig`（管理员）

`UpdateDynamicFeeConfig`（管理员）

`CollectProtocolFee` / `CollectFundFee`

`CollectExcessLamports`