Instructions CLMM

Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →

Cette page s’accompagne de products/clmm/accounts (ce que sont les comptes) et products/clmm/math (ce que sont les mathématiques). Elle fait autorité pour les arguments et l’ordre des comptes ; les dispositions d’octets spécifiques proviennent de l’IDL.

Inventaire des instructions

Groupe	Instruction	Notes
Admin	`CreateAmmConfig`	Définir un nouveau palier de frais.
Admin	`UpdateAmmConfig`	Modifier les taux sur un palier existant.
Admin	`UpdatePoolStatus`	Mettre en pause/reprendre les opérations sur un pool.
Admin	`CreateSupportMintAssociated`	Ajouter à la liste blanche une configuration d’extension de mint Token-2022 pour utilisation dans les pools CLMM.
Admin	`CreateOperationAccount`	Initialiser le compte d’opération au niveau du programme (une seule fois).
Admin	`UpdateOperationAccount`	Modifier la liste blanche du compte d’opération.
Admin	`CreateDynamicFeeConfig`	Créer un ensemble de paramètres de frais dynamiques réutilisable sous un index u16.
Admin	`UpdateDynamicFeeConfig`	Modifier un `DynamicFeeConfig` existant. Les pools qui l’ont déjà capturé ne sont pas affectés.
Admin	`CreatePermissionPda`	Accorder à une autorité le droit d’appeler `CreatePermissionedPool` en initialisant son PDA `Permission`.
Admin	`ClosePermissionPda`	Révoquer une permission précédemment accordée en fermant son PDA `Permission` ; le loyer est remboursé à l’appelant.
Pool	`CreatePool`	Initialiser un pool CLMM lié à un `AmmConfig`. Chemin standard FromInput-fee. Coexiste avec `CreateCustomizablePool`.
Pool	`CreateCustomizablePool`	Recommandé pour les nouveaux pools. Même forme que `CreatePool` plus `collect_fee_on` et un drapeau optionnel `enable_dynamic_fee`.
Pool	`CreatePermissionedPool`	Créer un pool supplémentaire pour une paire qui en a déjà un, en utilisant un `seed_index` fourni par le client plié dans le PDA du pool. Le payeur doit détenir un PDA `Permission`.
Position	`OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft`	Frapper un NFT de position. `OpenPositionV2` remplace V1 ; `OpenPositionWithToken22Nft` émet le NFT en tant que Token-2022. Les chemins V2 gèlent le compte NFT uniquement lorsque l’autorité de gel d’un mint de coffre sous-jacent correspond à la liste des émetteurs restreints. Sinon, le compte reste dégelé.
Position	`IncreaseLiquidity` / `IncreaseLiquidityV2`	Ajouter de la liquidité à une position existante.
Position	`DecreaseLiquidity` / `DecreaseLiquidityV2`	Retirer de la liquidité ; collecte les frais dus.
Position	`ClosePosition`	Brûler le NFT et fermer le `PersonalPositionState`. Si le compte NFT est gelé, le dégeler d’abord avec le PDA du pool fourni en tant que compte restant.
Position	`CloseProtocolPosition`	Balayage réservé à l’admin pour les PDAs `ProtocolPositionState` hérités. Le programme actuel ne crée ni ne lit plus `ProtocolPositionState` — cette instruction existe uniquement pour récupérer le loyer sur les comptes créés par les anciennes versions du programme.
Swap	`Swap` / `SwapV2`	Swap à liquidité constante. Les deux variantes appliquent les frais dynamiques, le routage des frais unilatéraux et l’appariement des ordres limites ; la seule différence est que `SwapV2` accepte les mints Token-2022 (la variante V1 exige que les deux coffres soient du Token SPL classique).
Swap	`SwapRouterBaseIn`	Multi-hop, utilisé par le routeur.
Ordre limite	`OpenLimitOrder`	Placer un ordre de vente à un tick. Les jetons non remplis restent sur le tick ; le moteur d’appariement les remplit à mesure que le prix traverse.
Ordre limite	`IncreaseLimitOrder`	Ajouter à un ordre ouvert existant.
Ordre limite	`DecreaseLimitOrder`	Réduire ou annuler un ordre ouvert ; paie le reste non rempli plus tout résultat déjà réglé.
Ordre limite	`SettleLimitOrder`	Pousser les jetons de résultat remplis vers le propriétaire de l’ordre. Peut être appelé par le propriétaire ou par le gardien opérationnel.
Ordre limite	`CloseLimitOrder`	Fermer un compte d’ordre entièrement consommé. Le loyer revient toujours au `owner` de l’ordre. Peut être appelé par le propriétaire ou le gardien.
Frais	`CollectProtocolFee`	Balayage admin des frais de protocole.
Frais	`CollectFundFee`	Balayage admin des frais de fonds.
Récompenses	`InitializeReward`	Attacher un nouveau flux de récompenses à un pool.
Récompenses	`SetRewardParams`	Modifier le taux d’émission/fin d’une récompense existante.
Récompenses	`UpdateRewardInfos`	Régler la croissance des récompenses à maintenant (appelé par tout swap / changement de position).
Récompenses	`TransferRewardOwner`	Transférer l’autorité qui peut définir ou alimenter un flux de récompenses.
Récompenses	`CollectRemainingRewards`	Après le `end_time` d’un flux de récompenses, balayer tous les jetons non alloués vers le financeur.
Admin	`CloseSupportMintAssociated`	Supprimer l’enregistrement `SupportMintAssociated` d’un mint et rembourser son loyer.

