Journal des modifications

Registre datée des mises à jour de cet ensemble de documentation. Les entrées consignent les chapitres modifiés, la raison, et quand le contenu a été vérifié par rapport à l’état on-chain et au code source du programme.

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

Voir la version anglaise →

Ceci est le journal des modifications de la documentation — le registre des mises à jour de ces pages depuis le lancement du projet. Pour la chronologie historique du protocole lui-même, consultez introduction/history-and-milestones. Chaque entrée ici contient une date, une liste des chapitres affectés, le déclencheur, et une date vérifiée indiquant quand l’état on-chain et le code source ont été vérifiés pour la dernière fois par rapport au contenu écrit.

​

2026-05-18 — CLMM : ordres à cours limite, frais unidirectionnels, frais dynamiques

La prochaine version de CLMM ajoute trois capacités au niveau du pool. Elles sont optionnelles au moment de la création du pool et rétrocompatibles avec les pools et positions existants.

​

Résumé pour les intégrateurs

• Les ordres à cours limite sont désormais des primitives CLMM de première classe. Les LP peuvent ouvrir un ordre single-tick sur un pool qui les supporte ; l’ordre est rempli en FIFO quand un swap franchit le tick, et un gardien hors chaîne (limit_order_admin) peut régler le résultat rempli sans que le propriétaire soit connecté. Sept nouvelles méthodes SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) et trois nouveaux points de terminaison Temp API sous /limit-order/ (ordres actifs, historique par utilisateur, journal des événements par PDA) couvrent le flux complet.
• Les frais unidirectionnels (CollectFeeOn) permettent à un pool de collecter les frais de swap du côté input (hérité, mode 0), ou toujours depuis token_0 (mode 1), ou toujours depuis token_1 (mode 2). Utile quand un côté de la paire est le token comptable canonical.
• Les frais dynamiques permettent à un pool d’opter pour une majoration de suivi de la volatilité qui augmente avec le mouvement rapide du tick et décroît au fil du temps, calibrée par une DynamicFeeConfig par tier et une DynamicFeeInfo par pool. Le nouveau point de terminaison /main/clmm-dynamic-config expose la liste des tiers.
• Une nouvelle instruction, CreateCustomizablePool, expose les trois paramètres au moment de la création du pool. L’instruction CreatePool classique continue de fonctionner pour les pools sans frais variables, sans ordres à cours limite.
• Changement important pour l’indexeur : 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}) sur PoolState ont été retirés dans le remplissage pour faire de la place à fee_on et dynamic_fee_info. Les indexeurs qui lisent ces champs directement doivent migrer vers le ring Observation on-chain ou l’API.

​

Pourquoi c’est important (pour les traders, LP et intégrateurs)

• Les traders obtiennent des devis plus serrés sur les paires long-tail et axées sur les événements : les frais dynamiques permettent au pool d’absorber les majorations de volatilité du preneur sans que les LP aient à élargir activement les plages, et les échelles d’ordres à cours limite approfondissent la liquidité on-chain à des prix spécifiques sans s’engager sur les capitaux sur toute la plage.
• Les LP obtiennent une troisième stratégie aux côtés des plages concentrées et des positions full-range : garez des ordres à prix exact, faites-vous remplir quand le prix les visite, réglez dans le token de cotation. Aucun rééquilibrage actif requis pour la portion remplie.
• 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 tiers d’étalonnage sont interrogeables, et le chemin de swap reste inchangé en forme (seuls les frais par étape varient).

​

Ce qui a changé dans le programme

​

Nouveaux comptes

• DynamicFeeConfig — enregistrement d’étalonnage par tier (période de filtre, période de décroissance, facteur de réduction, contrôle des frais dynamiques, accumulateur de volatilité maximum). Créé par CreateDynamicFeeConfig (admin), référencé par CreateCustomizablePool quand les frais dynamiques sont activés.
• LimitOrderState — compte par ordre (graines PDA : [owner, limit_order_nonce, order_nonce]) contenant le pool, le tick, le côté, le montant input, le ratio non rempli, la phase de cohort FIFO, et les snapshots de tenue de livre. Le cycle de vie est implicite (filled_amount vs total_amount, plus l’existence du compte) : Open → Filled → Settled → Closed.
• LimitOrderNonce — compteur monotone croissant par (propriétaire, nonce_index) qui obtient les graines du PDA d’ordre à cours limite. Le nonce_index: u8 permet au même propriétaire de partitionner les ordres dans jusqu’à 256 flux de nonce indépendants.

