Changelog

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.

​

Non publié — CLMM : ordres limites, frais unilatéraux, frais dynamiques

​

Résumé pour les intégrateurs

• Les ordres limites sont désormais des primitives CLMM de première classe. Les LPs peuvent ouvrir un ordre sur un tick unique dans un pool qui les prend en charge ; l’ordre est exécuté en FIFO lorsqu’un swap franchit le tick, et un keeper hors chaîne (limit_order_admin) peut régler la sortie remplie sans que le propriétaire soit en ligne. Sept nouvelles méthodes SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) et trois nouveaux endpoints de l’API Temp sous /limit-order/ (ordres actifs, historique par utilisateur, journal d’événements par PDA) couvrent l’intégralité du flux.
• Les frais unilatéraux (CollectFeeOn) permettent à un pool de collecter les frais de swap du côté de l’entrée (mode historique, 0), ou toujours depuis token_0 (mode 1), ou toujours depuis token_1 (mode 2). Utile lorsque l’un des côtés de la paire est le token de référence comptable.
• Les frais dynamiques permettent à un pool d’opter pour une surtaxe de suivi de la volatilité qui augmente avec les mouvements rapides de tick et diminue avec le temps, calibrée par un DynamicFeeConfig par niveau et un DynamicFeeInfo par pool. Le nouvel endpoint /main/clmm-dynamic-config expose la liste des niveaux.
• Une nouvelle instruction, CreateCustomizablePool, expose les trois réglages à la création du pool. L’instruction classique CreatePool continue de fonctionner pour les pools sans ordre limite et avec des frais par défaut.
• Changement cassant pour les indexeurs : les compteurs de volume par direction (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) et les compteurs de frais cumulés (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) de PoolState ont été déplacés dans le padding pour laisser de la place à fee_on et dynamic_fee_info. Les indexeurs qui lisent ces champs directement doivent migrer vers l’anneau Observation on-chain ou vers l’API.

​

Pourquoi cela est important (pour les traders, les LPs et les intégrateurs)

• Les traders obtiennent des cotations plus précises sur les paires longue traîne et événementielles : les frais dynamiques permettent au pool d’absorber les surtaxes de volatilité de la part du preneur sans que les LPs aient à élargir activement leurs plages, et les échelles d’ordres limites approfondissent la liquidité on-chain à des prix précis sans immobiliser de capital sur l’ensemble d’une plage.
• Les LPs disposent d’une troisième stratégie aux côtés des plages concentrées et des positions pleine plage : placer des ordres à prix exact, être exécutés quand le prix passe, et régler en token de cotation. Aucun rééquilibrage actif n’est requis pour la portion exécutée.
• Les intégrateurs peuvent modéliser les pools à frais dynamiques de manière déterministe — l’algorithme et les paramètres sont entièrement on-chain, les niveaux de calibration sont interrogeables, et le chemin de swap reste inchangé dans sa forme (seul le montant des frais par étape varie).

​

Ce qui a changé dans le programme

​

Nouveaux comptes

• DynamicFeeConfig — enregistrement de calibration par niveau (période de filtre, période de décroissance, facteur de réduction, contrôle des frais dynamiques, accumulateur de volatilité maximal). Créé par CreateDynamicFeeConfig (admin), référencé par CreateCustomizablePool lorsque les frais dynamiques sont activés.
• LimitOrderState — compte par ordre (seeds PDA : [owner, limit_order_nonce, order_nonce]) contenant le pool, le tick, le côté, le montant d’entrée, le ratio non rempli, la phase de cohorte FIFO et des instantanés de comptabilité. Le cycle de vie est implicite (filled_amount vs total_amount, plus l’existence du compte) : Open → Filled → Settled → Closed.
• LimitOrderNonce — compteur à incrémentation monotone par (owner, nonce_index) qui alimente les seeds PDA des ordres limites. Le nonce_index: u8 permet au même propriétaire de répartir ses ordres dans jusqu’à 256 flux de nonce indépendants.

​

Restructuration de PoolState

​

Ajouts à TickState (sans changement cassant)

• order_phase: u64 — compteur qui distingue les cohortes d’ordres limites à ce tick.
• orders_amount: u64 — entrée totale engagée par tous les ordres ouverts à ce tick (dont certains peuvent être partiellement non remplis).
• part_filled_orders_remaining: u64 — entrée encore non remplie dans la cohorte en cours de consommation par les swaps.
• unfilled_ratio_x64: u128 — ratio Q64.64 utilisé pour calculer la part d’exécution de chaque ordre.

​

Nouvelles instructions

• CreateDynamicFeeConfig (admin) — crée un niveau DynamicFeeConfig calibré. Autorité : même multisig que pour CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — met à jour les paramètres d’un niveau existant.
• CreateCustomizablePool — point d’entrée de création de pool exposant collect_fee_on, enable_dynamic_fee et dynamic_fee_config. Coexiste avec CreatePool ; nous recommandons CreateCustomizablePool pour tout nouveau pool nécessitant les nouveaux réglages.
• OpenLimitOrder — ouvre un ordre limite sur un tick unique. Incrémente LimitOrderNonce, alloue LimitOrderState et insère l’ordre dans la cohorte FIFO du tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajuste la portion non remplie d’un ordre. Échoue avec InvalidOrderPhase sur un ordre entièrement rempli.
• SettleLimitOrder — transfère la sortie remplie vers l’ATA du propriétaire. L’appelant peut être le propriétaire ou le keeper limit_order_admin du pool.
• CloseLimitOrder — ferme un ordre entièrement réglé pour récupérer le loyer.

​

Changements de comportement de SwapV2