Il n’existe pas d’instruction d’initialisation de tick array, et aucune n’est nécessaire. Un tick array est créé à l’intérieur de OpenPosition* / IncreaseLiquidity* par TickArrayState::get_or_create_tick_array, aux frais de payer. Passez la PDA de tick array (éventuellement encore non initialisée et détenue par le système) comme tick_array_lower / tick_array_upper et le programme l’alloue si elle est absente. OpenLimitOrder fait de même pour son unique tick_array.

La plupart des instructions réservées à l’admin (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) sont contrôlées par la clé admin codée en dur du programme. CreatePermissionPda / ClosePermissionPda acceptent soit la clé admin soit une clé permission_pda_admin dédiée ; CreateSupportMintAssociated / CloseSupportMintAssociated acceptent soit la clé admin soit une clé dédiée de propriétaire des mints supportés. Les instructions d’admin de flux de récompenses (TransferRewardOwner, CollectRemainingRewards) sont contrôlées par le financeur de récompenses, pas par l’admin du programme. Le suffixe V2 signifie « supporte Token-2022 sur les coffres / NFT, nécessite l’emplacement d’extension bitmap ». Le SDK choisit V2 par défaut pour les nouveaux pools.

`CreatePool`

Arguments

sqrt_price_x64: u128           // prix initial
open_time:      u64            // les swaps sont rejetés avant cette heure

Comptes (abrégés)

#	Nom	W	S	Notes
1	`pool_creator`	W	S
2	`amm_config`			Palier de frais choisi.
3	`pool_state`	W		`init` ici.
4	`token_mint_0`			Trié.
5	`token_mint_1`
6	`token_vault_0`	W		`init` ici, détenu par le PDA d’autorité du pool.
7	`token_vault_1`	W
8	`observation_state`	W		`init` ici.
9	`tick_array_bitmap`	W		La PDA `TickArrayBitmapExtension` ; `init` ici.
10	`token_program_0`			Le programme qui possède `token_mint_0` — SPL Token ou Token-2022.
11	`token_program_1`			Le programme qui possède `token_mint_1`.
12	`system_program`
13	`rent`

Les slots 10 et 11 sont par mint, et non « SPL Token puis Token-2022 ». Chacun est contraint par mint::token_program sur le mint correspondant : pour un pool dont le token_mint_0 est Token-2022 et le token_mint_1 du SPL classique, vous devez donc passer Token-2022 dans le slot 10 et SPL Token dans le slot 11. CreateCustomizablePool et CreatePermissionedPool utilisent les deux mêmes slots.

Préconditions

token_mint_0 < token_mint_1 par ordre d’octets.
amm_config.disable_create_pool == false.
Les mints ne sont pas rejetés par la liste blanche d’extension Token-2022.

Postconditions

pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
pool_state.liquidity = 0 (pas de positions encore).
pool_state.fee_on = FromInput (défaut hérité).
pool_state.dynamic_fee_info est mis à zéro (frais dynamiques désactivés).

`CreateCustomizablePool`

Recommandé pour les nouveaux pools. Même effet que CreatePool plus le mode de collecte des frais par pool et un opt-in optionnel pour les frais dynamiques. Arguments

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

Comptes — exactement les 13 comptes déclarés de CreatePool. dynamic_fee_config n’est pas un compte déclaré.

Lorsque enable_dynamic_fee = true, le DynamicFeeConfig à capturer doit être fourni comme dernier remaining_account — le gestionnaire lit ctx.remaining_accounts.last(). Toute PDA de contournement SupportMintAssociated doit donc venir avant lui, sinon le programme capture le mauvais compte et échoue à la désérialisation. L’omettre alors que le drapeau est positionné échoue avec AccountLack.

Préconditions — identiques à CreatePool. Si enable_dynamic_fee = false, aucun remaining_account n’est requis et ceux qui sont passés ne sont analysés qu’à la recherche d’enregistrements de mints supportés. Postconditions

pool_state.fee_on défini à la variante CollectFeeOn choisie.
Si les frais dynamiques ont été activés : pool_state.dynamic_fee_info est initialisé à partir du DynamicFeeConfig fourni (cinq paramètres d’étalonnage copiés ; champs d’état mis à zéro).
Sinon : pool_state.dynamic_fee_info est mis à zéro (= frais dynamiques inactifs à jamais pour ce pool).

fee_on et le bit d’activation des frais dynamiques sont définis uniquement à la création du pool. Il n’y a pas de mise à niveau sur place — les pools créés via le CreatePool hérité ne peuvent pas rétroactivement obtenir des frais dynamiques ou des frais unilatéraux. Les nouveaux déploiements doivent utiliser cette instruction par défaut.

