Hướng dẫn CLMM

Tham khảo đầy đủ về hướng dẫn CLMM: vòng đời pool, quản lý vị trí, swap và luồng phần thưởng.

Trang này được dịch tự động bằng AI. Phiên bản tiếng Anh là bản chính thức.

Xem bản tiếng Anh →

Trang này kết hợp với products/clmm/accounts (các tài khoản là gì) và products/clmm/math (toán học là gì). Nó là tài liệu chính thức cho các đối số và thứ tự tài khoản; bố cục byte cụ thể đến từ IDL.

Nâng cấp chương trình 2026-09 đã xây dựng lại CLMM trên Anchor 1.0.2 / Solana 3.1.10, thêm hướng dẫn admin CollectExcessLamports, và thay đổi những gì CreateAmmConfig ghi vào owner / fund_owner. Không có hướng dẫn nào hướng tới người dùng thay đổi tài khoản, đối số hoặc toán học của nó. Xem mục nhập changelog 2026-09-30.

Nâng cấp chương trình 2026-10-22 đổi tên CreatePermissionedPool thành CreateCustomizablePoolV2, làm cho nó có thể gọi được bởi bất kỳ ai, và loại bỏ tài khoản Permission với hai hướng dẫn admin của nó. Xem mục nhập changelog 2026-10-22.

​

Danh sách hướng dẫn

Nhóm	Hướng dẫn	Ghi chú
Admin	CreateAmmConfig	Xác định một mức phí mới.
Admin	UpdateAmmConfig	Thay đổi tỷ lệ trên một mức phí hiện có.
Admin	UpdatePoolStatus	Tạm dừng/tiếp tục hoạt động trên một pool.
Admin	CreateSupportMintAssociated	Cho phép danh sách cấu hình phần mở rộng mint Token-2022 để sử dụng trong các pool CLMM.
Admin	CreateOperationAccount	Khởi tạo tài khoản hoạt động cấp chương trình (một lần).
Admin	UpdateOperationAccount	Sửa đổi danh sách trắng tài khoản hoạt động.
Admin	CreateDynamicFeeConfig	Tạo một bộ tham số phí động có thể tái sử dụng dưới một chỉ mục u16.
Admin	UpdateDynamicFeeConfig	Sửa đổi một DynamicFeeConfig hiện có. Các pool đã chụp nó không bị ảnh hưởng.
Pool	CreatePool	Khởi tạo một pool CLMM được liên kết với một AmmConfig. Đường dẫn phí tiêu chuẩn, FromInput. Tồn tại cùng với CreateCustomizablePool.
Pool	CreateCustomizablePool	Được khuyến nghị cho các pool mới. Cùng hình dạng với CreatePool cộng với collect_fee_on và một cờ enable_dynamic_fee tùy chọn.
Pool	CreateCustomizablePoolV2	Tạo một pool bổ sung cho một cặp và mức phí đã có một, sử dụng seed_index khác không do khách hàng cung cấp được gấp vào pool PDA. Không cần phép. Được gọi là CreatePermissionedPool trước 2026-10-22.
Vị trí	OpenPosition / OpenPositionV2 / OpenPositionWithToken22Nft	Mint một NFT vị trí. OpenPositionV2 thay thế V1; OpenPositionWithToken22Nft phát hành NFT dưới dạng Token-2022. Các đường dẫn V2 đóng băng tài khoản NFT chỉ khi quyền đóng băng mint kho lưu trữ cơ bản khớp với danh sách nhà phát hành bị hạn chế. Nếu không, tài khoản vẫn không bị đóng băng.
Vị trí	IncreaseLiquidity / IncreaseLiquidityV2	Thêm thanh khoản vào một vị trí hiện có.
Vị trí	DecreaseLiquidity / DecreaseLiquidityV2	Loại bỏ thanh khoản; thu thập phí nợ.
Vị trí	ClosePosition	Đốt NFT và đóng PersonalPositionState. Nếu tài khoản NFT bị đóng băng, trước tiên hãy rã đông nó với pool PDA được cung cấp dưới dạng tài khoản còn lại.
Vị trí	CloseProtocolPosition	Quét chỉ dành cho admin cho các PDA ProtocolPositionState kế thừa. Chương trình hiện tại không còn tạo hoặc đọc ProtocolPositionState — hướng dẫn này chỉ tồn tại để lấy lại tiền thuê trên các tài khoản được tạo bởi các phiên bản chương trình cũ hơn.
Swap	Swap / SwapV2	Swap thanh khoản không đổi. Cả hai biến thể áp dụng phí động, định tuyến phí một chiều và khớp lệnh giới hạn; sự khác biệt duy nhất là SwapV2 chấp nhận mint Token-2022 (biến thể V1 yêu cầu cả hai kho lưu trữ là SPL Token cổ điển).
Swap	SwapRouterBaseIn	Nhiều bước, được sử dụng bởi bộ định tuyến.
Lệnh giới hạn	OpenLimitOrder	Đặt lệnh bán ở một tick. Các token chưa được điền nằm trên tick; công cụ khớp điền chúng khi giá vượt qua.
Lệnh giới hạn	IncreaseLimitOrder	Thêm vào một lệnh mở hiện có.
Lệnh giới hạn	DecreaseLimitOrder	Giảm hoặc hủy một lệnh mở; trả lại phần còn lại chưa được điền cộng với bất kỳ đầu ra nào đã được giải quyết.
Lệnh giới hạn	SettleLimitOrder	Đẩy các token đầu ra đã điền cho chủ sở hữu lệnh. Có thể gọi bởi chủ sở hữu hoặc bởi người giữ hoạt động.
Lệnh giới hạn	CloseLimitOrder	Đóng một tài khoản lệnh được tiêu thụ hoàn toàn. Tiền thuê luôn quay trở lại owner của lệnh. Có thể gọi bởi chủ sở hữu hoặc người giữ.
Phí	CollectProtocolFee	Quét phí giao thức chỉ dành cho admin.
Phí	CollectFundFee	Quét phí quỹ chỉ dành cho admin.
Phần thưởng	InitializeReward	Gắn một luồng phần thưởng mới vào một pool.
Phần thưởng	SetRewardParams	Thay đổi tỷ lệ phát hành/kết thúc phần thưởng hiện có.
Phần thưởng	UpdateRewardInfos	Giải quyết tăng trưởng phần thưởng cho đến bây giờ (được gọi bởi bất kỳ swap / thay đổi vị trí nào).
Phần thưởng	TransferRewardOwner	Chuyển quyền có thể đặt hoặc bổ sung một luồng phần thưởng.
Phần thưởng	CollectRemainingRewards	Sau end_time của luồng phần thưởng, quét bất kỳ token chưa được phân bổ nào trở lại cho người tài trợ.
Admin	CloseSupportMintAssociated	Loại bỏ đăng ký SupportMintAssociated của một mint và hoàn lại tiền thuê của nó.
Admin	CollectExcessLamports	Quét lamport vượt quá mức tối thiểu miễn phí tiền thuê từ PoolState và kho lưu trữ của một pool, cộng với bất kỳ PDA nào do CLMM sở hữu được truyền vào. admin hoặc ví thu thập lamport chuyên dụng. Được thêm vào 2026-09.