1. Frais dynamiques (lorsqu’ils sont activés) : le DynamicFeeInfo du pool est mis à jour à chaque étape (décroissance → accumulation → plafonnement), et la surtaxe résultante s’ajoute aux frais de base pour cette étape.
2. Correspondance d’ordres limites (lorsque l’étape franchit un tick initialisé avec des ordres ouverts) : une partie de l’entrée du swap est consommée en FIFO pour remplir la cohorte à ce tick, avec mise à jour atomique de unfilled_ratio_x64.
3. Routage des frais unilatéraux (lorsque fee_on != 0) : les frais sont prélevés sur token_0 ou token_1 quelle que soit la direction du swap, au lieu d’être toujours prélevés sur le côté d’entrée.

​

Nouveaux codes d’erreur

• 6040 OrderAlreadyFilled
• 6041 InvalidOrderPhase
• 6042 InvalidLimitOrderAmount
• 6043 OrderPhaseSaturated
• 6044 InvalidDynamicFeeConfigParams
• 6045 InvalidFeeOn
• 6046 ZeroSqrtPrice
• 6047 ZeroLiquidity
• 6048 MissingBaseFlag
• 6049 MissingMintAccount
• 6050 MissingTokenProgram2022

​

Ce qui a changé dans le SDK (@raydium-io/raydium-sdk-v2)

• Nouvelles méthodes sur raydium.clmm : createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Nouveaux helpers REST sur raydium.api : getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Nouveaux types : enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Réorganisation interne : utils/ a été déplacé vers libraries/. Le barrel du package est inchangé ; seules les importations profondes via @raydium-io/raydium-sdk-v2/utils/... doivent être mises à jour vers …/libraries/....

​

Ce qui a changé dans les APIs

• api-v3 — deux nouveaux endpoints sous /main/ :
  • GET /main/clmm-dynamic-config — liste des niveaux DynamicFeeConfig.
  • GET /main/clmm-limit-order-config — configuration des ordres limites par pool.
• temp-api-v1 — trois nouveaux endpoints sous /limit-order/ :
  • GET /limit-order/order/list?wallet=… — ordres actuellement placés par un wallet (ouverts et partiellement remplis, servis depuis le cache Redis de l’indexeur ; le même payload couvre les deux phases via totalAmount / filledAmount / pendingSettle).
  • GET /limit-order/history/order/list-by-user?wallet=… — historique des ordres limites d’un wallet. Filtres optionnels : poolId, mint1, mint2, hideCancel. Pagination par curseur via nextPageId / size (max 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — journal d’événements par PDA (open / increase / decrease / settle / close) pour un ou plusieurs PDAs d’ordres limites séparés par des virgules. Pagination par curseur via nextPageId / size (max 100).

​

Surface d’autorité

​

Pages mises à jour

• products/clmm/overview — nouvelle section « Nouveautés » et pointeurs d’étapes suivantes mis à jour.
• products/clmm/accounts — trois nouveaux comptes, restructuration de PoolState avec avertissement de migration, ajouts à TickState, nouveaux helpers PDA.
• products/clmm/instructions — sept nouvelles instructions, addendum sur le comportement de SwapV2, matrice de changement d’état mise à jour.
• products/clmm/fees — section sur les frais unilatéraux, section sur les frais dynamiques avec tableau de paramètres.
• products/clmm/math — pseudo-code de correspondance d’ordres limites, dérivation des frais dynamiques.
• products/clmm/code-demos — démo createCustomizablePool, guide complet des ordres limites, nouveaux pièges à éviter.
• algorithms/clmm-math — référence croisée vers la correspondance d’ordres limites et les frais dynamiques dans la boucle de swap multi-tick.
• sdk-api/typescript-sdk — section des ajouts au module CLMM, note de migration utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — deux nouveaux endpoints avec schémas de réponse.
• api-reference/openapi/temp-api-v1.yaml — trois nouveaux endpoints d’ordres limites (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) avec leurs schémas de requête et de réponse.
• api-reference/api-v3/overview — note sur les nouveaux endpoints de configuration CLMM.
• api-reference/temp-api-v1/overview — note sur les nouveaux endpoints d’ordres actifs, d’historique par utilisateur et d’événements par PDA.
• reference/error-codes — onze nouveaux codes d’erreur CLMM (6040–6050) et cinq codes historiques supprimés ; les codes numériques après les points de suppression ont décalé.
• security/admin-and-multisig — nouvelle ligne admin DynamicFeeConfig et ligne keeper limit_order_admin, avec explication des autorités limitées.

• Le code source de raydium-clmm.
• Le code source de @raydium-io/raydium-sdk-v2.
• Les codes sources de api-v3 et temp-api-v1.

​

2026-04-26 — Publication initiale

• Les déploiements de programmes actifs sur Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• La documentation publique de Raydium et les références on-chain jusqu’en avril 2026.

​

Conventions de documentation

• Versionnage : cette documentation utilise un versionnage basé sur le calendrier (AAAA-MM-JJ). Chaque mise à jour crée une nouvelle entrée en haut du fichier.
• Date de vérification : chaque entrée enregistre la dernière date à laquelle le contenu a été confronté à l’état on-chain / API et au code source du programme. En l’absence d’indication, considérez que c’est la date principale de l’entrée.
• Changements cassants : signalés par un avertissement encadré sur les pages concernées et étiquetés dans l’entrée correspondante.
• Couverture : ce changelog couvre l’ensemble de la documentation. La chronologie historique du protocole se trouve dans introduction/history-and-milestones et constitue la source de vérité sur « quand X s’est produit sur Raydium ».

​

Corrections

​

Références utiles

• introduction/history-and-milestones — la chronologie du protocole.
• security/audits — historique des audits.
• ray/protocol-fees — répartition des frais de protocole.
• reference/program-addresses — source de vérité des identifiants de programme.