`CreatePermissionedPool`

À la fois CreatePool et CreateCustomizablePool dérivent le PDA du pool de ["pool", amm_config, token_mint_0, token_mint_1], donc il y a exactement une adresse de pool canonique par triplet (config, mint0, mint1) — un second init aux mêmes graines échoue. CreatePermissionedPool lève cette restriction en pliant un seed_index: u16 fourni par le client dans les graines du PDA du pool, permettant plusieurs pools pour la même paire et palier de frais — chacun à sa propre adresse. Parce qu’une adresse de pool arbitraire est une capacité privilégiée, le payeur doit détenir un PDA Permission qui l’autorise. Tout le reste du pool est identique à CreateCustomizablePool : il prend les mêmes CreateCustomizableParams et supporte les frais unilatéraux et l’opt-in pour les frais dynamiques. Arguments

customizable_params: CreateCustomizableParams   // même struct que CreateCustomizablePool
seed_index:          u16                          // doit être non-zéro ; plié dans les graines du PDA du pool

Comptes (abrégés) — identiques à CreateCustomizablePool plus, au début :

#	Nom	W	S	Notes
1	`payer`	W	S	Paie le loyer. Doit être l’autorité du PDA `permission` ci-dessous.
2	`pool_creator`			Enregistré comme `pool_state.owner`. Peut différer de `payer`.
3	`permission`			PDA `["permission", payer]`. Anchor rejette l’appel s’il n’existe pas / n’est pas détenu par le programme.
…	(`amm_config`, `pool_state`, mints, coffres, `observation_state`, `tick_array_bitmap`, programmes token/système)			Comme dans `CreateCustomizablePool`.

Le PDA pool_state est dérivé de ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]. Préconditions

seed_index != 0. Un seed_index de 0 est réservé aux pools hérités et est rejeté ici ; la composante de graine [0, 0] est ce qui fait qu’une adresse de pool hérité s’effondre à la forme classique à quatre graines.
Le PDA permission pour payer existe (créé par un admin via CreatePermissionPda).
Mêmes règles de mint / liste blanche que CreatePool.

Postconditions

Un nouveau pool_state existe à l’adresse dérivée de seed_index, avec pool_state.seed_index = seed_index.
Tout autre post-état correspond à CreateCustomizablePool (mode de frais, frais dynamiques optionnels).

Cette instruction ne pas élargir l’accès général à la création de pools — la création sans permission continue via CreatePool / CreateCustomizablePool, qui restent un-pool-par-paire. CreatePermissionedPool existe pour le cas spécifique où un opérateur sur liste blanche a besoin de plusieurs pools pour la même paire (par exemple, prix initiaux différents ou cohortes de lancement) et détient un PDA Permission accordé par l’admin.

`OpenPositionV2` / `OpenPositionWithToken22Nft`

Créer une nouvelle position à l’intérieur d’un pool existant. Arguments

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // L désiré (ou 0 pour utiliser les montants ci-dessous)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // écrire les métadonnées NFT (Metaplex)
base_flag: Option<bool>       // true = adapter à amount0 ; false = adapter à amount1

Comptes (abrégés)

#	Nom	W	S	Notes
1	`payer`	W	S
2	`position_nft_owner`
3	`position_nft_mint`	W	S	Nouvelle keypair.
4	`position_nft_account`	W		ATA du propriétaire pour le NFT.
5	`metadata_account`	W		PDA de métadonnées Metaplex. Déclaré inconditionnellement, même lorsque `with_metadata = false`.
6	`pool_state`	W
7	`protocol_position`			Résiduel ; `UncheckedAccount` en lecture seule.
8	`tick_array_lower`	W		Créé ici s’il n’est pas initialisé.
9	`tick_array_upper`	W		Idem.
10	`personal_position`	W		Créé ici.
11	`token_account_0`	W		ATA source de l’utilisateur.
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 est la même liste avec metadata_account (5) et metadata_program (19) retirés — il écrit les métadonnées de la position via l’extension de métadonnées Token-2022 sur le mint du NFT — soit 20 comptes. Son position_nft_mint est un simple Signer et son position_nft_account un UncheckedAccount.

tick_array_bitmap_extension n’est un compte déclaré sur aucune des deux variantes. Lorsque la plage de la position sort du tick_array_bitmap inline du pool (±512 tick arrays), ajoutez la PDA TickArrayBitmapExtension aux seeds ["pool_tick_array_bitmap_extension", pool_state] comme remaining_accounts[0].

Mathématiques — voir products/clmm/math. Donné base_flag, le programme résout soit liquidity soit (amount_0_max, amount_1_max) en L réel et les montants de jetons réels consommés. Préconditions

tick_lower < tick_upper, tous deux multiples de pool.tick_spacing, dans [MIN_TICK, MAX_TICK].
Les deux PDAs de tick array sont passées. Elles n’ont pas besoin d’exister déjà — get_or_create_tick_array alloue celle qui manque aux frais du payer, à l’intérieur de cette instruction. Il n’existe pas d’instruction distincte d’initialisation de tick array.
L’utilisateur a au moins amount_0_max et amount_1_max dans les ATAs source.

