CLMM instructions

This page pairs with products/clmm/accounts (what the accounts are) and products/clmm/math (what the math is). It is authoritative for arguments and account ordering; specific byte layouts come from the IDL.The 2026-09 program upgrade rebuilt CLMM on Anchor 1.0.2 / Solana 3.1.10, added the admin instruction CollectExcessLamports, and changed what CreateAmmConfig writes into owner / fund_owner. No user-facing instruction changed its accounts, arguments or math. See the 2026-09-30 changelog entry.

Instruction inventory

Group	Instruction	Notes
Admin	`CreateAmmConfig`	Define a new fee tier.
Admin	`UpdateAmmConfig`	Change rates on an existing tier.
Admin	`UpdatePoolStatus`	Pause/resume operations on a pool.
Admin	`CreateSupportMintAssociated`	Allow-list a Token-2022 mint extension config for use in CLMM pools.
Admin	`CreateOperationAccount`	Initialize the program-level operation account (one-time).
Admin	`UpdateOperationAccount`	Modify the operation-account whitelist.
Admin	`CreateDynamicFeeConfig`	Create a reusable dynamic-fee parameter set under a u16 index.
Admin	`UpdateDynamicFeeConfig`	Modify an existing `DynamicFeeConfig`. Pools that already snapshotted it are unaffected.
Admin	`CreatePermissionPda`	Grant an authority the right to call `CreatePermissionedPool` by initializing its `Permission` PDA.
Admin	`ClosePermissionPda`	Revoke a previously-granted permission by closing its `Permission` PDA; rent refunds to the caller.
Pool	`CreatePool`	Initialize a CLMM pool bound to an `AmmConfig`. Standard, FromInput-fee path. Coexists with `CreateCustomizablePool`.
Pool	`CreateCustomizablePool`	Recommended for new pools. Same shape as `CreatePool` plus `collect_fee_on` and an opt-in `enable_dynamic_fee` flag.
Pool	`CreatePermissionedPool`	Create an additional pool for a pair that already has one, using a client-supplied `seed_index` folded into the pool PDA. Payer must hold a `Permission` PDA.
Position	`OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft`	Mint a position NFT. `OpenPositionV2` supersedes V1; `OpenPositionWithToken22Nft` issues the NFT as Token-2022. V2 paths freeze the NFT account only when an underlying vault mint’s freeze authority matches the restricted-issuer list. Otherwise the account stays unfrozen.
Position	`IncreaseLiquidity` / `IncreaseLiquidityV2`	Add liquidity to an existing position.
Position	`DecreaseLiquidity` / `DecreaseLiquidityV2`	Remove liquidity; collects owed fees.
Position	`ClosePosition`	Burn the NFT and close the `PersonalPositionState`. If the NFT account is frozen, first thaws it with the pool PDA supplied as a remaining account.
Position	`CloseProtocolPosition`	Admin-only sweep for legacy `ProtocolPositionState` PDAs. The current program no longer creates or reads `ProtocolPositionState` — this instruction exists solely to reclaim rent on accounts created by older program versions.
Swap	`Swap` / `SwapV2`	Constant-liquidity swap. Both variants apply dynamic fee, single-sided fee routing, and limit-order matching; the only difference is that `SwapV2` accepts Token-2022 mints (the V1 variant requires both vaults to be classic SPL Token).
Swap	`SwapRouterBaseIn`	Multi-hop, used by the router.
Limit order	`OpenLimitOrder`	Place a sell order at a tick. Unfilled tokens sit on the tick; the matching engine fills them as price crosses.
Limit order	`IncreaseLimitOrder`	Add to an existing open order.
Limit order	`DecreaseLimitOrder`	Reduce or cancel an open order; pays out the unfilled remainder plus any output already settled.
Limit order	`SettleLimitOrder`	Push filled output tokens to the order owner. Callable by the owner or by the operational keeper.
Limit order	`CloseLimitOrder`	Close a fully-consumed order account. Rent always returns to the order’s `owner`. Callable by owner or keeper.
Fees	`CollectProtocolFee`	Admin sweep of protocol fees.
Fees	`CollectFundFee`	Admin sweep of fund fees.
Rewards	`InitializeReward`	Attach a new reward stream to a pool.
Rewards	`SetRewardParams`	Change an existing reward’s emission rate/end.
Rewards	`UpdateRewardInfos`	Settle reward growth to now (called by any swap / position change).
Rewards	`TransferRewardOwner`	Transfer the authority that can set or top up a reward stream.
Rewards	`CollectRemainingRewards`	After a reward stream’s `end_time`, sweep any unallocated tokens back to the funder.
Admin	`CloseSupportMintAssociated`	Remove a mint’s `SupportMintAssociated` registration and refund its rent.
Admin	`CollectExcessLamports`	Sweep lamports above the rent-exempt minimum from one pool’s `PoolState` and vaults, plus any CLMM-owned PDAs passed in. `admin` or the dedicated collect-lamports wallet. Added 2026-09.

