Instructions CLMM

​

Inventaire des instructions

​

CreatePool

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

• 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.

• 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

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

• 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).

​

CreatePermissionedPool

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

• 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.

• 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).

​

OpenPositionV2 / OpenPositionWithToken22Nft

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // L 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

• tick_lower < tick_upper, tous deux multiples de pool.tick_spacing, dans [MIN_TICK, MAX_TICK].
• Les tick arrays requis passés et initialisés (ou créés ici via CPI InitTickArray dans la transaction).
• L’utilisateur a au moins amount_0_max et amount_1_max dans les ATAs source.

• 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.

​

IncreaseLiquidityV2

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

• 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 à tokens_fees_owed_{0,1} / reward_amount_owed. Ceux-ci ne sont payés que sur DecreaseLiquidity ou CollectReward, pas sur l’augmentation.

​

DecreaseLiquidityV2

liquidity: u128
amount_0_min: u64
amount_1_min: u64

• 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.

​

ClosePosition

• 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.

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

• 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.

​

SwapV2

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

• 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.

1. 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).
2. 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.
3. 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.

​

OpenLimitOrder

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

• 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é.

• 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.

​

IncreaseLimitOrder

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

• 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.

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

​

DecreaseLimitOrder

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

• 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

• 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

• 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).

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

​

CreateDynamicFeeConfig (admin)

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

​

UpdateDynamicFeeConfig (admin)

​

CollectProtocolFee / CollectFundFee

​

InitializeReward

open_time:     u64
end_time:      u64
emissions_per_second_x64: u128   // Q64.64

• 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

​

UpdateRewardInfos

​

CollectReward

• Règle la croissance des récompenses (même motif que les frais).
• Transfère le montant dû à l’ATA du destinataire, met à zéro reward_amount_owed[i].

​

Matrice de changement d’état

​

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.

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