Voir Accounts → DynamicFeeConfig and DynamicFeeInfo et Accounts → LimitOrderState.

​

Remodèle de PoolState

Groupe de champs	Ancienne disposition	Nouvelle disposition
Compteurs de volume par direction	swap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1	Repliés dans padding5: [u128; 4]
Compteurs de frais cumulés	total_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1	Repliés dans padding6: [u64; 4]
Frais unidirectionnels	—	fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Frais dynamiques	—	dynamic_fee_info: DynamicFeeInfo (embarqué)

La taille totale du compte est inchangée. Indexeurs : basculez le suivi du volume hors de PoolState et vers le ring Observation ou l’API. Les compteurs retirés ne sont pas mis à zéro sur les pools existants (ils contiennent ce qu’ils avaient l’habitude de porter), donc les relire après la mise à jour renverra des données obsolètes.

​

Ajouts à TickState (pas de changement important)

Quatre nouveaux champs sont ajoutés à la fin de TickState, remplaçant une partie de son remplissage terminal :

• order_phase: u64 — compteur qui désambiguïse les cohorts d’ordres à cours limite à ce tick.
• orders_amount: u64 — montant total input engagé par tous les ordres ouverts à ce tick (non tous entièrement non remplis).
• part_filled_orders_remaining: u64 — input toujours non rempli dans le cohort actuellement consommé par les swaps.
• unfilled_ratio_x64: u128 — ratio Q64.64 utilisé pour calculer la part de remplissage de chaque ordre.

La disposition du tick-array, le dimensionnement et les graines PDA restent inchangés.

​

Nouvelles instructions

• CreateDynamicFeeConfig (admin) — créer un tier DynamicFeeConfig étalonné. Autorité : même multisig du trésor que CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — mettre à jour les paramètres d’un tier existant.
• CreateCustomizablePool — point d’entrée de création de pool qui expose collect_fee_on, enable_dynamic_fee et dynamic_fee_config. Coexiste avec CreatePool ; nous recommandons CreateCustomizablePool pour tout nouveau pool qui a besoin des nouveaux paramètres.
• OpenLimitOrder — ouvrir un ordre à cours limite single-tick. Incremente LimitOrderNonce, alloue LimitOrderState, place l’ordre dans le cohort FIFO au tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajuster la portion non remplie d’un ordre. Revient en arrière sur un ordre entièrement rempli avec InvalidOrderPhase.
• SettleLimitOrder — transférer le résultat rempli vers l’ATA du propriétaire. L’appelant peut être le propriétaire ou le gardien limit_order_admin du pool.
• CloseLimitOrder — fermer un ordre entièrement réglé pour récupérer le loyer.

​

Changements de comportement de SwapV2

Le chemin de swap lui-même reste inchangé en forme, mais trois choses se produisent maintenant le long du chemin :

1. Frais dynamiques (quand activés) : la DynamicFeeInfo du pool est mise à jour à chaque étape (décroissance → accumulation → plafonnement), et la majoration résultante est ajoutée en plus des frais de base pour cette étape.
2. Appairage des ordres à cours limite (quand l’étape franchit un tick initialisé qui a des ordres ouverts) : une partie de l’input de swap est consommée en FIFO pour remplir le cohort à ce tick, avec unfilled_ratio_x64 mis à jour de manière atomique.
3. Routage des frais unidirectionnels (quand fee_on != 0) : les frais sont prélevés sur token_0 ou token_1 indépendamment de la direction du swap, au lieu d’être toujours prélevés du côté input.

Chacune de ces opérations est un no-op quand le pool a été créé avec les paramètres par défaut hérités. Voir Instructions → SwapV2 pour la matrice de changement d’état mise à jour.

​

Nouveaux codes d’erreur

L’énumération ErrorCode a été renumérotée dans cette version : cinq variantes héritées (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) ont été supprimées, et onze nouvelles variantes ont été ajoutées. Parce qu’Anchor numérote les erreurs par ordre d’énumération à partir de 6000, tout code d’erreur à ou après les positions supprimées a décalé — les clients qui ont codifié en dur les codes numériques doivent remapper.

Les nouveaux codes sont :

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