Postconditions

personal_position existe, liquidity défini, fee_growth_inside_last capturé.
Les entrées du tick-array à tick_lower et tick_upper mises à jour (liquidity_gross += L, liquidity_net ± L, instantanés de croissance des frais maintenus).
pool_state.liquidity += L si la position est en plage (tick_lower ≤ tick_current < tick_upper).
Le mint NFT de la position enregistre pool_state comme autorité de gel. L’autorité de mint est supprimée après que le seul NFT soit frappé. L’enregistrement de l’autorité de gel ne change pas l’état du compte de jeton NFT.
Le compte de jeton NFT reste dégelé sauf si l’instruction est OpenPositionV2 ou OpenPositionWithToken22Nft et que l’autorité de gel de l’un des mints de coffre correspond à la liste des émetteurs restreints de CLMM. Seul ce chemin V2 correspondant gèle le compte. OpenPosition V1 ne gèle pas.

Erreurs courantes — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (une extrémité n’est pas un multiple de tick_spacing), InvalidTickIndex (en dehors de [MIN_TICK, MAX_TICK]), MissingTickArrayBitmapExtensionAccount (plage en dehors du bitmap inline et extension non ajoutée), NotApproved (pool_state.status bloque l’ouverture), ZeroAmountSpecified.

Le gel de position n’ajoute pas de comptes d’instruction déclarés ou d’arguments. Les clients peuvent ouvrir ces positions avec les dispositions V2 existantes. Le comportement est sélectionné on-chain à partir de vault_0_mint et vault_1_mint.

`IncreaseLiquidityV2`

Ajouter de la liquidité à une position déjà ouverte. Arguments

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

Comptes — 15, et non dérivables de OpenPosition : il n’y a ni rent, ni system_program, ni associated_token_program, ni compte de métadonnées.

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

Ajoutez la PDA TickArrayBitmapExtension en tête, comme remaining_accounts[0], lorsque la plage de la position sort du bitmap inline. Effet

Transfère amount_0_actual / amount_1_actual de l’utilisateur → coffres.
Incrémente personal_position.liquidity et pool_state.liquidity (si en plage), et le liquidity_gross / liquidity_net du tick d’extrémité en conséquence.
Collecte les frais et récompenses dus depuis le dernier toucher et les crédite à token_fees_owed_{0,1} / reward_amount_owed. Ceux-ci ne sont payés que sur DecreaseLiquidity / DecreaseLiquidityV2, pas sur l’augmentation — il n’existe pas d’instruction de collecte autonome.

`DecreaseLiquidityV2`

Retirer de la liquidité d’une position. Arguments

liquidity: u128
amount_0_min: u64
amount_1_min: u64

Comptes — 16, et pas la même forme ni le même ordre que IncreaseLiquidityV2 : personal_position et pool_state sont inversés, les coffres viennent avant les tick arrays, les comptes côté utilisateur sont nommés recipient_token_account_*, et il y a un memo_program supplémentaire.

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

Comptes restants — trois par récompense active collectée, dans l’ordre reward_token_vault(W), recipient_token_account(W), reward_vault_mint. Ajoutez en tête la PDA TickArrayBitmapExtension lorsque la plage de la position sort du bitmap inline.

C’est aussi le seul moyen de collecter les frais et les récompenses. Pour collecter sans modifier la position, appelez-la avec liquidity = 0, amount_0_min = 0, amount_1_min = 0.

Effet

Calcule (amount_0, amount_1) pour le L retiré donné le sqrt_price_x64 actuel.
Règle les frais/récompenses accumulés depuis le dernier toucher, comme IncreaseLiquidity.
Transfère amount_0 + fees_owed_0 et amount_1 + fees_owed_1 hors des coffres vers l’utilisateur.
Décrémente les compteurs de liquidité ; si le nouveau personal_position.liquidity == 0, la position est éligible pour ClosePosition.

Slippage — amount_0_min et amount_1_min sont les minimums que l’utilisateur accepte nets des frais de transfert Token-2022 du côté de la sortie.

`ClosePosition`

Brûler le NFT de position et fermer PersonalPositionState. Comptes déclarés

#	Nom	W	S	Notes
1	`nft_owner`	W	S	Doit détenir le compte de jeton NFT détenant le montant `1`.
2	`position_nft_mint`	W		Doit correspondre à `personal_position.nft_mint`.
3	`position_nft_account`	W		Compte du propriétaire du NFT ; peut être Token SPL classique ou Token-2022.
4	`personal_position`	W		Fermé à `nft_owner`.
5	`system_program`			Ferme l’état de position.
6	`token_program`			Doit détenir le mint NFT et le compte de jeton.

Comptes restants

NFT dégelé : aucun requis ; un compte de pool supplémentaire est inoffensif car le gestionnaire ne le lit pas.
NFT gelé : ajouter personal_position.pool_id comme premier compte restant. Le programme le charge comme PoolState et utilise ses graines PDA pour signer le dégel.