There is no init-tick-array instruction, and none is needed. A tick array is created inside OpenPosition* / IncreaseLiquidity* by TickArrayState::get_or_create_tick_array, paid for by payer. Pass the (possibly still-uninitialized, system-owned) tick-array PDA as tick_array_lower / tick_array_upper and the program allocates it if it is missing. OpenLimitOrder does the same for its single tick_array.

Most admin-only instructions (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) are gated by the program’s hardcoded admin pubkey. CreatePermissionPda / ClosePermissionPda accept either the admin pubkey or a dedicated permission_pda_admin key; CreateSupportMintAssociated / CloseSupportMintAssociated accept either the admin pubkey or a dedicated support-mint owner key; CollectExcessLamports accepts either the admin pubkey or a dedicated collect-lamports wallet. Reward-stream admin instructions (TransferRewardOwner, CollectRemainingRewards) are gated by the reward funder, not the program admin. V2 suffix means “supports Token-2022 on vaults / NFT, requires bitmap-extension slot”. The SDK picks V2 by default for new pools.

`CreatePool`

Arguments

sqrt_price_x64: u128           // initial price
open_time:      u64            // swaps rejected before this time

Accounts (abridged)

#	Name	W	S	Notes
1	`pool_creator`	W	S
2	`amm_config`			Chosen fee tier.
3	`pool_state`	W		`init` here.
4	`token_mint_0`			Sorted.
5	`token_mint_1`
6	`token_vault_0`	W		`init` here, owned by pool authority PDA.
7	`token_vault_1`	W
8	`observation_state`	W		`init` here.
9	`tick_array_bitmap`	W		The `TickArrayBitmapExtension` PDA; `init` here.
10	`token_program_0`			The program that owns `token_mint_0` — SPL Token or Token-2022.
11	`token_program_1`			The program that owns `token_mint_1`.
12	`system_program`
13	`rent`

Slots 10 and 11 are per-mint, not “SPL Token then Token-2022”. Each is constrained by mint::token_program on the matching mint, so for a pool whose token_mint_0 is Token-2022 and token_mint_1 is classic SPL you must pass Token-2022 in slot 10 and SPL Token in slot 11. CreateCustomizablePool and CreatePermissionedPool use the same two slots.

Preconditions

token_mint_0 < token_mint_1 by byte order.
amm_config.disable_create_pool == false.
Mints are not rejected by the Token-2022 extension allow-list.

Postconditions

pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
pool_state.liquidity = 0 (no positions yet).
pool_state.fee_on = FromInput (legacy default).
pool_state.dynamic_fee_info is zeroed (dynamic fee disabled).

`CreateCustomizablePool`

Recommended for new pools. Same effect as CreatePool plus per-pool fee-collection mode and an optional dynamic-fee opt-in. Arguments

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

Accounts — exactly the 13 declared accounts of CreatePool. dynamic_fee_config is not a declared account.

When enable_dynamic_fee = true, the DynamicFeeConfig to snapshot must be supplied as the last remaining_account — the handler reads ctx.remaining_accounts.last(). Any SupportMintAssociated bypass PDAs must therefore come before it, or the program snapshots the wrong account and fails deserialization. Omitting it while the flag is set fails with AccountLack.

Preconditions — same as CreatePool. If enable_dynamic_fee = false, no remaining_account is required and any that are passed are only scanned for support-mint records. Postconditions

pool_state.fee_on set to the chosen CollectFeeOn variant.
If dynamic fee was enabled: pool_state.dynamic_fee_info is initialized from the supplied DynamicFeeConfig (five calibration parameters copied; state fields zeroed).
Otherwise: pool_state.dynamic_fee_info is zeroed (= dynamic fee inactive forever for this pool).

fee_on and the dynamic-fee enablement bit are set only at pool creation. There is no in-place upgrade — pools created via legacy CreatePool cannot retroactively gain dynamic fee or single-sided fee. New deployments should default to this instruction.

`CreatePermissionedPool`