Không có hướng dẫn khởi tạo tick array, và không cần hướng dẫn nào. Một tick array được tạo bên trong OpenPosition* / IncreaseLiquidity* bởi TickArrayState::get_or_create_tick_array, được thanh toán bởi payer. Truyền PDA tick-array (có thể vẫn chưa được khởi tạo, do hệ thống sở hữu) dưới dạng tick_array_lower / tick_array_upper và chương trình phân bổ nó nếu nó bị thiếu. OpenLimitOrder làm tương tự cho tick_array duy nhất của nó.

Hầu hết các hướng dẫn chỉ dành cho admin (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) được kiểm soát bởi khóa admin được mã hóa cứng của chương trình. CreateSupportMintAssociated / CloseSupportMintAssociated chấp nhận khóa admin hoặc khóa chủ sở hữu support-mint chuyên dụng; CollectExcessLamports chấp nhận khóa admin hoặc ví thu thập lamport chuyên dụng. Các hướng dẫn admin luồng phần thưởng (TransferRewardOwner, CollectRemainingRewards) được kiểm soát bởi người tài trợ phần thưởng, không phải admin chương trình.

Hậu tố V2 có nghĩa là “hỗ trợ Token-2022 trên kho lưu trữ / NFT, yêu cầu khe bitmap-extension”. SDK chọn V2 theo mặc định cho các pool mới.

​

CreatePool

Đối số

sqrt_price_x64: u128           // giá ban đầu
open_time:      u64            // swap bị từ chối trước thời gian này

Tài khoản (tóm tắt)

#	Tên	W	S	Ghi chú
1	pool_creator	W	S
2	amm_config			Mức phí được chọn.
3	pool_state	W		init ở đây.
4	token_mint_0			Được sắp xếp.
5	token_mint_1
6	token_vault_0	W		init ở đây, được sở hữu bởi pool authority PDA.
7	token_vault_1	W
8	observation_state	W		init ở đây.
9	tick_array_bitmap	W		PDA TickArrayBitmapExtension; init ở đây.
10	token_program_0			Chương trình sở hữu token_mint_0 — SPL Token hoặc Token-2022.
11	token_program_1			Chương trình sở hữu token_mint_1.
12	system_program
13	rent

Các khe 10 và 11 là theo mint, không phải “SPL Token rồi Token-2022”. Mỗi cái được ràng buộc bởi mint::token_program trên mint phù hợp, vì vậy đối với một pool có token_mint_0 là Token-2022 và token_mint_1 là SPL cổ điển, bạn phải truyền Token-2022 vào khe 10 và SPL Token vào khe 11. CreateCustomizablePool và CreateCustomizablePoolV2 sử dụng cùng hai khe.

Điều kiện tiên quyết

• token_mint_0 < token_mint_1 theo thứ tự byte.
• amm_config.disable_create_pool == false.
• Các mint không bị từ chối bởi danh sách cho phép phần mở rộng Token-2022.

Điều kiện sau

• pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
• pool_state.liquidity = 0 (chưa có vị trí nào).
• pool_state.fee_on = FromInput (mặc định kế thừa).
• pool_state.dynamic_fee_info được đặt thành 0 (phí động bị vô hiệu hóa).

​

CreateCustomizablePool

Được khuyến nghị cho các pool mới. Cùng hiệu ứng với CreatePool cộng với chế độ thu thập phí theo pool và tùy chọn phí động tùy chọn.

Đối số

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

Tài khoản — chính xác 13 tài khoản được khai báo của CreatePool. dynamic_fee_config không phải là một tài khoản được khai báo.

Khi enable_dynamic_fee = true, DynamicFeeConfig để chụp phải được cung cấp dưới dạng cuối cùng remaining_account — trình xử lý đọc ctx.remaining_accounts.last(). Bất kỳ PDA bỏ qua SupportMintAssociated nào phải do đó đến trước nó, hoặc chương trình chụp tài khoản sai và không thành công trong deserialization. Bỏ qua nó trong khi cờ được đặt thất bại với AccountLack.

Điều kiện tiên quyết — giống như CreatePool. Nếu enable_dynamic_fee = false, không cần remaining_account và bất kỳ cái nào được truyền chỉ được quét để tìm các bản ghi support-mint.

Điều kiện sau

• pool_state.fee_on được đặt thành biến thể CollectFeeOn được chọn.
• Nếu phí động được bật: pool_state.dynamic_fee_info được khởi tạo từ DynamicFeeConfig được cung cấp (năm tham số hiệu chỉnh được sao chép; các trường trạng thái được đặt thành 0).
• Nếu không: pool_state.dynamic_fee_info được đặt thành 0 (= phí động không hoạt động mãi mãi cho pool này).

fee_on và bit bật phí động được đặt chỉ khi tạo pool. Không có nâng cấp tại chỗ — các pool được tạo thông qua CreatePool kế thừa không thể có được phí động hoặc phí một chiều một cách hồi tưởng. Các triển khai mới nên mặc định cho hướng dẫn này.

​

CreateCustomizablePoolV2