Préconditions

personal_position.liquidity == 0.
tokens_fees_owed_{0,1} == 0.
Tous les compteurs de récompenses reward_amount_owed == 0.

(C’est-à-dire, collecter tout et diminuer à zéro d’abord.) Effet

Si le compte de jeton NFT est gelé, vérifie que le premier compte restant égale personal_position.pool_id, puis le dégèle avec le PDA du pool.
Brûle le NFT.
Ferme le compte de jeton NFT et personal_position, remboursant le loyer à nft_owner. Si le NFT de position utilise Token-2022, il ferme également le mint NFT ; les mints Token SPL classiques ne peuvent pas être fermés et restent avec l’approvisionnement zéro.

Le dégel, la combustion et la fermeture sont atomiques. Le NFT ne peut pas devenir transférable entre ces étapes. Rupture client conditionnelle — la disposition IDL déclarée est inchangée, donc les clients hérités continuent à fermer les positions existantes et dégelées. Un constructeur hérité qui omet le compte de pool restant échoue avec AccountLack lors de la fermeture d’une position gelée. Passer le pool pour chaque fermeture est la stratégie compatible la plus simple.

`SwapV2`

Parcourir la courbe de liquidité ; entrée exacte ou sortie exacte selon is_base_input. Arguments

amount: u64                  // entrée si is_base_input=true, sortie sinon
other_amount_threshold: u64  // min out ou max in
sqrt_price_limit_x64: u128   // limite dure ; 0 ⇒ illimité
is_base_input: bool

Comptes (abrégés)

#	Nom	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 (requis pour certains chemins Token-2022).
12	`input_vault_mint`, `output_vault_mint`			V2.
13	`tick_array_bitmap_extension` (optionnel)	W		Si le swap marche dans l’extension.
14+	`tick_array` (restants)	W		Assez de tableaux pour couvrir la plage attendue de la marche.

Les appelants passent une liste classée de tick arrays couvrant la marche de swap attendue ; le programme en utilise autant qu’il en a besoin. Le SDK calcule cette liste via PoolUtils.computeAmountOutFormat ou le point de terminaison de devis de l’API. Préconditions

pool_state.status permet le swap.
now >= open_time.
sqrt_price_limit_x64 est du bon côté de sqrt_price_x64 pour la direction.

Erreurs courantes — TooLittleOutputReceived (slippage en entrée exacte), TooMuchInputPaid (slippage en sortie exacte), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (bit de swap positionné sur pool_state.status). Le CLMM n’a pas de variante ExceededSlippage — ce nom est celui du CPMM — ni de TickArrayNotFound. Ce que SwapV2 fait en interne que les appelants doivent savoir (version post-2025) :

Surcharge de frais dynamiques — si pool.dynamic_fee_info est non-zéro, le programme met à jour l’accumulateur de volatilité en utilisant la distance de tick parcourue depuis le dernier swap (avec les règles de filtre/décroissance de products/clmm/fees) et ajoute un dynamic_fee_component en plus de AmmConfig.trade_fee_rate. Le frais total est plafonné à 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
Appariement des ordres limites — lorsque la marche de prix traverse un tick qui détient des ordres limites ouverts, le programme remplit d’abord la liquidité d’ordre limite disponible à ce tick (FIFO par order_phase), puis procède le long de la courbe de liquidité LP. Les montants remplis mettent à jour tick.unfilled_ratio_x64 et tick.part_filled_orders_remaining pour le règlement ultérieur ; les ordres eux-mêmes restent non dépensés jusqu’à ce que leur propriétaire appelle SettleLimitOrder.
Routage des frais unilatéraux — lorsque pool.fee_on = Token0Only ou Token1Only, l’étape de swap calcule toujours le même échange entrée-sortie ; le frais est ensuite acheminé vers le côté configuré. Pour les directions où le côté de frais configuré est la sortie, le frais est déduit de la sortie du swap (l’utilisateur reçoit out − fee) ; pour les directions où il est l’entrée, le comportement correspond à FromInput. Voir is_fee_on_input(zero_for_one) et is_fee_on_token0(zero_for_one) sur PoolState.

Swap (V1) implémente les mêmes frais dynamiques, routage des frais unilatéraux et appariement des ordres limites que SwapV2 ; la seule fonctionnalité qu’il manque est le support Token-2022 — les deux coffres doivent être du Token SPL classique. Les pools avec n’importe quel mint Token-2022 doivent être échangés via SwapV2. L’agrégateur et le SDK préfèrent déjà V2 pour chaque jambe CLMM, donc les appelants n’ont pas à se brancher sur le type de mint.

`OpenLimitOrder`

Placer un ordre de vente à un tick spécifique. L’ordre reste dans une cohorte FIFO par tick et se remplit à mesure que le prix traverse. Arguments

nonce_index:    u8       // index de compte nonce choisi par l'utilisateur (0..255 par portefeuille)
zero_for_one:   bool     // true : vendre token0 pour token1 ; false : vendre token1 pour token0
tick_index:     i32      // doit être un multiple de pool.tick_spacing
amount:         u64      // montant du jeton d'entrée

