CLMM 명령어

완전한 CLMM 명령어 참고: 풀 생명주기, 포지션 관리, 스왑, 보상 스트림.

이 페이지는 AI 자동 번역입니다. 모든 내용은 영문판을 기준으로 합니다.

영문판 보기 →

이 페이지는 products/clmm/accounts (계정이 무엇인지)와 products/clmm/math (수학이 무엇인지)와 함께 사용됩니다. 인자와 계정 순서에 대한 권위 있는 참고자료이며, 구체적인 바이트 레이아웃은 IDL에서 나옵니다.

2026-09 프로그램 업그레이드는 CLMM을 Anchor 1.0.2 / Solana 3.1.10으로 재구축했으며, 관리자 명령어 CollectExcessLamports를 추가했고, CreateAmmConfig가 owner / fund_owner에 쓰는 내용을 변경했습니다. 사용자 대면 명령어는 계정, 인자 또는 수학을 변경하지 않았습니다. 2026-09-30 변경 로그 항목을 참조하세요.

2026-10-22 프로그램 업그레이드는 CreatePermissionedPool을 CreateCustomizablePoolV2로 이름을 바꾸고, 누구나 호출할 수 있도록 만들며, 두 개의 관리자 명령어가 있는 Permission 계정을 제거합니다. 2026-10-22 변경 로그 항목을 참조하세요.

​

명령어 목록

그룹	명령어	설명
관리자	CreateAmmConfig	새로운 수수료 계층을 정의합니다.
관리자	UpdateAmmConfig	기존 계층의 요금을 변경합니다.
관리자	UpdatePoolStatus	풀의 작업을 일시 중지/재개합니다.
관리자	CreateSupportMintAssociated	CLMM 풀에서 사용할 Token-2022 민트 확장 구성을 허용 목록에 추가합니다.
관리자	CreateOperationAccount	프로그램 수준 작업 계정을 초기화합니다 (일회성).
관리자	UpdateOperationAccount	작업 계정 허용 목록을 수정합니다.
관리자	CreateDynamicFeeConfig	u16 인덱스 아래에 재사용 가능한 동적 수수료 매개변수 집합을 만듭니다.
관리자	UpdateDynamicFeeConfig	기존 DynamicFeeConfig를 수정합니다. 이미 스냅샷한 풀은 영향을 받지 않습니다.
풀	CreatePool	AmmConfig에 바인딩된 CLMM 풀을 초기화합니다. 표준, FromInput 수수료 경로. CreateCustomizablePool과 공존합니다.
풀	CreateCustomizablePool	새 풀에 권장됩니다. CreatePool과 동일한 형태에 collect_fee_on과 선택적 enable_dynamic_fee 플래그를 추가합니다.
풀	CreateCustomizablePoolV2	이미 하나가 있는 쌍과 수수료 계층에 대한 추가 풀을 만듭니다. 클라이언트가 제공한 0이 아닌 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 토큰이어야 함).
스왑	SwapRouterBaseIn	라우터에서 사용하는 다중 홉입니다.
지정가 주문	OpenLimitOrder	틱에서 판매 주문을 배치합니다. 미체결 토큰은 틱에 남아 있으며, 매칭 엔진은 가격이 교차할 때 채웁니다.
지정가 주문	IncreaseLimitOrder	기존 공개 주문에 추가합니다.
지정가 주문	DecreaseLimitOrder	공개 주문을 줄이거나 취소합니다. 미체결 나머지와 이미 정산된 출력을 지급합니다.
지정가 주문	SettleLimitOrder	채워진 출력 토큰을 주문 소유자에게 푸시합니다. 소유자 또는 운영 키퍼가 호출할 수 있습니다.
지정가 주문	CloseLimitOrder	완전히 소비된 주문 계정을 닫습니다. 임차료는 항상 주문의 owner로 반환됩니다. 소유자 또는 키퍼가 호출할 수 있습니다.
수수료	CollectProtocolFee	프로토콜 수수료의 관리자 스윕입니다.
수수료	CollectFundFee	펀드 수수료의 관리자 스윕입니다.
보상	InitializeReward	풀에 새로운 보상 스트림을 연결합니다.
보상	SetRewardParams	기존 보상의 방출 속도/종료를 변경합니다.
보상	UpdateRewardInfos	보상 성장을 현재로 정산합니다 (모든 스왑/포지션 변경으로 호출됨).
보상	TransferRewardOwner	보상 스트림을 설정하거나 충전할 수 있는 권한을 이전합니다.
보상	CollectRemainingRewards	보상 스트림의 end_time 이후, 할당되지 않은 토큰을 펀더에게 다시 스윕합니다.
관리자	CloseSupportMintAssociated	민트의 SupportMintAssociated 등록을 제거하고 임차료를 환불합니다.
관리자	CollectExcessLamports	하나의 풀의 PoolState 및 볼트에서 임차료 면제 최소값 이상의 램포트를 스윕하고, 전달된 CLMM 소유 PDA를 스윕합니다. admin 또는 전용 수집 램포트 지갑. 2026-09에 추가됨.