Cả CreatePool và CreateCustomizablePool đều dẫn xuất pool PDA từ ["pool", amm_config, token_mint_0, token_mint_1], vì vậy chỉ có một địa chỉ pool chính tắc cho mỗi bộ ba (config, mint0, mint1) — một lần init thứ hai tại cùng seeds sẽ thất bại. CreateCustomizablePoolV2 loại bỏ hạn chế này bằng cách gộp seed_index: u16 do client cung cấp vào seeds của pool PDA, cho phép nhiều pool cho cùng một cặp và mức phí — mỗi pool tại địa chỉ riêng của nó. Bất kỳ ai cũng có thể gọi nó.

Mọi thứ khác về pool đều giống với CreateCustomizablePool: nó nhận cùng CreateCustomizableParams và hỗ trợ phí một phía cũng như tùy chọn phí động.

Cho đến bản nâng cấp 2026-10-22, instruction này được gọi là CreatePermissionedPool và yêu cầu người trả phí phải giữ một PDA Permission do admin phát hành. Bản nâng cấp đã đổi tên nó, loại bỏ tài khoản permission và xóa cơ chế quyền hạn. Discriminator đã thay đổi theo tên, vì vậy các client được xây dựng dựa trên CreatePermissionedPool phải được xây dựng lại.

Arguments

customizable_params: CreateCustomizableParams   // same struct as CreateCustomizablePool
seed_index:          u16                          // must be non-zero; folded into the pool PDA seeds

Accounts

#	Name	W	S	Notes
1	payer	W	S	Trả tiền thuê cho mỗi tài khoản mới. Bất kỳ ví nào.
2	pool_creator			Được ghi lại là pool_state.owner. Có thể khác với payer. Không phải là signer và không được kiểm tra.
3	amm_config			Mức phí mà pool liên kết.
4	pool_state	W		init tại ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()].
5	token_mint_0			Phải sắp xếp trước 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			Chương trình sở hữu token_mint_0.
12	token_program_1			Chương trình sở hữu token_mint_1.
13	system_program
14	rent

remaining_accounts: các PDA của registry support-mint khi một mint Token-2022 cần chúng, và DynamicFeeConfig cuối cùng khi enable_dynamic_fee = true — như trong CreateCustomizablePool.

Preconditions

• seed_index != 0. Một seed_index bằng 0 được dành riêng cho các pool cũ và bị từ chối ở đây; thành phần seed [0, 0] là điều làm cho địa chỉ pool cũ sụp đổ thành dạng bốn seed cổ điển.
• Không có pool nào tồn tại tại địa chỉ được dẫn xuất.
• Các quy tắc mint / allow-list giống như CreatePool.

Postconditions

• Một pool_state mới tồn tại tại địa chỉ được dẫn xuất từ seed_index, với pool_state.seed_index = seed_index.
• Tất cả các postcondition khác khớp với CreateCustomizablePool (chế độ phí, phí động tùy chọn).

Vì pool_creator không được kiểm tra, bất kỳ người trả phí nào cũng có thể ghi bất kỳ địa chỉ nào vào pool_state.owner. Địa chỉ đó có thể gọi InitializeReward trên pool, nhưng nó không phải là bằng chứng về ai đã tạo pool. Các integrator không nên gắn nhãn hoặc xếp hạng các pool V2 theo owner của chúng.

​

OpenPositionV2 / OpenPositionWithToken22Nft

Tạo một vị trí mới bên trong một pool hiện có.

Arguments

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // desired L (or 0 to use amounts below)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // write NFT metadata (Metaplex)
base_flag: Option<bool>       // true = fit to amount0; false = fit to amount1

Accounts — hai biến thể có danh sách tài khoản khác nhau. OpenPositionV2 khai báo 22; OpenPositionWithToken22Nft khai báo 20.

OpenPositionV2, theo thứ tự:

#	Name	W	S	Notes
1	payer	W	S
2	position_nft_owner
3	position_nft_mint	W	S	Keypair mới.
4	position_nft_account	W		ATA của chủ sở hữu cho NFT.
5	metadata_account	W		PDA metadata Metaplex. Được khai báo vô điều kiện, ngay cả khi with_metadata = false.
6	pool_state	W
7	protocol_position			Cổ điển; UncheckedAccount chỉ đọc.
8	tick_array_lower	W		Được tạo ở đây nếu chưa được khởi tạo.
9	tick_array_upper	W		Tương tự.
10	personal_position	W		Được tạo ở đây.
11	token_account_0	W		ATA nguồn của người dùng.
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 là danh sách tương tự với metadata_account (5) và metadata_program (19) bị loại bỏ — nó ghi metadata của vị trí thông qua phần mở rộng metadata Token-2022 trên mint NFT thay thế — cho 20 tài khoản. position_nft_mint của nó là một Signer đơn thuần và position_nft_account là một UncheckedAccount.

tick_array_bitmap_extension không phải là một tài khoản được khai báo trên bất kỳ biến thể nào. Khi phạm vi của vị trí nằm ngoài tick_array_bitmap nội tuyến của pool (±512 tick arrays), hãy thêm PDA TickArrayBitmapExtension tại seeds ["pool_tick_array_bitmap_extension", pool_state] dưới dạng remaining_accounts[0].

Math — xem products/clmm/math. Với base_flag, chương trình giải quyết liquidity hoặc (amount_0_max, amount_1_max) thành L thực tế và số lượng token thực tế được tiêu thụ.

Preconditions

• tick_lower < tick_upper, cả hai đều là bội số của pool.tick_spacing, trong [MIN_TICK, MAX_TICK].
• Hai PDA tick-array được truyền. Chúng không cần đã tồn tại — get_or_create_tick_array cấp phát một PDA bị thiếu tại chi phí của payer bên trong instruction này. Không có instruction init-tick-array riêng biệt.
• Người dùng có ít nhất amount_0_max và amount_1_max trong các ATA nguồn.

Postconditions

• personal_position tồn tại, liquidity được đặt, fee_growth_inside_last được chụp nhanh.
• Các mục tick-array tại tick_lower và tick_upper được cập nhật (liquidity_gross += L, liquidity_net ± L, các bản chụp nhanh tăng trưởng phí được duy trì).
• pool_state.liquidity += L nếu vị trí nằm trong phạm vi (tick_lower ≤ tick_current < tick_upper).
• Mint NFT của vị trí ghi lại pool_state là freeze authority. Mint authority bị loại bỏ sau khi NFT duy nhất được mint. Ghi lại freeze authority không thay đổi trạng thái của tài khoản token NFT.
• Tài khoản token NFT vẫn không bị đóng băng trừ khi instruction là OpenPositionV2 hoặc OpenPositionWithToken22Nft và freeze authority của mint vault khớp với danh sách restricted-issuer của CLMM. Chỉ đường dẫn V2 khớp đó mới đóng băng tài khoản. OpenPosition V1 không đóng băng.