Both CreatePool and CreateCustomizablePool derive the pool PDA from ["pool", amm_config, token_mint_0, token_mint_1], so there is exactly one canonical pool address per (config, mint0, mint1) triple — a second init at the same seeds fails. CreatePermissionedPool lifts that restriction by folding a client-supplied seed_index: u16 into the pool PDA seeds, allowing multiple pools for the same pair and fee tier — each at its own address. Because an arbitrary pool address is a privileged capability, the payer must hold a Permission PDA that authorizes it. Everything else about the pool is identical to CreateCustomizablePool: it takes the same CreateCustomizableParams and supports single-sided fee and the dynamic-fee opt-in. Arguments

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

Accounts (abridged) — same as CreateCustomizablePool plus, at the front:

#	Name	W	S	Notes
1	`payer`	W	S	Pays rent. Must be the authority of the `permission` PDA below.
2	`pool_creator`			Recorded as `pool_state.owner`. May differ from `payer`.
3	`permission`			PDA `["permission", payer]`. Anchor rejects the call if it does not exist / is not owned by the program.
…	(`amm_config`, `pool_state`, mints, vaults, `observation_state`, `tick_array_bitmap`, token/system programs)			As in `CreateCustomizablePool`.

The pool_state PDA is derived from ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]. Preconditions

seed_index != 0. A seed_index of 0 is reserved for legacy pools and is rejected here; the [0, 0] seed component is what makes a legacy pool address collapse to the classic four-seed form.
The permission PDA for payer exists (created by an admin via CreatePermissionPda).
Same mint / allow-list rules as CreatePool.

Postconditions

A new pool_state exists at the seed_index-derived address, with pool_state.seed_index = seed_index.
All other post-state matches CreateCustomizablePool (fee mode, optional dynamic fee).

This instruction does not widen general pool-creation access — permissionless creation continues through CreatePool / CreateCustomizablePool, which remain one-pool-per-pair. CreatePermissionedPool exists for the specific case where a whitelisted operator needs several pools for the same pair (e.g. differing initial prices or launch cohorts) and holds a Permission PDA granted by the admin.

`OpenPositionV2` / `OpenPositionWithToken22Nft`

Create a new position inside an existing pool. 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 — the two variants have different account lists. OpenPositionV2 declares 22; OpenPositionWithToken22Nft declares 20. OpenPositionV2, in order:

#	Name	W	S	Notes
1	`payer`	W	S
2	`position_nft_owner`
3	`position_nft_mint`	W	S	Fresh keypair.
4	`position_nft_account`	W		Owner’s ATA for the NFT.
5	`metadata_account`	W		Metaplex metadata PDA. Declared unconditionally, even when `with_metadata = false`.
6	`pool_state`	W
7	`protocol_position`			Vestigial; read-only `UncheckedAccount`.
8	`tick_array_lower`	W		Created here if uninitialized.
9	`tick_array_upper`	W		Same.
10	`personal_position`	W		Created here.
11	`token_account_0`	W		User source 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 is the same list with metadata_account (5) and metadata_program (19) removed — it writes the position’s metadata through the Token-2022 metadata extension on the NFT mint instead — giving 20 accounts. Its position_nft_mint is a bare Signer and position_nft_account an UncheckedAccount.

tick_array_bitmap_extension is not a declared account on either variant. When the position’s range falls outside the pool’s inline tick_array_bitmap (±512 tick arrays), append the TickArrayBitmapExtension PDA at seeds ["pool_tick_array_bitmap_extension", pool_state] as remaining_accounts[0].

Math — see products/clmm/math. Given base_flag, the program resolves either liquidity or (amount_0_max, amount_1_max) into the actual L and the actual token amounts consumed. Preconditions

tick_lower < tick_upper, both multiples of pool.tick_spacing, within [MIN_TICK, MAX_TICK].
The two tick-array PDAs are passed. They need not already exist — get_or_create_tick_array allocates a missing one at payer’s expense inside this instruction. There is no separate init-tick-array instruction.
User has at least amount_0_max and amount_1_max in the source ATAs.

Postconditions

personal_position exists, liquidity set, fee_growth_inside_last snapshotted.
Tick-array entries at tick_lower and tick_upper updated (liquidity_gross += L, liquidity_net ± L, fee-growth snapshots maintained).
pool_state.liquidity += L if position is in range (tick_lower ≤ tick_current < tick_upper).
The position NFT mint records pool_state as freeze authority. Mint authority is removed after the single NFT is minted. Recording the freeze authority does not change the NFT token account’s state.
The NFT token account remains unfrozen unless the instruction is OpenPositionV2 or OpenPositionWithToken22Nft and either vault mint’s freeze authority matches CLMM’s restricted-issuer list. Only that matching V2 path freezes the account. OpenPosition V1 does not freeze.