초기화 틱 배열 명령어는 없으며 필요하지 않습니다. 틱 배열은 OpenPosition* / IncreaseLiquidity* 내에서 TickArrayState::get_or_create_tick_array에 의해 생성되며, payer가 비용을 지불합니다. (아직 초기화되지 않았을 수 있는 시스템 소유) 틱 배열 PDA를 tick_array_lower / tick_array_upper로 전달하면 프로그램이 누락된 경우 할당합니다. OpenLimitOrder는 단일 tick_array에 대해 동일한 작업을 수행합니다.

대부분의 관리자 전용 명령어 (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition)는 프로그램의 하드코딩된 admin 공개 키로 제어됩니다. CreateSupportMintAssociated / CloseSupportMintAssociated는 admin 공개 키 또는 전용 지원 민트 소유자 키를 허용합니다. CollectExcessLamports는 admin 공개 키 또는 전용 수집 램포트 지갑을 허용합니다. 보상 스트림 관리자 명령어 (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과 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는 0으로 설정됨 (동적 수수료 비활성화).

​

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에서 초기화됨 (5개의 보정 매개변수 복사됨; 상태 필드는 0으로 설정됨).
• 그렇지 않으면: pool_state.dynamic_fee_info는 0으로 설정됨 (= 이 풀에 대해 동적 수수료는 영구적으로 비활성화됨).

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                          // 0이 아니어야 함; 풀 PDA 시드에 포함됨

계정

#	이름	W	S	참고
1	payer	W	S	모든 새 계정의 렌트를 지불합니다. 모든 지갑.
2	pool_creator			pool_state.owner로 기록됩니다. payer와 다를 수 있습니다. 서명자가 아니며 검증되지 않습니다.
3	amm_config			풀이 바인딩되는 수수료 계층.
4	pool_state	W		["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]에서 init.
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 민트가 필요할 때 지원 민트 레지스트리 PDA, 그리고 enable_dynamic_fee = true일 때 DynamicFeeConfig 마지막 — CreateCustomizablePool과 동일합니다.

전제 조건

• seed_index != 0. seed_index가 0이면 레거시 풀을 위해 예약되어 있으며 여기서 거부됩니다. [0, 0] 시드 컴포넌트가 레거시 풀 주소를 클래식 4시드 형식으로 축소하게 합니다.
• 유도된 주소에 풀이 이미 존재하지 않습니다.
• CreatePool과 동일한 민트/허용 목록 규칙.

사후 조건

• 새로운 pool_state가 seed_index 유도 주소에 존재하며, pool_state.seed_index = seed_index.
• 다른 모든 사후 상태는 CreateCustomizablePool과 일치합니다 (수수료 모드, 선택적 동적 수수료).

pool_creator가 검증되지 않으므로, 모든 지불자가 pool_state.owner에 모든 주소를 쓸 수 있습니다. 그 주소는 풀에서 InitializeReward를 호출할 수 있지만, 풀을 누가 만들었는지 증명하지는 않습니다. 통합자는 V2 풀을 owner로 라벨링하거나 순위를 매기지 않아야 합니다.

​

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 틱 배열) 밖에 있으면, 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] 범위 내.
• 두 틱 배열 PDA가 전달됩니다. 이미 존재할 필요는 없습니다 — get_or_create_tick_array는 이 명령어 내에서 payer의 비용으로 누락된 것을 할당합니다. 별도의 초기화 틱 배열 명령어는 없습니다.
• 사용자는 소스 ATA에 최소 amount_0_max와 amount_1_max를 보유합니다.

사후 조건