Common errors — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (một điểm cuối không phải là bội số của tick_spacing), InvalidTickIndex (ngoài [MIN_TICK, MAX_TICK]), MissingTickArrayBitmapExtensionAccount (phạm vi ngoài bitmap nội tuyến và phần mở rộng không được thêm), NotApproved (pool_state.status chặn việc mở), ZeroAmountSpecified.

Đóng băng vị trí không thêm các tài khoản instruction được khai báo hoặc các argument. Các client có thể mở các vị trí này với các bố cục V2 hiện có. Hành vi được chọn on-chain từ vault_0_mint và vault_1_mint.

​

IncreaseLiquidityV2

Thêm liquidity vào một vị trí đã mở.

Arguments

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

Accounts — 15, và không có thể dẫn xuất từ OpenPosition: không có rent, không có system_program, không có associated_token_program và không có metadata account.

#	Name	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

Thêm PDA TickArrayBitmapExtension vào đầu remaining_accounts[0] khi phạm vi của vị trí nằm ngoài bitmap nội tuyến.

Effect

• Chuyển amount_0_actual / amount_1_actual từ người dùng → vaults.
• Tăng personal_position.liquidity và pool_state.liquidity (nếu nằm trong phạm vi), và liquidity_gross / liquidity_net của tick điểm cuối tương ứng.
• Thu thập phí và phần thưởng nợ kể từ lần chạm cuối cùng và ghi có chúng vào token_fees_owed_{0,1} / reward_amount_owed. Những khoản này chỉ được thanh toán trên DecreaseLiquidity / DecreaseLiquidityV2, không phải trên increase — không có instruction collect riêng biệt.

​

DecreaseLiquidityV2

Loại bỏ liquidity từ một vị trí.

Arguments

liquidity: u128
amount_0_min: u64
amount_1_min: u64

Accounts — 16, và không có cùng hình dạng hoặc thứ tự như IncreaseLiquidityV2: personal_position và pool_state được hoán đổi, các vault đến trước các tick arrays, các tài khoản phía người dùng được đặt tên là recipient_token_account_*, và có một memo_program bổ sung.

#	Name	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

Remaining accounts — ba cho mỗi reward đang hoạt động được thu thập, theo thứ tự reward_token_vault(W), recipient_token_account(W), reward_vault_mint. Thêm PDA TickArrayBitmapExtension vào đầu khi phạm vi của vị trí nằm ngoài bitmap nội tuyến.

Đây cũng là cách duy nhất để thu thập phí và phần thưởng. Để thu thập mà không thay đổi vị trí, hãy gọi nó với liquidity = 0, amount_0_min = 0, amount_1_min = 0.

Effect

• Tính toán (amount_0, amount_1) cho L bị loại bỏ với sqrt_price_x64 hiện tại.
• Giải quyết phí/phần thưởng tích lũy kể từ lần chạm cuối cùng, giống như IncreaseLiquidity.
• Chuyển amount_0 + fees_owed_0 và amount_1 + fees_owed_1 ra khỏi vaults cho người dùng.
• Giảm các bộ đếm liquidity; nếu personal_position.liquidity mới == 0, vị trí đủ điều kiện cho ClosePosition.

Slippage — amount_0_min và amount_1_min là mức tối thiểu mà người dùng chấp nhận sau khi trừ phí chuyển Token-2022 ở phía đầu ra.

​

ClosePosition

Đốt NFT vị trí và đóng PersonalPositionState.

Các tài khoản được khai báo

#	Tên	W	S	Ghi chú
1	nft_owner	W	S	Phải sở hữu tài khoản token NFT chứa số lượng 1.
2	position_nft_mint	W		Phải khớp với personal_position.nft_mint.
3	position_nft_account	W		Tài khoản của chủ sở hữu NFT; có thể là SPL Token cổ điển hoặc Token-2022.
4	personal_position	W		Đóng cho nft_owner.
5	system_program			Đóng trạng thái vị trí.
6	token_program			Phải sở hữu mint NFT và tài khoản token.

Các tài khoản còn lại

• NFT chưa bị đóng băng: không cần; một tài khoản pool bổ sung là vô hại vì trình xử lý không đọc nó.
• NFT bị đóng băng: thêm personal_position.pool_id làm tài khoản còn lại đầu tiên. Chương trình tải nó dưới dạng PoolState và sử dụng các seed PDA của nó để ký vào thao tác rã đông.

Điều kiện tiên quyết

• personal_position.liquidity == 0.
• tokens_fees_owed_{0,1} == 0.
• Tất cả các bộ đếm phần thưởng reward_amount_owed == 0.

(Tức là, thu thập mọi thứ và giảm xuống không trước tiên.)

Hiệu ứng

• Nếu tài khoản token NFT bị đóng băng, xác minh tài khoản còn lại đầu tiên bằng personal_position.pool_id, sau đó rã đông nó bằng PDA của pool.
• Đốt NFT.
• Đóng tài khoản token NFT và personal_position, hoàn lại tiền thuê cho nft_owner. Nếu NFT vị trí sử dụng Token-2022, nó cũng đóng mint NFT; các mint SPL Token cổ điển không thể đóng được và vẫn có nguồn cung bằng không.

Thao tác rã đông, đốt và đóng là nguyên tử. NFT không thể trở nên có thể chuyển nhượng giữa các bước đó.

Ngắt kết nối máy khách có điều kiện — bố cục IDL được khai báo không thay đổi, vì vậy các máy khách cũ tiếp tục đóng các vị trí hiện có và chưa bị đóng băng. Một trình xây dựng cũ bỏ qua tài khoản pool còn lại sẽ gặp lỗi AccountLack khi đóng một vị trí bị đóng băng. Chuyển pool cho mỗi lần đóng là chiến lược tương thích đơn giản nhất.

​

SwapV2

Đi bộ dọc theo đường cong thannh khoản; đầu vào chính xác hoặc đầu ra chính xác tùy thuộc vào is_base_input.

Đối số

