CLMM 指令

完整的 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 變更日誌條目。

2026-10-22 程式升級將 CreatePermissionedPool 重新命名為 CreateCustomizablePoolV2，使其可由任何人呼叫，並移除了 Permission 帳戶及其兩個管理員指令。請參閱 2026-10-22 變更日誌條目。

​

指令清單

分類	指令	說明
管理員	CreateAmmConfig	定義新的費用層級。
管理員	UpdateAmmConfig	變更現有層級的費率。
管理員	UpdatePoolStatus	暫停/恢復池上的操作。
管理員	CreateSupportMintAssociated	允許列表一個 Token-2022 鑄幣擴展設定以供 CLMM 池使用。
管理員	CreateOperationAccount	初始化程式級操作帳戶（一次性）。
管理員	UpdateOperationAccount	修改操作帳戶白名單。
管理員	CreateDynamicFeeConfig	在 u16 索引下建立可重複使用的動態費用參數集。
管理員	UpdateDynamicFeeConfig	修改現有的 DynamicFeeConfig。已快照的池不受影響。
池	CreatePool	初始化綁定到 AmmConfig 的 CLMM 池。標準、FromInput 費用路徑。與 CreateCustomizablePool 共存。
池	CreateCustomizablePool	推薦用於新池。與 CreatePool 形狀相同，加上 collect_fee_on 和可選的 enable_dynamic_fee 標誌。
池	CreateCustomizablePoolV2	為已有一個池的交易對和費用層級建立額外池，使用客戶端提供的非零 seed_index 折疊到池 PDA 中。無需許可。2026-10-22 之前稱為 CreatePermissionedPool。
頭寸	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 和保管庫掃描超過租金豁免最低限額的 lamport，加上傳入的任何 CLMM 擁有的 PDA。admin 或專用的收集 lamport 錢包。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 公鑰把守。CreateSupportMintAssociated / CloseSupportMintAssociated 接受 admin 公鑰或專用的支援鑄幣所有者金鑰；CollectExcessLamports 接受 admin 公鑰或專用的收集 lamport 錢包。獎勵流管理員指令（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		在此初始化。
4	token_mint_0			已排序。
5	token_mint_1
6	token_vault_0	W		在此初始化，由池權限 PDA 擁有。
7	token_vault_1	W
8	observation_state	W		在此初始化。
9	tick_array_bitmap	W		TickArrayBitmapExtension PDA；在此初始化。
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 和 CreateCustomizablePoolV2 使用相同的兩個槽。

前置條件

• 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 建立的池無法追溯獲得動態費用或單邊費用。新部署應預設為此指令。

​

CreateCustomizablePoolV2

CreatePool 和 CreateCustomizablePool 都從 ["pool", amm_config, token_mint_0, token_mint_1] 推導池 PDA，因此每個 (config, mint0, mint1) 三元組恰好有一個規範池位址——在相同種子上的第二次 init 會失敗。CreateCustomizablePoolV2 透過將客戶端提供的 seed_index: u16 折疊到池 PDA 種子中來解除此限制，允許同一交易對和費用層級的多個池——每個都在自己的位址上。任何人都可以呼叫它。

池的其他所有方面都與 CreateCustomizablePool 相同：它採用相同的 CreateCustomizableParams 並支援單邊費用和動態費用選擇加入。

在 2026-10-22 升級 之前，此指令稱為 CreatePermissionedPool，需要支付者持有管理員簽發的 Permission PDA。升級後重新命名，移除了 permission 帳戶並刪除了權限機制。判別器隨著名稱改變，因此針對 CreatePermissionedPool 構建的客戶端必須重新構建。

引數

customizable_params: CreateCustomizableParams   // 與 CreateCustomizablePool 相同的結構
seed_index:          u16                          // 必須非零；折疊到池 PDA 種子中

帳戶

#	名稱	W	S	備註
1	payer	W	S	為每個新帳戶支付租金。任何錢包。
2	pool_creator			記錄為 pool_state.owner。可能與 payer 不同。不是簽署者且未檢查。
3	amm_config			池綁定的費用層級。
4	pool_state	W		init 在 ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]。
5	token_mint_0			必須在 token_mint_1 之前排序。
6	token_mint_1
7	token_vault_0	W		PDA ["pool_vault", pool_state, token_mint_0]。
8	token_vault_1	W		PDA ["pool_vault", pool_state, token_mint_1]。
9	observation_state	W		PDA ["observation", pool_state]。
10	tick_array_bitmap	W		PDA ["pool_tick_array_bitmap_extension", pool_state]。
11	token_program_0			擁有 token_mint_0 的程式。
12	token_program_1			擁有 token_mint_1 的程式。
13	system_program
14	rent

remaining_accounts：Token-2022 mint 需要時的支援 mint 登錄 PDA，以及當 enable_dynamic_fee = true 時最後的 DynamicFeeConfig——如同 CreateCustomizablePool。