Les chaînes complètes et le tableau de décalage post-shift pour toutes les erreurs CLMM sont dans Error codes.

​

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 assistants REST sur raydium.api : getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Nouveaux types : énumération CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Réorganisation interne : utils/ déplacé vers libraries/. Le barrel du package est inchangé ; seules les imports profonds sous @raydium-io/raydium-sdk-v2/utils/... nécessitent une mise à jour vers …/libraries/....

Les walkthroughs TypeScript de bout en bout vivent dans products/clmm/code-demos.

​

Ce qui a changé dans les API

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

Les cinq sont documentés dans l’onglet Référence API.

​

Surface d’autorité

Le limit_order_admin est un gardien opérationnel hors chaîne, pas un multisig. Il ne peut appeler que SettleLimitOrder et CloseLimitOrder sur les ordres existants, et le résultat d’un règlement atterrit toujours dans l’ATA du propriétaire. Il ne peut pas muter les champs de pool, ouvrir ou modifier des ordres, ou signer pour quoi que ce soit d’autre. Voir Admin keys and multisig → CLMM.

​

Pages mises à jour

• products/clmm/overview — nouvelle section « What’s new » et pointeurs d’étapes suivantes mis à jour.
• products/clmm/accounts — trois nouveaux comptes, remodèle PoolState avec avertissement de migration, ajouts TickState, nouveaux assistants PDA.
• products/clmm/instructions — sept nouvelles instructions, addendum de comportement SwapV2, matrice de changement d’état mise à jour.
• products/clmm/fees — section des frais unidirectionnels, section des frais dynamiques avec tableau des paramètres.
• products/clmm/math — pseudo-code d’appairage des ordres à cours limite, dérivation des frais dynamiques.
• products/clmm/code-demos — démo createCustomizablePool, walkthrough complet des ordres à cours limite, nouveaux pièges.
• algorithms/clmm-math — référence croisée vers l’appairage des ordres à cours limite et les frais dynamiques dans la boucle de swap multi-tick.
• sdk-api/typescript-sdk — section d’ajouts du module CLMM, note de migration utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — deux nouveaux points de terminaison avec schémas de réponse.
• api-reference/openapi/temp-api-v1.yaml — trois nouveaux points de terminaison des ordres à cours limite (/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 points de terminaison de config CLMM.
• api-reference/temp-api-v1/overview — note sur les nouveaux points de terminaison des ordres actifs, historique par utilisateur et événements par PDA.
• reference/error-codes — onze nouveaux codes d’erreur CLMM (6040–6050) plus cinq codes hérités supprimés ; les codes numériques après les points de suppression ont décalé.
• security/admin-and-multisig — nouvelle ligne d’admin DynamicFeeConfig et ligne de gardien limit_order_admin, avec expliquant l’autorité bornée.

Vérifié par rapport à :

• Source raydium-clmm.
• Source @raydium-io/raydium-sdk-v2.
• Source api-v3 et temp-api-v1.

​

2026-04-26 — Publication initiale

Premier lancement public de l’ensemble de documentation de Raydium.

Vérifié par rapport à :

• Déploiements de programmes en direct sur Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Documentation publique Raydium et références on-chain jusqu’en avril 2026.

À partir de maintenant, chaque mise à jour de protocole, audit ou révision de documentation atterrit comme une nouvelle entrée dans ce fichier.

​

Conventions de documentation

• Versioning : cette documentation utilise le versioning basé sur le calendrier (YYYY-MM-DD). Chaque mise à jour crée une nouvelle entrée en haut du fichier.
• Date vérifiée : chaque entrée enregistre quand le contenu a été vérifié pour la dernière fois par rapport à l’état on-chain / API et au code source du programme. Si non indiqué, supposez la date principale de l’entrée.
• Changements importants : signalés dans un avertissement encadré sur les pages affectées et étiquetés dans l’entrée ci-dessous.
• Couverture : ce journal des modifications couvre l’ensemble de la documentation lui-même. La chronologie historique du protocole lui-même vit dans introduction/history-and-milestones et est la source de vérité pour « quand X s’est-il passé sur Raydium ».

​

Corrections

Si vous trouvez une erreur dans cette documentation, veuillez ouvrir un problème ou une demande de fusion sur le référentiel de documentation. Les corrections sont enregistrées dans ce journal des modifications.

​

Pointeurs

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