amount: u64                  // input if is_base_input=true, output otherwise
other_amount_threshold: u64  // min out or max in
sqrt_price_limit_x64: u128   // hard bound; 0 ⇒ unbounded
is_base_input: bool

Tài khoản (tóm tắt)

#	Tên	W	S	Ghi chú
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 (bắt buộc cho một số đường dẫn Token-2022).
12	input_vault_mint, output_vault_mint			V2.
13	tick_array_bitmap_extension (tùy chọn)	W		Nếu swap đi vào phần mở rộng.
14+	tick_array (còn lại)	W		Đủ mảng để bao quát phạm vi dự kiến của lần đi bộ.

Những người gọi chuyển một danh sách được xếp hạng các mảng tick bao quát lần đi bộ swap dự kiến; chương trình sử dụng bao nhiêu nó cần. SDK tính toán danh sách này thông qua PoolUtils.computeAmountOutFormat hoặc điểm cuối báo giá của API.

Điều kiện tiên quyết

• pool_state.status cho phép swap.
• now >= open_time.
• sqrt_price_limit_x64 nằm ở phía chính xác của sqrt_price_x64 cho hướng đó.

Lỗi phổ biến — TooLittleOutputReceived (slippage chính xác-in), TooMuchInputPaid (slippage chính xác-out), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (bit swap được đặt trên pool_state.status). CLMM không có biến thể ExceededSlippage — tên đó là của CPMM — và không có TickArrayNotFound.

Những gì SwapV2 làm nội bộ mà những người gọi nên biết (phát hành sau 2025):

1. Phí tăng thêm động — nếu pool.dynamic_fee_info khác không, chương trình cập nhật bộ tích lũy biến động bằng cách sử dụng khoảng cách tick được duyệt qua kể từ lần swap cuối cùng (với các quy tắc bộ lọc/phân rã từ products/clmm/fees) và thêm một dynamic_fee_component trên AmmConfig.trade_fee_rate. Tổng phí được giới hạn ở 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
2. Khớp lệnh giới hạn — khi lần đi bộ giá vượt qua một tick chứa các lệnh giới hạn mở, chương trình trước tiên điền thanh khoản lệnh giới hạn có sẵn ở tick đó (FIFO theo order_phase), sau đó tiếp tục dọc theo đường cong thanh khoản LP. Các số tiền được điền cập nhật tick.unfilled_ratio_x64 và tick.part_filled_orders_remaining để giải quyết sau; các lệnh tự chúng vẫn chưa được chi tiêu cho đến khi chủ sở hữu của chúng gọi SettleLimitOrder.
3. Định tuyến phí một chiều — khi pool.fee_on = Token0Only hoặc Token1Only, bước swap vẫn tính toán cùng một giao dịch đầu vào-đầu ra; phí sau đó được định tuyến đến phía được cấu hình. Đối với các hướng mà phía phí được cấu hình là đầu ra, phí được khấu trừ từ đầu ra swap (người dùng nhận out − fee); đối với các hướng mà nó là đầu vào, hành vi khớp với FromInput. Xem is_fee_on_input(zero_for_one) và is_fee_on_token0(zero_for_one) trên PoolState.

Swap (V1) triển khai cùng phí động, định tuyến phí một chiều và khớp lệnh giới hạn như SwapV2; tính năng duy nhất nó thiếu là hỗ trợ Token-2022 — cả hai vault phải là SPL Token cổ điển. Các pool có bất kỳ mint Token-2022 nào phải được swap thông qua SwapV2. Trình tổng hợp và SDK đã ưu tiên V2 cho mọi chân CLMM nên những người gọi không phải phân nhánh theo loại mint.

​

OpenLimitOrder

Đặt lệnh bán ở một tick cụ thể. Lệnh nằm trong một nhóm FIFO theo tick và được điền khi giá đi qua.

Đối số

nonce_index:    u8       // user's chosen nonce-account index (0..255 per wallet)
zero_for_one:   bool     // true: sell token0 for token1; false: sell token1 for token0
tick_index:     i32      // must be a multiple of pool.tick_spacing
amount:         u64      // input-token amount

Tài khoản (tóm tắt)

#	Tên	W	S	Ghi chú
1	payer	W	S	Chủ sở hữu lệnh; trả tiền thuê.
2	pool_state	W
3	tick_array	W		Mảng tick chứa tick_index.
4	limit_order_nonce	W		PDA. init_if_needed — được tạo trên lệnh đầu tiên của người dùng dưới nonce_index này.
5	limit_order	W		PDA. init ở đây.
6	input_token_account	W		ATA đầu vào của người dùng. Được kiểm tra xem có frozen.
7	output_token_account	W		ATA đầu ra của người dùng. Không bị khấu trừ khi mở — chỉ cần thiết để chương trình có thể xác nhận nó không frozen (tức là lần điền có thể được giao sau).
8	input_vault	W		Vault đầu vào của pool.
9	output_vault	W		Vault đầu ra của pool. Xác định mint đầu ra cho các kiểm tra output_token_account / output_vault_mint.
10	input_vault_mint			Xử lý phí Token-2022.
11	output_vault_mint			Mint của phía đầu ra (ghép nối kiểm tra đóng băng).
12	input_token_program			SPL hoặc Token-2022.
13	system_program			Tài trợ cho limit_order, limit_order_nonce và — nếu cần — phân bổ tick_array.

Các tài khoản còn lại — [0] tick_array_bitmap_extension, chỉ bắt buộc khi khởi tạo một mảng tick có chỉ số bắt đầu nằm ngoài bitmap nội tuyến của pool. Không chuyển gì nếu không.

Không có tài khoản rent: struct kết thúc ở system_program, 13 tài khoản được khai báo. Một rent lạc ở vị trí 14 rơi đúng vào nơi phần mở rộng bitmap tùy chọn được đọc, vì vậy lệnh dường như hoạt động cho đến lần đầu tiên một mảng tick ngoài bitmap nội tuyến phải được tạo — và sau đó gặp lỗi.