前置條件

• seed_index != 0。seed_index 為 0 保留給舊版池，此處會被拒絕；[0, 0] 種子元件是使舊版池位址崩潰為經典四種子形式的原因。
• 在推導位址上不存在池。
• 與 CreatePool 相同的 mint/允許清單規則。

後置條件

• 新的 pool_state 存在於 seed_index 推導的位址，其中 pool_state.seed_index = seed_index。
• 所有其他後狀態與 CreateCustomizablePool 相符（費用模式、可選動態費用）。

因為 pool_creator 未檢查，任何支付者都可以將任何位址寫入 pool_state.owner。該位址可以在池上呼叫 InitializeReward，但這不是誰建立池的證明。整合者不應按其 owner 標籤或排名 V2 池。

​

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 mint 上的 Token-2022 中繼資料擴充寫入位置的中繼資料——給出 20 個帳戶。其 position_nft_mint 是裸 Signer，position_nft_account 是 UncheckedAccount。

tick_array_bitmap_extension 不是任一變體上的宣告帳戶。 當位置的範圍落在池的內聯 tick_array_bitmap（±512 tick 陣列）之外時，將 TickArrayBitmapExtension PDA 附加在種子 ["pool_tick_array_bitmap_extension", pool_state] 作為 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 mint 記錄 pool_state 作為凍結授權。在鑄造單個 NFT 後移除 mint 授權。記錄凍結授權不會改變 NFT 代幣帳戶的狀態。
• NFT 代幣帳戶保持未凍結，除非指令是 OpenPositionV2 或 OpenPositionWithToken22Nft且任一保管庫 mint 的凍結授權與 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 年後發佈）：

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。請參閱 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，在此初始化。
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 控制的帳戶上超過租金豁免最低額的 lamport。它在 2026-09 升級中新增，以回收 SIMD-0437 租金減少 在每個步驟之前建立的帳戶上留下的過度資金。

只有超額部分移動。代幣餘額、帳戶資料、所有者、資金池狀態和價格曲線保持不變。已在最低額的帳戶保持原樣，因此在每次推出步驟後可以安全地重新執行指令。

引數：無。

帳戶

#	名稱	W	S	備註
1	collect_lamports_wallet	W	S	接收每個掃除的 lamport。必須是 CLMM 程式管理員或專用收集 lamport 錢包（見 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，非原生代幣帳戶	CPI WithdrawExcessLamports（代幣程式判別式 38），由 pool_state 簽署。
1	SPL Token 或 Token-2022，原生（wSOL）代幣帳戶	WithdrawExcessLamports 拒絕原生帳戶。程式 CPI SyncNative，測量包裝的 amount 增長了多少，並為該確切差額呼叫 UnwrapLamports（判別式 45）。然後它要求包裝的餘額等於其預同步值，否則失敗並顯示 LamportsCalculateError（6052）。SOL 端資金池金庫保持其完整流動性。
2	pool_state（位置 2）	直接扣款至 rent.minimum_balance(data_len)。
2	CLMM 程式：AmmConfig、ObservationState、TickArrayBitmapExtension、TickArrayState、PersonalPositionState、LimitOrderState 等	直接扣款至 rent.minimum_balance(data_len)。帳戶不必屬於位置 2 中的資金池。
—	其他任何內容	靜默跳過。 無錯誤，無 lamport 移動。

傳遞 2 涵蓋使用者支付租金的帳戶。 此處傳遞的 PersonalPositionState 或 LimitOrderState 像任何其他 CLMM 擁有的帳戶一樣放棄其超額。它保持租金豁免並保留其資料。當它稍後被關閉時，所有者取回帳戶此時持有的任何內容，掃除後是當前租金最低額。

交易大小是對一次呼叫中有多少來源適配的真實限制。這與 solana-fundamentals/rent-and-reclaimable-rent 中描述的錢包端掃除的約束相同。

常見錯誤：

• NotApproved（6000）：錯誤的簽署者。
• LamportsCalculateError（6052）：wSOL 往返沒有淨化為零。
• 代幣程式所有者不匹配錯誤：代幣來源不由 pool_state 擁有。
• InsufficientFunds：程式擁有的帳戶持有少於其自身租金最低額。

無 SDK 建構器。 @raydium-io/raydium-sdk-v2 不提供此管理員路徑的建構器。從 IDL 手動編碼。

​

InitializeReward

向資金池新增新的獎勵流。最多 3 個流可同時活躍。

引數 — 單個結構體，param: InitializeRewardParam：

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		在此初始化。
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、crank）有時想要觸發它。

​

收集獎勵

沒有獨立的收集獎勵指令。 程式不公開 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	—	—	+	—	—
CollectExcessLamports	—	—	—	—	—（僅 lamports；代幣餘額不變）

​

後續步驟

• 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