Comptes (abrégés)

#	Nom	W	S	Notes
1	`payer`	W	S	Propriétaire de l’ordre ; paie le loyer.
2	`pool_state`	W
3	`tick_array`	W		Le tick array contenant `tick_index`.
4	`limit_order_nonce`	W		PDA. `init_if_needed` — créé au premier ordre de l’utilisateur sous ce `nonce_index`.
5	`limit_order`	W		PDA. `init` ici.
6	`input_token_account`	W		ATA d’entrée de l’utilisateur. Vérifiée pour `frozen`.
7	`output_token_account`	W		ATA de sortie de l’utilisateur. Non débitée à l’ouverture — requise uniquement pour que le programme puisse confirmer qu’elle n’est pas `frozen` (c’est-à-dire que le remplissage peut être livré plus tard).
8	`input_vault`	W		Coffre d’entrée du pool.
9	`output_vault`	W		Coffre de sortie du pool. Identifie le mint de sortie pour les vérifications `output_token_account` / `output_vault_mint`.
10	`input_vault_mint`			Gestion des frais Token-2022.
11	`output_vault_mint`			Mint du côté de sortie (appariement de vérification gelée).
12	`input_token_program`			SPL ou Token-2022.
13	`system_program`			Finance l’allocation de `limit_order`, de `limit_order_nonce` et — si nécessaire — du `tick_array`.

Comptes restants — [0] tick_array_bitmap_extension, requis uniquement lors de l’initialisation d’un tick array dont l’index de début sort du bitmap inline du pool. Ne passez rien sinon.

Il n’y a aucun compte rent : la struct se termine à system_program, soit 13 comptes déclarés. Un rent égaré en position 14 atterrit exactement là où l’extension bitmap optionnelle est lue, de sorte que l’ordre semble fonctionner jusqu’à la première fois où un tick array situé en dehors du bitmap inline doit être créé — et échoue alors.

Changement de liste de comptes (version 2026-07). OpenLimitOrder prend maintenant aussi les comptes du côté de la sortie — output_token_account, output_vault et output_vault_mint — en plus du côté d’entrée. Ils sont utilisés uniquement pour la validation : le programme rejette l’ordre si le compte de jeton d’entrée ou de sortie du propriétaire est gelé. Cela garantit qu’un remplissage peut réellement être réglé à l’ATA de sortie du propriétaire, ce qui importe pour les mints Token-2022 avec liste blanche / gelés par défaut (par exemple, jetons autorisés) où un compte peut ne pas encore être dégelé. Les clients construits contre la liste de comptes unilatérale plus ancienne doivent ajouter les trois comptes de sortie.

Préconditions

Ni input_token_account ni output_token_account n’est gelé (sinon NotApproved).
pool_state.status permet à la fois le swap (bit 4) et les opérations d’ordre limite (bit 5) (sinon NotApproved).
tick_index % pool.tick_spacing == 0 et dans [MIN_TICK, MAX_TICK].
tick_index est du bon côté de pool.tick_current pour la direction choisie (vendre token0 → le tick doit être au-dessus du courant, et vice versa). Vendre à un tick déjà traversé serait immédiatement appariée et est rejeté.

Postconditions

limit_order existe, capturant tick.order_phase et tick.unfilled_ratio_x64 au moment de l’ouverture.
tick.orders_amount += amount (dans la cohorte actuelle).
limit_order_nonce.order_nonce += 1.
OpenLimitOrderEvent émis.

Erreurs courantes — NotApproved (compte de jeton d’entrée ou de sortie gelé, ou le pool a le swap / ordre limite désactivé), ZeroAmountSpecified (amount == 0 après les frais de transfert côté entrée), InvalidLimitOrderAmount (le montant produirait une sortie inférieure à 1 unité de base à ce tick, ou déborderait u64), InvalidTickIndex (hors de [MIN_TICK, MAX_TICK], ou du mauvais côté de tick_current pour la direction choisie), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

`IncreaseLimitOrder`

Ajouter à un ordre ouvert existant. Uniquement appelable par le owner de l’ordre. Arguments

amount: u64    // montant supplémentaire du jeton d'entrée

Comptes — 8, côté entrée uniquement. Il supprime le compte de nonce, les trois comptes côté sortie et system_program.

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

Préconditions

limit_order.owner == signer.
L’ordre est toujours dans la même cohorte (tick.order_phase == limit_order.order_phase). Si la cohorte a déjà commencé à se remplir, l’ordre est partiellement réglé — l’appelant doit d’abord appeler DecreaseLimitOrder ou SettleLimitOrder pour avancer.

Effet

Transfère amount de l’ATA du propriétaire à input_vault.
limit_order.total_amount += amount ; tick.orders_amount += amount.

`DecreaseLimitOrder`

Réduire ou annuler complètement un ordre ouvert. Paie le reste non rempli au propriétaire, plus tout résultat déjà réglé par les remplissages partiels passés. Arguments