Thay đổi danh sách tài khoản (phát hành 2026-07). OpenLimitOrder hiện cũng lấy các tài khoản phía đầu ra — output_token_account, output_vault và output_vault_mint — ngoài phía đầu vào. Chúng chỉ được sử dụng để xác thực: chương trình từ chối lệnh nếu tài khoản token đầu vào hoặc đầu ra của chủ sở hữu bị đóng băng. Điều này đảm bảo rằng một lần điền thực sự có thể được giải quyết cho ATA đầu ra của chủ sở hữu, điều này quan trọng đối với các mint Token-2022 danh sách cho phép / đóng băng mặc định (ví dụ: token được phép) nơi một tài khoản có thể chưa được rã đông. Các máy khách được xây dựng dựa trên danh sách tài khoản một chiều cũ phải thêm ba tài khoản đầu ra.

Điều kiện tiên quyết

• Cả input_token_account và output_token_account đều không bị đóng băng (nếu không NotApproved).
• pool_state.status cho phép cả hai hoạt động swap (bit 4) và lệnh giới hạn (bit 5) (nếu không NotApproved).
• tick_index % pool.tick_spacing == 0 và trong [MIN_TICK, MAX_TICK].
• tick_index nằm ở phía bên phải của pool.tick_current cho hướng được chọn (bán token0 → tick phải ở trên hiện tại, và ngược lại). Bán ở một tick đã được vượt qua sẽ được khớp ngay lập tức và bị từ chối.

Điều kiện sau

• limit_order tồn tại, chụp ảnh tick.order_phase và tick.unfilled_ratio_x64 tại thời điểm mở.
• tick.orders_amount += amount (trong nhóm hiện tại).
• limit_order_nonce.order_nonce += 1.
• OpenLimitOrderEvent được phát ra.

Lỗi phổ biến — NotApproved (tài khoản token đầu vào hoặc đầu ra bị đóng băng, hoặc pool có swap / lệnh giới hạn bị vô hiệu hóa), ZeroAmountSpecified (amount == 0 sau phí chuyển phía đầu vào), InvalidLimitOrderAmount (số tiền sẽ tạo ra đầu ra dưới 1 đơn vị cơ sở ở tick đó, hoặc tràn u64), InvalidTickIndex (ngoài [MIN_TICK, MAX_TICK], hoặc ở phía sai của tick_current cho hướng được chọn), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

​

IncreaseLimitOrder

Thêm vào một lệnh mở hiện có. Chỉ có thể gọi được bởi owner của lệnh.

Đối số

amount: u64    // additional input-token amount

Tài khoản — 8, chỉ phía đầu vào. Nó bỏ tài khoản nonce, cả ba tài khoản phía đầu ra và system_program.

#	Tên	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

Điều kiện tiên quyết

• limit_order.owner == signer.
• Lệnh vẫn ở trong cùng một nhóm (tick.order_phase == limit_order.order_phase). Nếu nhóm đã bắt đầu điền, lệnh được giải quyết một phần — người gọi nên gọi DecreaseLimitOrder hoặc SettleLimitOrder trước để tiến lên.

Hiệu ứng

• Chuyển amount từ ATA chủ sở hữu đến input_vault.
• limit_order.total_amount += amount; tick.orders_amount += amount.

​

DecreaseLimitOrder

Giảm hoặc hủy hoàn toàn một lệnh mở. Trả lại phần chưa điền cho chủ sở hữu, cộng với bất kỳ đầu ra nào đã được giải quyết bởi các lần điền một phần trong quá khứ.

Đối số

amount:     u64    // input-token amount to withdraw (max = unfilled remainder)
amount_min: u64    // slippage floor on the input-side withdrawal

Tài khoản — cả phía token đầu vào và đầu ra:

#	Tên	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

Hiệu ứng

• Tính toán lại số tiền được điền của lệnh từ unfilled_ratio_x64 của nhóm kể từ khi mở.
• Gửi đầu ra được điền đến output_token_account.
• Gửi amount của đầu vào chưa điền trở lại input_token_account.
• Cập nhật limit_order tương ứng. Nếu phần dư chưa điền mới bằng không, chương trình đóng tài khoản và hoàn lại tiền thuê cho owner.

​

SettleLimitOrder

Đẩy các token đầu ra đã được điền vào tài khoản của chủ sở hữu mà không thay đổi phần còn lại chưa được điền của lệnh. Hữu ích khi các keeper auto_withdraw muốn thanh toán từng phần cho các lần điền dài hạn.

Người gọi — hoặc là owner của lệnh, hoặc là limit_order_admin của chương trình (một ví nóng hoạt động ngoài chuỗi chạy vòng lặp keeper tự động). Keeper không có quyền hạn khác — nó không thể di chuyển quỹ người dùng ngoài việc đẩy đầu ra đã được điền vào ATA owner của lệnh.

Tài khoản

#	Tên	W	S	Ghi chú
1	signer		S	owner hoặc limit_order_admin
2	pool_state
3	tick_array
4	limit_order	W
5	output_token_account	W		ATA đầu ra của chủ sở hữu.
6	output_vault	W		Kho lưu trữ đầu ra của pool.
7	output_vault_mint
8	output_token_program

Hiệu ứng