Common errors — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (an endpoint is not a multiple of tick_spacing), InvalidTickIndex (outside [MIN_TICK, MAX_TICK]), MissingTickArrayBitmapExtensionAccount (range outside the inline bitmap and the extension was not appended), NotApproved (pool_state.status blocks opening), ZeroAmountSpecified.

Position freezing does not add declared instruction accounts or arguments. Clients can open these positions with the existing V2 layouts. The behavior is selected on-chain from vault_0_mint and vault_1_mint.

`IncreaseLiquidityV2`

Add liquidity to an already-open position. Arguments

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

Accounts — 15, and not derivable from OpenPosition: there is no rent, no system_program, no associated_token_program and no 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`

Prepend the TickArrayBitmapExtension PDA as remaining_accounts[0] when the position’s range is outside the inline bitmap. Effect

Transfers amount_0_actual / amount_1_actual from user → vaults.
Increments personal_position.liquidity and pool_state.liquidity (if in range), and the endpoint-tick liquidity_gross / liquidity_net accordingly.
Collects fees and rewards owed since last touch and credits them to token_fees_owed_{0,1} / reward_amount_owed. Those are paid out only on DecreaseLiquidity / DecreaseLiquidityV2, not on increase — there is no standalone collect instruction.

`DecreaseLiquidityV2`

Remove liquidity from a position. Arguments

liquidity: u128
amount_0_min: u64
amount_1_min: u64

Accounts — 16, and not the same shape or order as IncreaseLiquidityV2: personal_position and pool_state are swapped, the vaults come before the tick arrays, the user-side accounts are named recipient_token_account_*, and there is an extra memo_program.

#	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 — three per active reward being collected, in the order reward_token_vault(W), recipient_token_account(W), reward_vault_mint. Prepend the TickArrayBitmapExtension PDA when the position’s range is outside the inline bitmap.

This is also the only way to collect fees and rewards. To collect without changing the position, call it with liquidity = 0, amount_0_min = 0, amount_1_min = 0.

Effect

Computes (amount_0, amount_1) for the removed L given current sqrt_price_x64.
Settles fees/rewards accrued since the last touch, same as IncreaseLiquidity.
Transfers amount_0 + fees_owed_0 and amount_1 + fees_owed_1 out of vaults to the user.
Decrements liquidity counters; if the new personal_position.liquidity == 0, the position is eligible for ClosePosition.

Slippage — amount_0_min and amount_1_min are the minimums the user accepts net of Token-2022 transfer fees on the output side.

`ClosePosition`

Burn the position NFT and close PersonalPositionState. Declared accounts

#	Name	W	S	Notes
1	`nft_owner`	W	S	Must own the NFT token account holding amount `1`.
2	`position_nft_mint`	W		Must match `personal_position.nft_mint`.
3	`position_nft_account`	W		NFT owner’s account; may be classic SPL Token or Token-2022.
4	`personal_position`	W		Closed to `nft_owner`.
5	`system_program`			Closes position state.
6	`token_program`			Must own the NFT mint and token account.

Remaining accounts

Unfrozen NFT: none required; an extra pool account is harmless because the handler does not read it.
Frozen NFT: append personal_position.pool_id as the first remaining account. The program loads it as PoolState and uses its PDA seeds to sign the thaw.

Preconditions

personal_position.liquidity == 0.
tokens_fees_owed_{0,1} == 0.
All reward counters reward_amount_owed == 0.

(I.e., collect everything and decrease-to-zero first.) Effect

If the NFT token account is frozen, verifies the first remaining account equals personal_position.pool_id, then thaws it with the pool PDA.
Burns the NFT.
Closes the NFT token account and personal_position, refunding rent to nft_owner. If the position NFT uses Token-2022, it also closes the NFT mint; classic SPL Token mints cannot be closed and remain with supply zero.

The thaw, burn, and close are atomic. The NFT cannot become transferable between those steps. Conditional client break — the declared IDL layout is unchanged, so legacy clients continue to close existing and unfrozen positions. A legacy builder that omits the pool remaining account fails with AccountLack when closing a frozen position. Passing the pool for every close is the simplest compatible strategy.

`SwapV2`

Walk the liquidity curve; exact input or exact output depending on is_base_input. Arguments

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

Accounts (abridged)

#	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 (required for some Token-2022 paths).
12	`input_vault_mint`, `output_vault_mint`			V2.
13	`tick_array_bitmap_extension` (optional)	W		If swap walks into the extension.
14+	`tick_array` (remaining)	W		Enough arrays to span the walk’s expected range.

Callers pass a ranked list of tick arrays covering the expected swap walk; the program uses as many as it needs. The SDK computes this list via PoolUtils.computeAmountOutFormat or the API’s quote endpoint. Preconditions

pool_state.status allows swap.
now >= open_time.
sqrt_price_limit_x64 is on the correct side of sqrt_price_x64 for the direction.

Common errors — TooLittleOutputReceived (exact-in slippage), TooMuchInputPaid (exact-out slippage), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (swap bit set on pool_state.status). CLMM has no ExceededSlippage variant — that name is CPMM’s — and no TickArrayNotFound. What SwapV2 does internally that callers should know about (post-2025 release):

Dynamic fee surcharge — if pool.dynamic_fee_info is non-zero, the program updates the volatility accumulator using the tick distance traversed since the last swap (with the filter/decay rules from products/clmm/fees) and adds a dynamic_fee_component on top of AmmConfig.trade_fee_rate. Total fee is capped at 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
Limit-order matching — when the price walk crosses a tick that holds open limit orders, the program first fills available limit-order liquidity at that tick (FIFO by order_phase), then proceeds along the LP liquidity curve. Filled amounts update tick.unfilled_ratio_x64 and tick.part_filled_orders_remaining for later settlement; orders themselves remain unspent until their owner calls SettleLimitOrder.
Single-sided fee routing — when pool.fee_on = Token0Only or Token1Only, the swap step still computes the same input-output trade; the fee is then routed to the configured side. For directions where the configured fee side is the output, the fee is deducted from the swap output (the user receives out − fee); for directions where it is the input, behavior matches FromInput. See is_fee_on_input(zero_for_one) and is_fee_on_token0(zero_for_one) on PoolState.

Swap (V1) implements the same dynamic fee, single-sided fee routing, and limit-order matching as SwapV2; the only feature it lacks is Token-2022 support — both vaults must be classic SPL Token. Pools with any Token-2022 mint must be swapped via SwapV2. The aggregator and SDK already prefer V2 for every CLMM leg so callers don’t have to branch on mint type.

`OpenLimitOrder`

Place a sell order at a specific tick. The order sits in a per-tick FIFO cohort and fills as price walks past. Arguments

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

Accounts (abridged)

#	Name	W	S	Notes
1	`payer`	W	S	Order owner; pays rent.
2	`pool_state`	W
3	`tick_array`	W		The tick array containing `tick_index`.
4	`limit_order_nonce`	W		PDA. `init_if_needed` — created on the user’s first order under this `nonce_index`.
5	`limit_order`	W		PDA. `init` here.
6	`input_token_account`	W		User’s input ATA. Checked for `frozen`.
7	`output_token_account`	W		User’s output ATA. Not debited on open — required only so the program can confirm it is not `frozen` (i.e. the fill can be delivered later).
8	`input_vault`	W		Pool input vault.
9	`output_vault`	W		Pool output vault. Identifies the output mint for the `output_token_account` / `output_vault_mint` checks.
10	`input_vault_mint`			Token-2022 fee handling.
11	`output_vault_mint`			Mint of the output side (frozen-check pairing).
12	`input_token_program`			SPL or Token-2022.
13	`system_program`			Funds the `limit_order`, `limit_order_nonce` and — if needed — the `tick_array` allocation.

Remaining accounts — [0] tick_array_bitmap_extension, required only when initializing a tick array whose start index falls outside the pool’s inline bitmap. Pass nothing otherwise.

There is no rent account: the struct ends at system_program, 13 declared accounts. A stray rent in position 14 lands exactly where the optional bitmap extension is read, so the order appears to work until the first time a tick array outside the inline bitmap has to be created — and then fails.

Account-list change (2026-07 release). OpenLimitOrder now also takes the output-side accounts — output_token_account, output_vault, and output_vault_mint — in addition to the input side. They are used only for validation: the program rejects the order if the owner’s input or output token account is frozen. This guarantees that a fill can actually be settled to the owner’s output ATA, which matters for allow-list / default-frozen Token-2022 mints (e.g. permissioned tokens) where an account may not yet be thawed. Clients built against the older single-sided account list must add the three output accounts.

Preconditions

Neither input_token_account nor output_token_account is frozen (else NotApproved).
pool_state.status allows both the swap (bit 4) and limit-order (bit 5) operations (else NotApproved).
tick_index % pool.tick_spacing == 0 and within [MIN_TICK, MAX_TICK].
tick_index is on the right side of pool.tick_current for the chosen direction (selling token0 → tick must be above current, and vice versa). Selling at a tick already crossed would be matched immediately and is rejected.

Postconditions

limit_order exists, snapshotting tick.order_phase and tick.unfilled_ratio_x64 at open time.
tick.orders_amount += amount (in the current cohort).
limit_order_nonce.order_nonce += 1.
OpenLimitOrderEvent emitted.

Common errors — NotApproved (input or output token account frozen, or the pool has swap / limit-order disabled), ZeroAmountSpecified (amount == 0 after the input-side transfer fee), InvalidLimitOrderAmount (the amount would produce an output below 1 base unit at that tick, or overflow u64), InvalidTickIndex (out of [MIN_TICK, MAX_TICK], or on the wrong side of tick_current for the chosen direction), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

`IncreaseLimitOrder`

Add to an existing open order. Only callable by the order’s owner. Arguments

amount: u64    // additional input-token amount

Accounts — 8, input side only. It drops the nonce account, all three output-side accounts and 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`