amount:     u64    // montant du jeton d'entrée à retirer (max = reste non rempli)
amount_min: u64    // plancher de slippage sur le retrait du côté d'entrée

Comptes — côtés d’entrée et de sortie du jeton :

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

Effet

Recalcule le montant rempli de l’ordre à partir du unfilled_ratio_x64 de la cohorte depuis l’ouverture.
Envoie la sortie remplie à output_token_account.
Envoie amount de l’entrée non remplie de retour à input_token_account.
Met à jour limit_order en conséquence. Si le nouveau reste non rempli est zéro, le programme ferme le compte et rembourse le loyer à owner.

`SettleLimitOrder`

Pousser les jetons de sortie remplis vers le propriétaire sans modifier le reste non rempli de l’ordre. Utile lorsque les gardiens auto_withdraw veulent verser progressivement les remplissages partiels de longue durée. Appelant — soit le owner de l’ordre, soit le limit_order_admin du programme (un portefeuille chaud opérationnel hors chaîne qui exécute une boucle de gardien automatisée). Le gardien n’a aucune autre autorité — il ne peut pas déplacer les fonds de l’utilisateur en dehors de pousser la sortie remplie à l’ATA owner. Comptes

#	Nom	W	S	Notes
1	`signer`		S	propriétaire ou `limit_order_admin`
2	`pool_state`
3	`tick_array`
4	`limit_order`	W
5	`output_token_account`	W		ATA de sortie du propriétaire.
6	`output_vault`	W		Coffre de sortie du pool.
7	`output_vault_mint`
8	`output_token_program`

Effet

Calcule la sortie cumulative due en utilisant (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
Transfère le delta à output_token_account.
Met à jour limit_order.settled_output.
Ne ferme pas l’ordre ; il est toujours ouvert contre toute entrée restante.

`CloseLimitOrder`

Fermer un compte d’ordre entièrement consommé. Le loyer est toujours retourné à limit_order.owner quel que soit le signataire. Appelant — soit owner soit limit_order_admin. Préconditions

L’ordre a un reste non rempli zéro (soit amount == total_amount a été rempli et réglé, soit le propriétaire a précédemment réduit l’ordre à zéro et a oublié de fermer).

Effet

Ferme limit_order ; le loyer est envoyé à limit_order.owner.

`CreateDynamicFeeConfig` (admin)

Créer un ensemble de paramètres réutilisable sous un index u16. Arguments

index:                       u16
filter_period:               u16   // secondes ; par exemple 30
decay_period:                u16   // secondes ; par exemple 600. Doit être > filter_period
reduction_factor:            u16   // 1..10_000 ; par exemple 5_000 = 50% de rétention par fenêtre de décroissance
dynamic_fee_control:         u32   // 1..100_000 ; gain sur la courbe volatilité-frais
max_volatility_accumulator:  u32   // plafond

Comptes

#	Nom	W	S	Notes
1	`owner`	W	S	Clé admin codée en dur.
2	`dynamic_fee_config`	W		PDA, `init` ici.
3	`system_program`

Erreurs courantes — InvalidDynamicFeeConfigParams si decay_period <= filter_period ou tout champ à valeur zéro est hors limites.

`UpdateDynamicFeeConfig` (admin)

Modifier un DynamicFeeConfig existant. Les pools qui ont déjà capturé la configuration à la création ne sont pas rétroactivement mis à jour ; seuls les pools nouvellement créés qui référencent cette configuration reprendront les nouvelles valeurs. Arguments — mêmes cinq champs d’étalonnage que CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator) ; index est fixé à la création et n’est pas re-passé ici.

`CollectProtocolFee` / `CollectFundFee`

Balayer les frais de protocole/fonds accumulés des coffres du pool vers un destinataire, en mettant à zéro les champs correspondants PoolState.protocol_fees_* / fund_fees_*. Ce n’est pas le layout du CPMM — le CLMM n’a pas de compte authority, et les champs de destinataire sont nommés recipient_token_account_{0,1} plutôt que recipient_token_{0,1}_account. Arguments — amount_0_requested: u64, amount_1_requested: u64.

#	Nom	W	S	Notes
1	`owner`		S	`amm_config.owner` (ou `amm_config.fund_owner` pour la variante fonds), ou l’admin du programme ; sinon `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`

`InitializeReward`

Ajouter un nouveau flux de récompenses à un pool. Jusqu’à 3 flux peuvent être actifs à la fois. Arguments — une struct unique, param: InitializeRewardParam, soit un seul argument param :

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

L’encodage de transmission place les trois champs bout à bout, de sorte qu’une instruction construite à la main n’est pas affectée — mais un client piloté par l’IDL doit passer un unique objet param plutôt que trois arguments positionnels. Comptes

#	Nom	W	S	Notes
1	`reward_funder`	W	S
2	`funder_token_account`	W
3	`amm_config`
4	`pool_state`	W
5	`operation_state`			PDA d’état d’opération CLMM contrôlant la création de récompenses.
6	`reward_token_mint`
7	`reward_token_vault`	W		`init` ici.
8	`reward_token_program`
9	`system_program`, `rent`