• Tính toán đầu ra tích lũy nợ bằng cách sử dụng (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
• Chuyển delta đến output_token_account.
• Cập nhật limit_order.settled_output.
• Không đóng lệnh; nó vẫn còn mở đối với bất kỳ đầu vào còn lại nào.

​

CloseLimitOrder

Đóng tài khoản lệnh đã được tiêu thụ hoàn toàn. Tiền thuê luôn được trả lại cho limit_order.owner bất kể ai ký.

Người gọi — hoặc là owner hoặc limit_order_admin.

Điều kiện tiên quyết

• Lệnh có phần còn lại chưa được điền bằng không (hoặc amount == total_amount đã được điền và thanh toán, hoặc chủ sở hữu trước đó đã giảm lệnh xuống không và quên đóng).

Hiệu ứng

• Đóng limit_order; tiền thuê được gửi đến limit_order.owner.

​

CreateDynamicFeeConfig (admin)

Tạo một bộ tham số có thể tái sử dụng dưới một chỉ mục u16.

Đối số

index:                       u16
filter_period:               u16   // seconds; e.g. 30
decay_period:                u16   // seconds; e.g. 600. Must be > filter_period
reduction_factor:            u16   // 1..10_000; e.g. 5_000 = 50% retention per decay window
dynamic_fee_control:         u32   // 1..100_000; gain on the volatility-to-fee curve
max_volatility_accumulator:  u32   // ceiling

Tài khoản

#	Tên	W	S	Ghi chú
1	owner	W	S	Khóa công khai admin được mã hóa cứng.
2	dynamic_fee_config	W		PDA, init tại đây.
3	system_program

Lỗi phổ biến — InvalidDynamicFeeConfigParams nếu decay_period <= filter_period hoặc bất kỳ trường nào có giá trị 0 nằm ngoài giới hạn.

​

UpdateDynamicFeeConfig (admin)

Sửa đổi một DynamicFeeConfig hiện có. Các pool đã chụp nhanh cấu hình tại thời điểm tạo không được cập nhật theo cách hồi tưởng; chỉ các pool mới được tạo tham chiếu cấu hình này mới sẽ nhận các giá trị mới.

Đối số — năm trường hiệu chỉnh giống như CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index được cố định tại thời điểm tạo và không được truyền lại tại đây.

​

CollectProtocolFee / CollectFundFee

Quét các khoản phí giao thức/quỹ tích lũy từ các kho lưu trữ của pool đến người nhận, đặt lại các trường PoolState.protocol_fees_* / fund_fees_* tương ứng. Đây không phải bố cục CPMM — CLMM không có tài khoản authority, và các trường người nhận được đặt tên là recipient_token_account_{0,1} thay vì recipient_token_{0,1}_account.

Đối số — amount_0_requested: u64, amount_1_requested: u64.

#	Tên	W	S	Ghi chú
1	owner		S	amm_config.owner (hoặc amm_config.fund_owner cho biến thể quỹ), hoặc admin chương trình; nếu không thì 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

Thay đổi trong 2026-09: các cấu hình mới không còn lấy chủ sở hữu phí từ người ký. create_amm_config hiện ghi protocol_fee_owner::ID được mã hóa cứng của chương trình vào owner và fund_fee_owner::ID vào fund_owner. Trước đây, nó sao chép khóa của người ký admin vào cả hai. Trên mainnet, đây là những khóa giống nhau đã được lưu trữ trên tất cả 21 cấu hình hiện có. Các địa chỉ nằm trong reference/program-addresses.

Những người ký được chấp nhận ở trên không thay đổi. Admin vẫn có thể thu thập từ bất kỳ cấu hình nào, và các tài khoản AmmConfig hiện có không được viết lại. Đọc owner / fund_owner từ tài khoản thay vì giả định bất kỳ giá trị nào. Các tham số UpdateAmmConfig 3 và 4 vẫn xoay chúng.

​

CollectExcessLamports

Quét lamport của admin vượt quá mức tối thiểu miễn phí thuê trên các tài khoản mà CLMM kiểm soát. Nó được thêm vào trong bản nâng cấp 2026-09 để lấy lại quỹ dư thừa mà SIMD-0437 rent reduction để lại trên các tài khoản được tạo trước mỗi bước.

Chỉ phần dư thừa di chuyển. Số dư token, dữ liệu tài khoản, chủ sở hữu, trạng thái pool và đường cong giá không bị ảnh hưởng. Một tài khoản đã ở mức tối thiểu của nó được để nguyên, vì vậy lệnh có thể được chạy lại một cách an toàn sau mỗi bước triển khai.

Đối số: không có.

Tài khoản

#	Tên	W	S	Ghi chú
1	collect_lamports_wallet	W	S	Nhận mọi lamport được quét. Phải là admin chương trình CLMM hoặc ví thu thập lamport chuyên dụng (xem reference/program-addresses). Bất kỳ người ký nào khác sẽ thất bại với NotApproved.
2	pool_state	W		Pool được quét. Các hạt giống PDA của nó ký các CPI của token-program, và tài khoản luôn được quét chính nó.
3	token_program			SPL Token.
4	token_program_2022			Token-2022. Cả hai chương trình đều được yêu cầu; lệnh chọn một cho mỗi tài khoản nguồn.
5..	remaining_accounts	W		M tài khoản nguồn, bất kỳ số lượng, bất kỳ thứ tự.

Phạm vi: một pool cho mỗi lệnh gọi. CLMM không có quyền hạn kho lưu trữ trên toàn chương trình. Các kho lưu trữ của mỗi pool được sở hữu bởi PoolState của nó. Do đó, mọi nguồn token-program phải có pool_state trong khe 2 làm quyền hạn của nó: token_vault_0, token_vault_1, hoặc một trong các kho lưu trữ phần thưởng của pool đó. Nếu bạn chuyển kho lưu trữ của pool khác hoặc tài khoản token của người dùng, kiểm tra chủ sở hữu của token program sẽ thất bại và toàn bộ lệnh sẽ hoàn nguyên. Nó không bị bỏ qua. Các mint NFT vị trí không thể được quét, vì quyền hạn mint của chúng bị thu hồi khi vị trí được mở.

Cách xử lý mỗi tài khoản nguồn

Chương trình thực hiện hai lần vượt qua remaining_accounts: mọi CPI token-program trước tiên, sau đó là các khoản ghi nợ trực tiếp. Xen kẽ hai cái sẽ hủy bỏ với lỗi UnbalancedInstruction của runtime, vì vậy thứ tự được cố định trong chương trình và bạn không phải sắp xếp danh sách.

Lần vượt qua	Chủ sở hữu tài khoản nguồn	Xử lý
1	SPL Token hoặc Token-2022, tài khoản token không phải token gốc	CPI WithdrawExcessLamports (discriminant token-program 38), được ký bởi pool_state.
1	SPL Token hoặc Token-2022, gốc (wSOL) tài khoản token	WithdrawExcessLamports từ chối các tài khoản gốc. Chương trình CPIs SyncNative, đo lường bao nhiêu amount được bao bọc đã tăng, và gọi UnwrapLamports (discriminant 45) cho chính xác delta đó. Sau đó, nó yêu cầu số dư được bao bọc bằng giá trị trước khi đồng bộ hóa của nó, hoặc thất bại với LamportsCalculateError (6052). Kho lưu trữ pool phía SOL giữ toàn bộ than流động tính của nó.
2	pool_state (khe 2)	Ghi nợ trực tiếp xuống rent.minimum_balance(data_len).
2	Chương trình CLMM: AmmConfig, ObservationState, TickArrayBitmapExtension, TickArrayState, PersonalPositionState, LimitOrderState, v.v.	Ghi nợ trực tiếp xuống rent.minimum_balance(data_len). Tài khoản không phải thuộc pool trong khe 2.
—	Bất cứ điều gì khác	Bỏ qua im lặng. Không có lỗi, không có lamport di chuyển.

Lần vượt qua 2 bao gồm các tài khoản mà người dùng đã trả tiền thuê. Một PersonalPositionState hoặc LimitOrderState được chuyển tại đây từ bỏ phần dư thừa của nó giống như bất kỳ tài khoản nào khác do CLMM sở hữu. Nó vẫn miễn phí thuê và giữ dữ liệu của nó. Khi nó được đóng sau này, chủ sở hữu sẽ nhận lại bất kỳ tài khoản nào giữ tại thời điểm đó, sau khi quét là mức tối thiểu thuê hiện tại.

Kích thước giao dịch là giới hạn thực tế về bao nhiêu nguồn phù hợp trong một lệnh gọi. Đó là ràng buộc giống như quét phía ví được mô tả trong solana-fundamentals/rent-and-reclaimable-rent.

Lỗi phổ biến:

• NotApproved (6000): người ký sai.
• LamportsCalculateError (6052): vòng wSOL không lưới thành không.
• Lỗi không khớp chủ sở hữu token-program: một nguồn token không được sở hữu bởi pool_state.
• InsufficientFunds: một tài khoản do chương trình sở hữu giữ ít hơn mức tối thiểu thuê của nó.

Không có trình tạo SDK. @raydium-io/raydium-sdk-v2 không cung cấp trình tạo cho đường dẫn admin này. Mã hóa nó bằng tay từ IDL.

​

InitializeReward

Thêm một luồng phần thưởng mới vào pool. Tối đa 3 luồng có thể hoạt động cùng một lúc.

Đối số — một cấu trúc duy nhất, param: InitializeRewardParam:

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

Mã hóa dây là ba trường liên tiếp, vì vậy một lệnh được xây dựng bằng tay không bị ảnh hưởng — nhưng một máy khách được điều khiển bởi IDL phải chuyển một đối tượng param thay vì ba đối số vị trí.

Tài khoản

#	Tên	W	S	Ghi chú
1	reward_funder	W	S
2	funder_token_account	W
3	amm_config
4	pool_state	W
5	operation_state			PDA trạng thái hoạt động CLMM gating tạo phần thưởng.
6	reward_token_mint
7	reward_token_vault	W		init tại đây.
8	reward_token_program
9	system_program, rent

Điều kiện tiên quyết

• Ít hơn 3 luồng hiện hoạt động trên pool.
• Funder gửi total_emission = emissions_per_second × (end_time − open_time) giá trị của token phần thưởng vào kho lưu trữ như một phần của lệnh này.
• Mint phần thưởng được liệt trắng theo operation_state.

​

SetRewardParams

Mở rộng, bổ sung hoặc thay đổi tỷ lệ phát hành trên một luồng phần thưởng hiện có. Thường được gọi bởi người tạo pool hoặc multisig Raydium. Các ràng buộc sống trên chuỗi: bạn thường có thể mở rộng end_time hoặc tăng phát hành, không phải thu nhỏ chúng theo cách hồi tưởng. Kiểm tra danh sách chủ sở hữu của operation_state.

​

UpdateRewardInfos

Sổ sách thuần túy — giải quyết reward_growth_global_x64 đến thời gian hiện tại bằng cách nhân emissions_per_second × Δt / liquidity. Được gọi nội bộ bởi mọi lệnh chạm vào thanflow động tính. Được tiếp xúc như một lệnh độc lập vì các bên bên ngoài (UI, cranks) đôi khi muốn kích hoạt nó.

​

Thu thập phần thưởng

Không có lệnh thu thập phần thưởng độc lập. Chương trình không tiếp xúc điểm vào CollectReward, và IDL được xuất bản cũng không có.

Phần thưởng nợ cho một vị trí được trả bởi DecreaseLiquidity / DecreaseLiquidityV2. Để thu thập mà không thay đổi vị trí, hãy gọi nó với liquidity = 0, amount_0_min = 0, amount_1_min = 0. Các kho lưu trữ phần thưởng và tài khoản người nhận đi vào remaining_accounts trong các nhóm ba cho mỗi phần thưởng hoạt động, theo thứ tự reward_token_vault(W), recipient_token_account(W), reward_vault_mint.

CollectRemainingRewards là một điều khác: nó cho phép funder phần thưởng, sau end_time của luồng, quét các token không bao giờ được phân bổ cho bất kỳ vị trí nào.

​

Ma trận thay đổi trạng thái

Instruction	pool.liquidity	pool.fee_growth_global	pool.reward_growth_global	personal_position.liquidity	Tick array
CreatePool	0	0	—	—	—
OpenPosition	+ nếu trong phạm vi	—	—	mới	thêm liquidity_gross/net
IncreaseLiquidity	+ nếu trong phạm vi	settle owed	settle owed	+	điều chỉnh
DecreaseLiquidity	− nếu trong phạm vi	settle owed	settle owed	−	điều chỉnh
ClosePosition	—	—	—	bị xóa	—
SwapV2	± khi vượt qua	+	—	—	cross & flip outside; match limit-order cohorts
OpenLimitOrder	—	—	—	—	orders_amount += amount trên target tick
IncreaseLimitOrder	—	—	—	—	orders_amount += amount
DecreaseLimitOrder	—	—	—	—	orders_amount -=, có thể đóng cohort
SettleLimitOrder	—	—	—	—	— (chỉ đọc trên tick)
CloseLimitOrder	—	—	—	—	—
CreateCustomizablePool	0	0	—	—	—
UpdateRewardInfos	—	—	+	—	—
CollectExcessLamports	—	—	—	—	— (chỉ lamports; token balances không thay đổi)

​

Bước tiếp theo

• products/clmm/code-demos — các mẫu TypeScript có thể chạy được.
• products/clmm/fees — chi tiết về tích lũy phí và phần thưởng.
• reference/error-codes — bảng lỗi Anchor CLMM hoàn chỉnh.

Nguồn:

• raydium-io/raydium-clmm — programs/amm/src/instructions
• Raydium SDK v2 — @raydium-io/raydium-sdk-v2