Preconditions

limit_order.owner == signer.
The order is still in the same cohort (tick.order_phase == limit_order.order_phase). If the cohort has already begun filling, the order is partially settled — the caller should call DecreaseLimitOrder or SettleLimitOrder first to roll forward.

Effect

Transfers amount from owner ATA to input_vault.
limit_order.total_amount += amount; tick.orders_amount += amount.

`DecreaseLimitOrder`

Reduce or fully cancel an open order. Pays the unfilled remainder back to the owner, plus any output already settled by past partial fills. Arguments

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

Accounts — both input and output token sides:

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

Effect

Recomputes the order’s filled amount from the cohort’s unfilled_ratio_x64 since open.
Sends filled output to output_token_account.
Sends amount of unfilled input back to input_token_account.
Updates limit_order accordingly. If the new unfilled remainder is zero, the program closes the account and refunds rent to owner.

`SettleLimitOrder`

Push filled output tokens to the owner without changing the order’s unfilled remainder. Useful when auto_withdraw keepers want to drip-pay long-running partial fills. Caller — either the order’s owner, or the program’s limit_order_admin (an off-chain operational hot wallet that runs an automated keeper loop). The keeper has no other authority — it cannot move user funds outside of pushing filled output to the order’s owner ATA. Accounts

#	Name	W	S	Notes
1	`signer`		S	owner or `limit_order_admin`
2	`pool_state`
3	`tick_array`
4	`limit_order`	W
5	`output_token_account`	W		Owner’s output ATA.
6	`output_vault`	W		Pool output vault.
7	`output_vault_mint`
8	`output_token_program`