Préconditions

Moins de 3 flux actuellement actifs sur le pool.
Le financeur dépose total_emission = emissions_per_second × (end_time − open_time) de jeton de récompense dans le coffre dans le cadre de cette instruction.
Mint de récompense sur liste blanche par operation_state.

`SetRewardParams`

Étendre, alimenter ou modifier le taux d’émission sur un flux de récompenses existant. Généralement appelé par un créateur de pool ou le multisig Raydium. Les contraintes vivent on-chain : vous pouvez généralement étendre end_time ou augmenter les émissions, pas les réduire rétroactivement. Vérifiez la liste des propriétaires de operation_state.

`UpdateRewardInfos`

Pur comptage — règle reward_growth_global_x64 à l’heure actuelle en multipliant emissions_per_second × Δt / liquidity. Appelé en interne par chaque instruction touchant la liquidité. Exposé en tant qu’instruction autonome car les acteurs externes (UIs, cranks) veulent parfois le déclencher.

Collecting rewards

Il n’existe pas d’instruction autonome de collecte de récompense. Le programme n’expose aucun point d’entrée CollectReward, et l’IDL publié n’en contient pas non plus.

Les récompenses dues à une position sont payées par DecreaseLiquidity / DecreaseLiquidityV2. Pour collecter sans modifier la position, appelez-la avec liquidity = 0, amount_0_min = 0, amount_1_min = 0. Les coffres de récompense et les comptes destinataires vont dans remaining_accounts par groupes de trois par récompense active, dans l’ordre reward_token_vault(W), recipient_token_account(W), reward_vault_mint. CollectRemainingRewards est autre chose : il permet au financeur des récompenses, après le end_time d’un flux, de balayer les jetons qui n’ont jamais été alloués à une position.

Matrice de changement d’état

Instruction	`pool.liquidity`	`pool.fee_growth_global`	`pool.reward_growth_global`	`personal_position.liquidity`	Tick array
`CreatePool`	0	0	—	—	—
`OpenPosition`	+ si en plage	—	—	nouveau	ajouter liquidity_gross/net
`IncreaseLiquidity`	+ si en plage	régler dû	régler dû	+	ajuster
`DecreaseLiquidity`	− si en plage	régler dû	régler dû	−	ajuster
`ClosePosition`	—	—	—	détruit	—
`SwapV2`	± sur traversées	+	—	—	traverser & basculer dehors ; appariement des cohortes d’ordres limites
`OpenLimitOrder`	—	—	—	—	`orders_amount += amount` sur le tick cible
`IncreaseLimitOrder`	—	—	—	—	`orders_amount += amount`
`DecreaseLimitOrder`	—	—	—	—	`orders_amount -=`, peut fermer la cohorte
`SettleLimitOrder`	—	—	—	—	— (lecture seule sur le tick)
`CloseLimitOrder`	—	—	—	—	—
`CreateCustomizablePool`	0	0	—	—	—
`UpdateRewardInfos`	—	—	+	—	—

Où aller ensuite

products/clmm/code-demos — exemples TypeScript exécutables.
products/clmm/fees — détails sur l’accumulation des frais et récompenses.
reference/error-codes — table d’erreur Anchor CLMM complète.

Sources :

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

Produits

Algorithmes

Inventaire des instructions

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig` (admin)

`UpdateDynamicFeeConfig` (admin)

`CollectProtocolFee` / `CollectFundFee`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

Matrice de changement d’état

Où aller ensuite

​Inventaire des instructions

​CreatePool

​CreateCustomizablePool

​CreatePermissionedPool

​OpenPositionV2 / OpenPositionWithToken22Nft

​IncreaseLiquidityV2

​DecreaseLiquidityV2

​ClosePosition

​SwapV2

​OpenLimitOrder

​IncreaseLimitOrder

​DecreaseLimitOrder

​SettleLimitOrder

​CloseLimitOrder

​CreateDynamicFeeConfig (admin)

​UpdateDynamicFeeConfig (admin)

​CollectProtocolFee / CollectFundFee

​InitializeReward

​SetRewardParams

​UpdateRewardInfos

​Collecting rewards

​Matrice de changement d’état

​Où aller ensuite

Inventaire des instructions

`CreatePool`

`CreateCustomizablePool`

`CreatePermissionedPool`

`OpenPositionV2` / `OpenPositionWithToken22Nft`

`IncreaseLiquidityV2`

`DecreaseLiquidityV2`

`ClosePosition`

`SwapV2`

`OpenLimitOrder`

`IncreaseLimitOrder`

`DecreaseLimitOrder`

`SettleLimitOrder`

`CloseLimitOrder`

`CreateDynamicFeeConfig` (admin)

`UpdateDynamicFeeConfig` (admin)

`CollectProtocolFee` / `CollectFundFee`

`InitializeReward`

`SetRewardParams`

`UpdateRewardInfos`

Collecting rewards

Matrice de changement d’état

Où aller ensuite