• personal_position이 존재하고, liquidity가 설정되며, fee_growth_inside_last가 스냅샷됩니다.
• tick_lower와 tick_upper의 틱 배열 항목이 업데이트됩니다 (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 (범위 내인 경우)를 증가시키고, 끝점 틱의 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가 바뀌고, 금고가 틱 배열 앞에 오며, 사용자 측 계정이 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

남은 계정 — 수집 중인 활성 보상당 3개씩, 순서대로 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를 종료합니다.

선언된 계정

#	Name	W	S	Notes
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.

(즉, 먼저 모든 것을 수집하고 0으로 감소시킵니다.)

효과

• NFT 토큰 계정이 동결된 경우, 첫 번째 남은 계정이 personal_position.pool_id와 같은지 확인한 후 풀 PDA로 동결을 해제합니다.
• NFT를 소각합니다.
• NFT 토큰 계정과 personal_position을 종료하여 nft_owner에게 렌트를 환불합니다. 포지션 NFT가 Token-2022를 사용하는 경우, NFT 민트도 종료합니다. 클래식 SPL Token 민트는 종료할 수 없으며 공급량이 0으로 유지됩니다.

동결 해제, 소각, 종료는 원자적입니다. 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

계정 (요약)

#	Name	W	S	Notes
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		이동의 예상 범위를 포함할 충분한 배열.

호출자는 예상 스왑 이동을 포함하는 순위가 지정된 틱 배열 목록을 전달합니다. 프로그램은 필요한 만큼 사용합니다. 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가 0이 아닌 경우, 프로그램은 마지막 스왑 이후 순회한 틱 거리를 사용하여 변동성 누적기를 업데이트하고 (필터/감소 규칙은 products/clmm/fees 참조) AmmConfig.trade_fee_rate 위에 dynamic_fee_component를 추가합니다. 총 수수료는 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000)로 제한됩니다.
2. 리미트 오더 매칭 — 가격 이동이 열린 리미트 오더를 보유한 틱을 교차할 때, 프로그램은 먼저 해당 틱에서 사용 가능한 리미트 오더 유동성을 채우고 (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

특정 틱에서 판매 오더를 배치합니다. 오더는 틱별 FIFO 코호트에 앉아 있으며 가격이 지나갈 때 채워집니다.

인수

nonce_index:    u8       // 사용자가 선택한 논스 계정 인덱스 (지갑당 0..255)
zero_for_one:   bool     // true: token0을 token1로 판매; false: token1을 token0으로 판매
tick_index:     i32      // pool.tick_spacing의 배수여야 함
amount:         u64      // 입력 토큰 수량

계정 (요약)

#	Name	W	S	Notes
1	payer	W	S	오더 소유자; 렌트를 지불합니다.
2	pool_state	W
3	tick_array	W		tick_index를 포함하는 틱 배열.
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, 시작 인덱스가 풀의 인라인 비트맵 외부에 있는 틱 배열을 초기화할 때만 필요합니다. 그 외에는 아무것도 전달하지 마세요.

rent 계정이 없습니다: 구조는 system_program에서 끝나며 13개의 선언된 계정입니다. 위치 14에 있는 잘못된 rent는 선택적 비트맵 확장이 읽히는 정확한 위치에 도달하므로, 인라인 비트맵 외부의 틱 배열을 처음 생성해야 할 때까지 오더가 작동하는 것처럼 보입니다 — 그 다음 실패합니다.

계정 목록 변경 (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 판매 → 틱은 현재보다 위에 있어야 하고, 그 반대도 마찬가지). 이미 교차한 틱에서 판매하면 즉시 매칭되며 거부됩니다.

사후 조건

• 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 (금액이 해당 틱에서 1 기본 단위 미만의 출력을 생성하거나 u64 오버플로우), InvalidTickIndex ([MIN_TICK, MAX_TICK] 범위 밖, 또는 선택한 방향에 대해 tick_current의 잘못된 쪽), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

​

IncreaseLimitOrder

기존 열린 오더에 추가합니다. 오더의 owner만 호출할 수 있습니다.

인수

amount: u64    // 추가 입력 토큰 수량

계정 — 8개, 입력 쪽만. 논스 계정, 세 개의 출력 쪽 계정 및 system_program을 제거합니다.

#	Name	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에서 input_vault로 amount를 전송합니다.
• limit_order.total_amount += amount; tick.orders_amount += amount.

​

DecreaseLimitOrder

열린 오더를 줄이거나 완전히 취소합니다. 미채워진 나머지를 소유자에게 돌려주고, 과거 부분 채우기로 이미 정산된 출력도 함께 돌려줍니다.

인수

amount:     u64    // 인출할 입력 토큰 수량 (최대 = 미채워진 나머지)
amount_min: u64    // 입력 쪽 인출에 대한 슬리피지 하한

계정 — 입력 및 출력 토큰 쪽 모두:

#	Name	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를 그에 따라 업데이트합니다. 새로운 미채워진 나머지가 0이면, 프로그램은 계정을 종료하고 owner에게 렌트를 환불합니다.

​

SettleLimitOrder

채워진 출력 토큰을 주문의 미충전 잔액을 변경하지 않고 소유자에게 전달합니다. auto_withdraw 키퍼가 장기 실행 부분 채우기를 점진적으로 지급하려는 경우에 유용합니다.

호출자 — 주문의 owner 또는 프로그램의 limit_order_admin (자동화된 키퍼 루프를 실행하는 오프체인 운영 핫 지갑). 키퍼는 다른 권한이 없습니다. 주문의 owner ATA로 채워진 출력을 전달하는 것 외에는 사용자 자금을 이동할 수 없습니다.

계정

#	이름	W	S	참고
1	signer		S	owner 또는 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.

전제 조건

• 주문에 미충전 잔액이 0입니다 (amount == total_amount가 채워지고 정산되었거나, 소유자가 이전에 주문을 0으로 감소시키고 닫기를 잊었습니다).

효과

• 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와 동일한 5개 보정 필드 (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator). index는 생성 시 고정되며 여기서 다시 전달되지 않습니다.

​

CollectProtocolFee / CollectFundFee

풀의 금고에서 누적된 프로토콜/펀드 수수료를 수신자에게 스윕하고, 해당 PoolState.protocol_fees_* / fund_fees_* 필드를 0으로 설정합니다. 이것은 CPMM의 레이아웃이 아닙니다 — CLMM에는 authority 계정이 없으며, 수신자 필드는 recipient_token_{0,1}_account 대신 recipient_token_account_{0,1}로 명명됩니다.

인수 — 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이 제어하는 계정의 렌트 면제 최소값 이상의 램포트에 대한 관리자 스윕. SIMD-0437 렌트 감소 이후 각 단계 전에 생성된 계정에 남겨진 과다 자금을 회수하기 위해 2026-09 업그레이드에서 추가되었습니다.

초과분만 이동합니다. 토큰 잔액, 계정 데이터, 소유자, 풀 상태 및 가격 곡선은 변경되지 않습니다. 이미 최소값에 있는 계정은 그대로 두므로, 각 롤아웃 단계 후에 명령을 안전하게 다시 실행할 수 있습니다.

인수: 없음.

계정

#	이름	W	S	참고
1	collect_lamports_wallet	W	S	스윕된 모든 램포트를 수신합니다. CLMM 프로그램 관리자 또는 전용 수집-램포트 지갑이어야 합니다 (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는 네이티브 계정을 거부합니다. 프로그램은 SyncNative를 CPI하고, 래핑된 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의 풀에 속할 필요가 없습니다.
—	다른 모든 것	조용히 건너뜁니다. 오류 없음, 램포트 이동 없음.

통과 2는 사용자가 렌트를 지불한 계정을 포함합니다. 여기에 전달된 PersonalPositionState 또는 LimitOrderState는 다른 CLMM 소유 계정처럼 초과분을 포기합니다. 렌트 면제 상태를 유지하고 데이터를 유지합니다. 나중에 닫힐 때, 소유자는 계정이 그 시점에 보유한 것을 돌려받으며, 스윕 후에는 현재 렌트 최소값입니다.

트랜잭션 크기는 한 호출에 맞는 소스 수의 실제 제한입니다. 이는 solana-fundamentals/rent-and-reclaimable-rent에 설명된 지갑 측 스윕과 동일한 제약입니다.

일반적인 오류:

• NotApproved (6000): 잘못된 서명자.
• LamportsCalculateError (6052): wSOL 왕복이 0으로 정산되지 않았습니다.
• 토큰 프로그램 소유자 불일치 오류: 토큰 소스가 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
}

와이어 인코딩은 3개 필드가 연속되므로, 손으로 만든 명령은 영향을 받지 않습니다. 하지만 IDL 기반 클라이언트는 3개의 위치 인수 대신 하나의 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

순수 기록 유지 — reward_growth_global_x64를 현재 시간으로 정산하고 emissions_per_second × Δt / liquidity를 곱합니다. 모든 유동성 터치 명령에 의해 내부적으로 호출됩니다. 외부 행위자 (UI, 크랭크)가 때때로 이를 트리거하려고 하기 때문에 독립 실행형 명령으로 노출됩니다.

​

보상 수집

독립 실행형 보상 수집 명령이 없습니다. 프로그램은 CollectReward 진입점을 노출하지 않으며, 게시된 IDL도 없습니다.

포지션에 대한 보상은 DecreaseLiquidity / DecreaseLiquidityV2에 의해 지급됩니다. 포지션을 변경하지 않고 수집하려면 liquidity = 0, amount_0_min = 0, amount_1_min = 0으로 호출합니다. 보상 금고와 수신자 계정은 활성 보상당 3개 그룹으로 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