> ## Documentation Index > Fetch the complete documentation index at: https://docs.raydium.io/llms.txt > Use this file to discover all available pages before exploring further. # Instructions CLMM > Référence complète des instructions CLMM : cycle de vie du pool, gestion des positions, swap et flux de récompenses. **Cette page est traduite automatiquement par IA. La version anglaise fait foi.** [Voir la version anglaise →](/products/clmm/instructions) Cette page est complémentaire de [`products/clmm/accounts`](/fr/products/clmm/accounts) (description des comptes) et de [`products/clmm/math`](/fr/products/clmm/math) (description des calculs). Elle fait autorité pour les arguments et l'ordre des comptes ; les dispositions d'octets précises proviennent de l'IDL. ## Inventaire des instructions | Groupe | Instruction | Notes | | ------------ | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Admin | `CreateAmmConfig` | Définir un nouveau palier de frais. | | Admin | `UpdateAmmConfig` | Modifier les taux d'un palier existant. | | Admin | `UpdatePoolStatus` | Mettre en pause/reprendre les opérations d'un pool. | | Admin | `CreateSupportMintAssociated` | Inscrire sur 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 (opération unique). | | Admin | `UpdateOperationAccount` | Modifier la liste blanche du compte d'opération. | | Admin | `CreateDynamicFeeConfig` | Créer un jeu de paramètres de frais dynamiques réutilisable sous un index u16. | | Admin | `UpdateDynamicFeeConfig` | Modifier un `DynamicFeeConfig` existant. Les pools ayant déjà pris un instantané de cette config ne sont pas affectés. | | Pool | `CreatePool` | Initialiser un pool CLMM lié à un `AmmConfig`. Chemin de frais standard FromInput. Coexiste avec `CreateCustomizablePool`. | | Pool | `CreateCustomizablePool` | Recommandé pour les nouveaux pools. Même structure que `CreatePool`, avec en plus `collect_fee_on` et un indicateur optionnel `enable_dynamic_fee`. | | Position | `OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft` | Émettre un NFT de position. `OpenPositionV2` remplace la V1 (nouvelle disposition des comptes avec l'emplacement d'extension bitmap) ; `OpenPositionWithToken22Nft` émet le NFT de position en Token-2022 plutôt qu'en SPL Token. Le nouveau code devrait utiliser la V2 ou la variante Token-2022. | | 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`. | | Position | `CloseProtocolPosition` | Nettoyage réservé à l'admin pour les PDAs `ProtocolPositionState` hérités. Le programme actuel ne crée ni ne lit plus le `ProtocolPositionState` — cette instruction existe uniquement pour récupérer le loyer des comptes créés par d'anciennes versions du programme. | | Swap | `Swap` / `SwapV2` | Swap à liquidité constante. Les deux variantes appliquent les frais dynamiques, le routage de frais unilatéral et la correspondance d'ordres limités ; la seule différence est que `SwapV2` accepte les mints Token-2022 (la variante V1 exige que les deux coffres soient des SPL Token classiques). | | Swap | `SwapRouterBaseIn` | Multi-hop, utilisé par le routeur. | | Ordre limité | `OpenLimitOrder` | Placer un ordre de vente à un tick. Les tokens non exécutés restent sur le tick ; le moteur de correspondance les exécute au fur et à mesure que le prix le franchit. | | Ordre limité | `IncreaseLimitOrder` | Augmenter un ordre ouvert existant. | | Ordre limité | `DecreaseLimitOrder` | Réduire ou annuler un ordre ouvert ; verse le reliquat non exécuté ainsi que toute sortie déjà réglée. | | Ordre limité | `SettleLimitOrder` | Transférer les tokens de sortie exécutés vers le propriétaire de l'ordre. Peut être appelé par le propriétaire ou par le keeper opérationnel. | | Ordre limité | `CloseLimitOrder` | Fermer un compte d'ordre entièrement consommé. Le loyer est toujours restitué au `owner` de l'ordre. Peut être appelé par le propriétaire ou le keeper. | | Frais | `CollectProtocolFee` | Collecte admin des frais de protocole. | | Frais | `CollectFundFee` | Collecte 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/la fin d'une récompense existante. | | Récompenses | `UpdateRewardInfos` | Mettre à jour la croissance des récompenses jusqu'à maintenant (appelé par tout swap ou changement de position). | | Récompenses | `TransferRewardOwner` | Transférer l'autorité permettant de définir ou d'alimenter un flux de récompenses. | | Récompenses | `CollectRemainingRewards` | Après le `end_time` d'un flux de récompenses, récupérer les tokens non alloués vers le financeur. | | Utilitaire | `InitTickArray` | Initialiser un compte de tableau de ticks (souvent regroupé avec `OpenPosition`). | La plupart des instructions réservées à l'admin (`CreateAmmConfig`, `UpdateAmmConfig`, `UpdatePoolStatus`, `CreateSupportMintAssociated`, `CreateOperationAccount`, `UpdateOperationAccount`, `CloseProtocolPosition`) sont contrôlées par la clé publique `admin` codée en dur dans le programme. Les instructions d'administration des flux de récompenses (`TransferRewardOwner`, `CollectRemainingRewards`) sont contrôlées par le financeur de la récompense, et non par l'admin du programme. Le suffixe V2 signifie « prend en charge Token-2022 sur les coffres / NFT, nécessite l'emplacement d'extension bitmap ». Le SDK sélectionne 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 (résumé)** | # | 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, propriété du PDA d'autorité du pool. | | 7 | `token_vault_1` | W | | | | 8 | `observation_state` | W | | `init` ici. | | 9 | `tick_array_bitmap_extension` | W | | `init` ici (V2). | | 10 | `token_program` | | | | | 11 | `token_program_2022` | | | | | 12 | `system_program`, `rent` | | | | **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'extensions Token-2022. **Postconditions** * `pool_state.sqrt_price_x64 = sqrt_price_x64`, `tick_current = floor(log_{1.0001}(price))`. * `pool_state.liquidity = 0` (aucune position pour l'instant). * `pool_state.fee_on = FromInput` (valeur par défaut héritée). * `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`, avec en plus un mode de collecte de frais par pool et une activation optionnelle des frais dynamiques. **Arguments** ```rust theme={null} pub struct CreateCustomizableParams { pub sqrt_price_x64: u128, pub collect_fee_on: CollectFeeOn, // FromInput | Token0Only | Token1Only pub enable_dynamic_fee: bool, } ``` **Comptes (résumé)** — identiques à `CreatePool`, avec en plus, lorsque `enable_dynamic_fee = true` : | # | Nom | W | S | Notes | | - | -------------------- | - | - | ----------------------------------------------------------------- | | N | `dynamic_fee_config` | | | La config partagée dont prendre un instantané. Doit déjà exister. | **Préconditions** — identiques à `CreatePool`. Si `enable_dynamic_fee = false`, `dynamic_fee_config` est ignoré. **Postconditions** * `pool_state.fee_on` est défini sur la variante `CollectFeeOn` choisie. * Si les frais dynamiques sont activés : `pool_state.dynamic_fee_info` est initialisé à partir du `DynamicFeeConfig` fourni (cinq paramètres de calibration copiés ; champs d'état mis à zéro). * Sinon : `pool_state.dynamic_fee_info` est mis à zéro (= frais dynamiques inactifs de façon permanente pour ce pool). `fee_on` et le bit d'activation des frais dynamiques sont définis **uniquement** à la création du pool. Il n'existe pas de mise à niveau en place — les pools créés via `CreatePool` hérité ne peuvent pas bénéficier rétroactivement des frais dynamiques ni des frais unilatéraux. Les nouveaux déploiements doivent utiliser cette instruction par défaut. ## `OpenPositionV2` / `OpenPositionWithToken22Nft` Créer une nouvelle position dans 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 souhaité (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 // true = ajuster sur amount0 ; false = ajuster sur amount1 ``` **Comptes (résumé)** | # | Nom | W | S | | | -- | ----------------------------------------- | - | ----------- | ----------------------------------------- | | 1 | `payer` | W | S | | | 2 | `position_nft_owner` | | | | | 3 | `position_nft_mint` | W | S (keypair) | | | 4 | `position_nft_account` | W | | ATA du propriétaire pour le NFT. | | 5 | `metadata_account` | W | | Metaplex (optionnel, si `with_metadata`). | | 6 | `pool_state` | W | | | | 7 | `protocol_position` | | | | | 8 | `tick_array_lower` | W | | Créé si non initialisé. | | 9 | `tick_array_upper` | W | | Idem. | | 10 | `personal_position` | W | | Créé ici. | | 11 | `token_account_0`, `token_account_1` | W | | ATAs source de l'utilisateur. | | 12 | `token_vault_0`, `token_vault_1` | W | | | | 13 | `rent`, `system_program`, `token_program` | | | | | 14 | `associated_token_program` | | | | | 15 | `metadata_program` | | | Optionnel. | | 16 | `token_program_2022` | | | V2. | | 17 | `vault_0_mint`, `vault_1_mint` | | | V2. | | 18 | `tick_array_bitmap_extension` | W | | V2 (si touché). | **Calcul** — voir [`products/clmm/math`](/fr/products/clmm/math). En fonction de `base_flag`, le programme résout soit `liquidity`, soit `(amount_0_max, amount_1_max)` pour obtenir le `L` réel et les montants de tokens effectivement consommés. **Préconditions** * `tick_lower < tick_upper`, tous deux multiples de `pool.tick_spacing`, dans `[MIN_TICK, MAX_TICK]`. * Les tableaux de ticks requis sont passés et initialisés (ou créés ici via un CPI `InitTickArray` dans la transaction). * L'utilisateur dispose d'au moins `amount_0_max` et `amount_1_max` dans les ATAs sources. **Postconditions** * `personal_position` existe, `liquidity` est défini, `fee_growth_inside_last` est capturé en instantané. * Les entrées du tableau de ticks à `tick_lower` et `tick_upper` sont mises à jour (`liquidity_gross += L`, `liquidity_net ± L`, instantanés de croissance des frais maintenus). * `pool_state.liquidity += L` si la position est dans la plage (`tick_lower ≤ tick_current < tick_upper`). **Erreurs courantes** — `InvalidTickIndex`, `NotApproved`, `ZeroAmountSpecified`, `TransactionTooLarge` (si trop de tableaux de ticks). ## `IncreaseLiquidityV2` Ajouter de la liquidité à une position déjà ouverte. **Arguments** ``` liquidity: u128 amount_0_max: u64 amount_1_max: u64 base_flag: Option ``` **Comptes** — comme `OpenPosition` sans le mint NFT (la position existe déjà ; le NFT est passé en tant qu'ATA du propriétaire détenant 1 token). **Effet** * Transfère `amount_0_actual` / `amount_1_actual` de l'utilisateur vers les coffres. * Incrémente `personal_position.liquidity` et `pool_state.liquidity` (si dans la plage), ainsi que `liquidity_gross` / `liquidity_net` des ticks limites en conséquence. * **Collecte les frais et récompenses dus depuis le dernier accès** et les crédite sur `tokens_fees_owed_{0,1}` / `reward_amount_owed`. Ces montants ne sont versés que lors d'un `DecreaseLiquidity` ou d'un `CollectReward`, pas lors d'une augmentation. ## `DecreaseLiquidityV2` Retirer de la liquidité d'une position. **Arguments** ``` liquidity: u128 amount_0_min: u64 amount_1_min: u64 ``` **Comptes** — même structure qu'`IncreaseLiquidity`. **Effet** * Calcule `(amount_0, amount_1)` pour le `L` retiré en fonction du `sqrt_price_x64` actuel. * Règle les frais et récompenses accumulés depuis le dernier accès, de la même façon qu'`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 à `ClosePosition`. **Slippage** — `amount_0_min` et `amount_1_min` représentent les minimums acceptés par l'utilisateur, nets des frais de transfert Token-2022 côté sortie. ## `ClosePosition` Brûler le NFT de position et fermer le `PersonalPositionState`. **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 ramener la position à zéro au préalable.) **Effet** * Brûle le NFT. * Ferme le compte de mint du NFT et le compte `personal_position`, en restituant le loyer au `payer`. ## `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 // sortie minimum ou entrée maximum sqrt_price_limit_x64: u128 // borne dure ; 0 ⇒ sans limite is_base_input: bool ``` **Comptes (résumé)** | # | 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 s'étend dans l'extension. | | 14+ | `tick_array` (restants) | W | | Suffisamment de tableaux pour couvrir la plage attendue du parcours. | Les appelants passent une liste ordonnée de tableaux de ticks couvrant le parcours de swap attendu ; le programme en utilise autant que nécessaire. Le SDK calcule cette liste via `PoolUtils.computeAmountOutFormat` ou l'endpoint de devis de l'API. **Préconditions** * `pool_state.status` autorise le swap. * `now >= open_time`. * `sqrt_price_limit_x64` se trouve du bon côté de `sqrt_price_x64` pour la direction choisie. **Erreurs courantes** — `ExceededSlippage`, `SqrtPriceLimitOverflow`, `TickArrayNotFound`, `LiquidityInsufficient`. **Ce que `SwapV2` fait en interne et que les appelants doivent savoir** (version post-2025) : 1. **Surcharge de frais dynamiques** — si `pool.dynamic_fee_info` est non nul, le programme met à jour l'accumulateur de volatilité en utilisant la distance en ticks parcourue depuis le dernier swap (selon les règles de filtre/décroissance décrites dans [`products/clmm/fees`](/fr/products/clmm/fees)) et ajoute un `dynamic_fee_component` au-dessus de `AmmConfig.trade_fee_rate`. Les frais totaux sont plafonnés à 10 % (`MAX_FEE_RATE_NUMERATOR / 1_000_000`). 2. **Correspondance des ordres limités** — lorsque le parcours de prix franchit un tick contenant des ordres limités ouverts, le programme remplit d'abord la liquidité des ordres limités disponibles à ce tick (FIFO par `order_phase`), puis continue le long de la courbe de liquidité LP. Les montants exécutés 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`. 3. **Routage des frais unilatéral** — lorsque `pool.fee_on = Token0Only` ou `Token1Only`, l'étape de swap calcule toujours le même échange entrée-sortie ; les frais sont ensuite acheminés vers le côté configuré. Pour les directions où le côté de frais configuré est la sortie, les frais sont déduits de la sortie du swap (l'utilisateur reçoit `out − fee`) ; pour les directions où il s'agit de 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, le même routage de frais unilatéral et la même correspondance d'ordres limités que `SwapV2` ; la seule fonctionnalité qui lui manque est la prise en charge de Token-2022 — les deux coffres doivent être des SPL Token classiques. Les pools comportant un mint Token-2022 doivent être swappés via `SwapV2`. L'agrégateur et le SDK préfèrent déjà V2 pour chaque segment CLMM, de sorte que les appelants n'ont pas à distinguer selon le type de mint. ## `OpenLimitOrder` Placer un ordre de vente à un tick spécifique. L'ordre s'inscrit dans une cohorte FIFO par tick et s'exécute au fur et à mesure que le prix la franchit. **Arguments** ``` nonce_index: u8 // index du compte nonce choisi par l'utilisateur (0..255 par portefeuille) zero_for_one: bool // true : vendre token0 contre token1 ; false : vendre token1 contre token0 tick_index: i32 // doit être un multiple de pool.tick_spacing amount: u64 // montant du token d'entrée ``` **Comptes (résumé)** | # | 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 tableau de ticks contenant `tick_index`. | | 4 | `limit_order_nonce` | W | | PDA. `init_if_needed` — créé lors du 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. | | 7 | `input_vault` | W | | Coffre d'entrée du pool. | | 8 | `input_vault_mint` | | | Gestion des frais Token-2022. | | 9 | `input_token_program` | | | SPL ou Token-2022. | | 10 | `system_program`, `rent` | | | | **Préconditions** * `tick_index % pool.tick_spacing == 0` et dans `[MIN_TICK, MAX_TICK]`. * `tick_index` se trouve **du bon côté de `pool.tick_current`** pour la direction choisie (vendre token0 → le tick doit être au-dessus du tick actuel, et inversement). Vendre à un tick déjà franchi entraînerait une exécution immédiate et est rejeté. * `pool_state.status` autorise l'opération d'ordre limité (bit 5). **Postconditions** * `limit_order` existe, avec un instantané de `tick.order_phase` et `tick.unfilled_ratio_x64` à l'ouverture. * `tick.orders_amount += amount` (dans la cohorte actuelle). * `limit_order_nonce.order_nonce += 1`. * Événement `OpenLimitOrderEvent` émis. **Erreurs courantes** — `InvalidLimitOrderAmount` (nul ou inférieur au minimum du pool), `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` Augmenter un ordre ouvert existant. Uniquement appelable par le `owner` de l'ordre. **Arguments** ``` amount: u64 // montant supplémentaire du token d'entrée ``` **Comptes** — comme `OpenLimitOrder` sans le compte nonce ; le PDA `limit_order` est passé directement. **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é à s'exécuter, l'ordre est partiellement réglé — l'appelant devrait d'abord appeler `DecreaseLimitOrder` ou `SettleLimitOrder` pour avancer. **Effet** * Transfère `amount` de l'ATA du propriétaire vers `input_vault`. * `limit_order.total_amount += amount` ; `tick.orders_amount += amount`. ## `DecreaseLimitOrder` Réduire ou annuler entièrement un ordre ouvert. Rembourse le reliquat non exécuté au propriétaire, ainsi que toute sortie déjà réglée lors de remplissages partiels passés. **Arguments** ``` amount: u64 // montant du token d'entrée à retirer (max = reliquat non exécuté) amount_min: u64 // plancher de slippage sur le retrait côté entrée ``` **Comptes** — côtés token d'entrée et de sortie : | # | 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 exécuté de l'ordre à partir du `unfilled_ratio_x64` de la cohorte depuis l'ouverture. * Envoie la sortie exécutée vers `output_token_account`. * Renvoie `amount` d'entrée non exécutée vers `input_token_account`. * Met à jour `limit_order` en conséquence. Si le nouveau reliquat non exécuté est nul, le programme ferme le compte et rembourse le loyer au `owner`. ## `SettleLimitOrder` Transférer les tokens de sortie exécutés vers le propriétaire sans modifier le reliquat non exécuté de l'ordre. Utile lorsque des keepers `auto_withdraw` souhaitent verser progressivement des 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 keeper automatisée). Le keeper ne dispose d'aucune autre autorité — il ne peut pas déplacer les fonds des utilisateurs en dehors du transfert de la sortie exécutée vers l'ATA de sortie du `owner` de l'ordre. **Comptes** | # | Nom | W | S | | | - | ---------------------- | - | - | ------------------------------------- | | 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 cumulée due en utilisant `(limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64)`. * Transfère le delta vers `output_token_account`. * Met à jour `limit_order.settled_output`. * Ne ferme **pas** l'ordre ; il reste ouvert sur toute entrée restante. ## `CloseLimitOrder` Fermer un compte d'ordre entièrement consommé. Le loyer est toujours restitué à `limit_order.owner`, quel que soit le signataire. **Appelant** — soit `owner`, soit `limit_order_admin`. **Préconditions** * L'ordre a un reliquat non exécuté nul (soit `amount == total_amount` a été exécuté et réglé, soit le propriétaire avait précédemment réduit l'ordre à zéro sans le fermer). **Effet** * Ferme `limit_order` ; le loyer est envoyé à `limit_order.owner`. ## `CreateDynamicFeeConfig` (admin) Créer un jeu de paramètres réutilisable sous un index u16. **Arguments** ``` index: u16 filter_period: u16 // secondes ; ex. 30 decay_period: u16 // secondes ; ex. 600. Doit être > filter_period reduction_factor: u16 // 1..10_000 ; ex. 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é publique 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 si un champ à valeur nulle est hors limites. ## `UpdateDynamicFeeConfig` (admin) Modifier un `DynamicFeeConfig` existant. Les pools ayant déjà pris un instantané de la config au moment de leur création ne sont **pas** mis à jour rétroactivement ; seuls les pools nouvellement créés référençant cette config adopteront les nouvelles valeurs. **Arguments** — les cinq mêmes champs de calibration que `CreateDynamicFeeConfig` (`filter_period`, `decay_period`, `reduction_factor`, `dynamic_fee_control`, `max_volatility_accumulator`) ; `index` est fixé à la création et n'est pas repassé ici. ## `CollectProtocolFee` / `CollectFundFee` Structure identique à celle du CPMM pour `CollectProtocolFee` / `CollectFundFee`. Le signataire doit correspondre à `AmmConfig.owner` / `AmmConfig.fund_owner`. Collecte les frais de protocole/fonds accumulés depuis les coffres du pool vers un destinataire, puis remet à zéro les champs `PoolState.protocol_fees_*` / `fund_fees_*` correspondants. ## `InitializeReward` Ajouter un nouveau flux de récompenses à un pool. Au maximum 3 flux peuvent être actifs simultanément. **Arguments** ``` open_time: u64 end_time: u64 emissions_per_second_x64: u128 // Q64.64 ``` **Comptes** | # | Nom | W | S | | | - | ------------------------ | - | - | ------------------------------------------------------------------ | | 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 tokens de récompense dans le coffre dans le cadre de cette instruction. * Mint de récompense autorisé par `operation_state`. ## `SetRewardParams` Prolonger, alimenter ou modifier le taux d'émission d'un flux de récompenses existant. Généralement appelé par le créateur du pool ou le multisig Raydium. Les contraintes sont définies on-chain : il est généralement possible d'étendre `end_time` ou d'augmenter les émissions, mais pas de les réduire rétroactivement. Vérifiez la liste des propriétaires de `operation_state`. ## `UpdateRewardInfos` Comptabilité pure — règle `reward_growth_global_x64` jusqu'à l'heure actuelle en multipliant `emissions_per_second × Δt / liquidity`. Appelée en interne par chaque instruction touchant à la liquidité. Exposée en tant qu'instruction autonome car des acteurs externes (interfaces, cranks) souhaitent parfois la déclencher directement. ## `CollectReward` Le propriétaire d'une position réclame les tokens de récompense dus. **Comptes** | # | Nom | W | S | | | - | ------------------------- | - | - | ------------------------------------------------ | | 1 | `nft_owner` | | S | | | 2 | `nft_account` | | | ATA du propriétaire détenant le NFT de position. | | 3 | `personal_position` | W | | | | 4 | `pool_state` | W | | | | 5 | `protocol_position` | | | | | 6 | `reward_token_vault` | W | | | | 7 | `recipient_token_account` | W | | | | 8 | `token_program` | | | | | 9 | `token_program_2022` | | | | **Effet** * Règle la croissance des récompenses (même mécanisme que pour les frais). * Transfère le montant dû vers l'ATA destinataire, remet à zéro `reward_amount_owed[i]`. ## Matrice des changements d'état | Instruction | `pool.liquidity` | `pool.fee_growth_global` | `pool.reward_growth_global` | `personal_position.liquidity` | Tableau de ticks | | ------------------------ | --------------------- | ------------------------ | --------------------------- | ----------------------------- | ----------------------------------------------------------------------------- | | `CreatePool` | 0 | 0 | — | — | — | | `OpenPosition` | + si dans la plage | — | — | nouveau | ajouter liquidity\_gross/net | | `IncreaseLiquidity` | + si dans la plage | régler le dû | régler le dû | + | ajuster | | `DecreaseLiquidity` | − si dans la plage | régler le dû | régler le dû | − | ajuster | | `ClosePosition` | — | — | — | supprimé | — | | `SwapV2` | ± aux franchissements | + | — | — | franchir et inverser l'extérieur ; correspondre aux cohortes d'ordres limités | | `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` | — | — | + | — | — | | `CollectReward` | — | — | régler le dû | — | — | ## Pour aller plus loin * [`products/clmm/code-demos`](/fr/products/clmm/code-demos) — exemples TypeScript exécutables. * [`products/clmm/fees`](/fr/products/clmm/fees) — détails sur l'accumulation des frais et des récompenses. * [`reference/error-codes`](/fr/reference/error-codes) — tableau complet des erreurs Anchor CLMM. Sources : * [`raydium-io/raydium-clmm` — `programs/amm/src/instructions`](https://github.com/raydium-io/raydium-clmm) * Raydium SDK v2 — `@raydium-io/raydium-sdk-v2`