Effect

Computes the cumulative output owed using (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
Transfers the delta to output_token_account.
Updates limit_order.settled_output.
Does not close the order; it is still open against any remaining input.

`CloseLimitOrder`

Close a fully-consumed order account. Rent is always returned to limit_order.owner regardless of who signs. Caller — either owner or limit_order_admin. Preconditions

The order has zero unfilled remainder (either amount == total_amount was filled and settled, or the owner previously decreased the order to zero and forgot to close).

Effect

Closes limit_order; rent is sent to limit_order.owner.

`CreateDynamicFeeConfig` (admin)

Create a reusable parameter set under a u16 index. Arguments

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

Accounts

#	Name	W	S	Notes
1	`owner`	W	S	Hardcoded admin pubkey.
2	`dynamic_fee_config`	W		PDA, `init` here.
3	`system_program`

Common errors — InvalidDynamicFeeConfigParams if decay_period <= filter_period or any 0-valued field is out of bounds.

`UpdateDynamicFeeConfig` (admin)

Modify an existing DynamicFeeConfig. Pools that already snapshotted the config at creation time are not retroactively updated; only newly-created pools that reference this config will pick up the new values. Arguments — same five calibration fields as CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index is fixed at creation and not re-passed here.

`CollectProtocolFee` / `CollectFundFee`

Sweep accrued protocol/fund fees from the pool’s vaults to a recipient, zeroing the corresponding PoolState.protocol_fees_* / fund_fees_* fields. This is not CPMM’s layout — CLMM has no authority account, and the recipient fields are named recipient_token_account_{0,1} rather than recipient_token_{0,1}_account. Arguments — amount_0_requested: u64, amount_1_requested: u64.

#	Name	W	S	Notes
1	`owner`		S	`amm_config.owner` (or `amm_config.fund_owner` for the fund variant), or the program admin; else `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`

Changed in 2026-09: new configs no longer take their fee owners from the signer. create_amm_config now writes the program’s hardcoded protocol_fee_owner::ID into owner and fund_fee_owner::ID into fund_owner. Before, it copied the admin signer’s key into both. On mainnet these are the same keys already stored on all 21 existing configs. Addresses are in reference/program-addresses.The accepted signers above are unchanged. The admin can still collect from any config, and existing AmmConfig accounts are not rewritten. Read owner / fund_owner off the account instead of assuming either value. UpdateAmmConfig params 3 and 4 still rotate them.

`CollectExcessLamports`

Admin sweep of lamports above the rent-exempt minimum on accounts CLMM controls. It was added in the 2026-09 upgrade to reclaim the over-funding that the SIMD-0437 rent reduction leaves on accounts created before each step. Only the excess moves. Token balances, account data, owners, pool state and the price curve are untouched. An account already at its minimum is left as is, so the instruction can be re-run safely after each rollout step. Arguments: none. Accounts

#	Name	W	S	Notes
1	`collect_lamports_wallet`	W	S	Receives every swept lamport. Must be the CLMM program admin or the dedicated collect-lamports wallet (see `reference/program-addresses`). Any other signer fails with `NotApproved`.
2	`pool_state`	W		The pool being swept. Its PDA seeds sign the token-program CPIs, and the account is always swept itself.
3	`token_program`			SPL Token.
4	`token_program_2022`			Token-2022. Both programs are required; the instruction picks one per source account.
5..	`remaining_accounts`	W		`M` source accounts, any number, any order.

Scope: one pool per call. CLMM has no program-wide vault authority. Each pool’s vaults are owned by its own PoolState. Every token-program source must therefore have the pool_state in slot 2 as its authority: token_vault_0, token_vault_1, or one of that pool’s reward vaults. If you pass another pool’s vault or a user’s token account, the token program’s owner check fails and the whole instruction reverts. It is not skipped. Position NFT mints cannot be swept, because their mint authority is revoked when the position is opened. How each source account is handled The program makes two passes over remaining_accounts: every token-program CPI first, then the direct debits. Interleaving the two aborts with the runtime’s UnbalancedInstruction error, so the order is fixed in the program and you don’t have to sort the list yourself.

Pass	Source account owner	Handling
1	SPL Token or Token-2022, non-native token account	CPI `WithdrawExcessLamports` (token-program discriminant `38`), signed by `pool_state`.
1	SPL Token or Token-2022, native (wSOL) token account	`WithdrawExcessLamports` rejects native accounts. The program CPIs `SyncNative`, measures how much the wrapped `amount` grew, and calls `UnwrapLamports` (discriminant `45`) for exactly that delta. It then requires the wrapped balance to equal its pre-sync value, or fails with `LamportsCalculateError` (`6052`). A SOL-side pool vault keeps its full liquidity.
2	`pool_state` (slot 2)	Debited directly down to `rent.minimum_balance(data_len)`.
2	The CLMM program: `AmmConfig`, `ObservationState`, `TickArrayBitmapExtension`, `TickArrayState`, `PersonalPositionState`, `LimitOrderState`, and so on	Debited directly down to `rent.minimum_balance(data_len)`. The account does not have to belong to the pool in slot 2.
—	Anything else	Skipped silently. No error, no lamports moved.

Pass 2 covers accounts whose rent a user paid. A PersonalPositionState or LimitOrderState passed here gives up its excess like any other CLMM-owned account. It stays rent-exempt and keeps its data. When it is later closed, the owner gets back whatever the account holds at that point, which after a sweep is the current rent minimum.

Transaction size is the real limit on how many sources fit in one call. It is the same constraint as the wallet-side sweep described in solana-fundamentals/rent-and-reclaimable-rent. Common errors:

NotApproved (6000): wrong signer.
LamportsCalculateError (6052): the wSOL round-trip did not net to zero.
A token-program owner-mismatch error: a token source is not owned by pool_state.
InsufficientFunds: a program-owned account holds less than its own rent minimum.

No SDK builder. @raydium-io/raydium-sdk-v2 does not ship a builder for this admin path. Encode it by hand from the IDL.

`InitializeReward`

Add a new reward stream to a pool. Up to 3 streams may be active at once. Arguments — a single struct, param: InitializeRewardParam:

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

The wire encoding is the three fields back to back, so a hand-built instruction is unaffected — but an IDL-driven client must pass one param object rather than three positional arguments. Accounts

#	Name	W	S	Notes
1	`reward_funder`	W	S
2	`funder_token_account`	W
3	`amm_config`
4	`pool_state`	W
5	`operation_state`			CLMM operation-state PDA gating reward creation.
6	`reward_token_mint`
7	`reward_token_vault`	W		`init` here.
8	`reward_token_program`
9	`system_program`, `rent`

Preconditions

Less than 3 streams currently active on the pool.
Funder deposits total_emission = emissions_per_second × (end_time − open_time) worth of reward token into the vault as part of this instruction.
Whitelisted reward mint per operation_state.

`SetRewardParams`

Extend, top up, or change emission rate on an existing reward stream. Typically called by a pool creator or the Raydium multisig. Constraints live on-chain: you can usually extend end_time or increase emissions, not shrink them retroactively. Check operation_state’s owner list.

`UpdateRewardInfos`

Pure bookkeeping — settles reward_growth_global_x64 to the current time by multiplying emissions_per_second × Δt / liquidity. Called internally by every liquidity-touching instruction. Exposed as a standalone instruction because external actors (UIs, cranks) sometimes want to trigger it.

Collecting rewards

There is no standalone collect-reward instruction. The program exposes no CollectReward entrypoint, and the published IDL has none either.

Rewards owed to a position are paid out by DecreaseLiquidity / DecreaseLiquidityV2. To collect without changing the position, call it with liquidity = 0, amount_0_min = 0, amount_1_min = 0. The reward vaults and recipient accounts go in remaining_accounts in groups of three per active reward, in the order reward_token_vault(W), recipient_token_account(W), reward_vault_mint. CollectRemainingRewards is a different thing: it lets the reward funder, after a stream’s end_time, sweep tokens that were never allocated to any position.

State-change matrix

Instruction	`pool.liquidity`	`pool.fee_growth_global`	`pool.reward_growth_global`	`personal_position.liquidity`	Tick array
`CreatePool`	0	0	—	—	—
`OpenPosition`	+ if in range	—	—	new	add liquidity_gross/net
`IncreaseLiquidity`	+ if in range	settle owed	settle owed	+	adjust
`DecreaseLiquidity`	− if in range	settle owed	settle owed	−	adjust
`ClosePosition`	—	—	—	destroyed	—
`SwapV2`	± on crossings	+	—	—	cross & flip outside; match limit-order cohorts
`OpenLimitOrder`	—	—	—	—	`orders_amount += amount` on the target tick
`IncreaseLimitOrder`	—	—	—	—	`orders_amount += amount`
`DecreaseLimitOrder`	—	—	—	—	`orders_amount -=`, may close cohort
`SettleLimitOrder`	—	—	—	—	— (read-only on tick)
`CloseLimitOrder`	—	—	—	—	—
`CreateCustomizablePool`	0	0	—	—	—
`UpdateRewardInfos`	—	—	+	—	—
`CollectExcessLamports`	—	—	—	—	— (lamports only; token balances unchanged)

Where to go next

products/clmm/code-demos — runnable TypeScript samples.
products/clmm/fees — details on fee and reward accrual.
reference/error-codes — complete CLMM Anchor error table.

Sources:

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

Products

Algorithms

Instruction inventory

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig` (admin)

`UpdateDynamicFeeConfig` (admin)

`CollectProtocolFee` / `CollectFundFee`

`CollectExcessLamports`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

State-change matrix

Where to go next

​Instruction inventory

​CreatePool

​CreateCustomizablePool

​CreatePermissionedPool

​OpenPositionV2 / OpenPositionWithToken22Nft

​IncreaseLiquidityV2

​DecreaseLiquidityV2

​ClosePosition

​SwapV2

​OpenLimitOrder

​IncreaseLimitOrder

​DecreaseLimitOrder

​SettleLimitOrder

​CloseLimitOrder

​CreateDynamicFeeConfig (admin)

​UpdateDynamicFeeConfig (admin)

​CollectProtocolFee / CollectFundFee

​CollectExcessLamports

​InitializeReward

​SetRewardParams

​UpdateRewardInfos

​Collecting rewards

​State-change matrix

​Where to go next

Instruction inventory

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig` (admin)

`UpdateDynamicFeeConfig` (admin)

`CollectProtocolFee` / `CollectFundFee`

`CollectExcessLamports`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

State-change matrix

Where to go next