Skip to main content
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 — l’enregistrement des mises à jour de ces pages depuis le lancement du projet. Chaque version ci-dessous renvoie à sa propre entrée ; ouvrez-la pour le résumé complet, les chapitres affectés et la date de vérification. Pour la chronologie historique du protocole lui-même, consultez introduction/history-and-milestones.

​
Versions

​
LaunchLab : les règles de courbe de plateforme remplacent la liste blanche des paramètres de courbe
Les restrictions de paramètres de lancement passent de PlatformConfig à des comptes PlatformCurveRule par configuration. Une règle contient jusqu’à 10 groupes de vérification de jusqu’à 25 contraintes (field, op, value) sur 19 paramètres de lancement, avec Eq / Gte / Lte / Neq — permettant à une plateforme d’exprimer enfin une bande de valeurs, des niveaux alternatifs, un plafond de valorisation à la graduation, un plancher de migration, un contrôle d’accès par type de jeton, ou un groupe qui bascule à une date donnée, ce que la liste blanche d’égalité uniquement ne pouvait pas faire. PlatformConfig conserve sa taille de 944 octets : restrict_curve_param, curve_rule_manager et le préfixe de longueur du vecteur supprimé sortent tous du remplissage. Les décodeurs doivent supprimer le Vec<PlatformCurveParam> final, et les créateurs de lancement doivent ajouter le PDA de règle à remaining_accounts tandis que l’indicateur est activé. Deux instructions supprimées, quatre ajoutées, deux variantes UpdatePlatformConfig ajoutées, 6024–6030 ajoutées. Actualisation de l’IDL requise. Le SDK fournit deux vérifications purement hors-chaîne pour qu’un créateur n’ait jamais à apprendre une règle à partir d’une transaction annulée, et l’entrée documente une répétition sur devnet avant d’activer l’indicateur sur mainnet.Lire l’entrée complète →
​
LaunchLab : la plateforme détient l'autorité de retrait des frais retenus depuis la création du mint
InitializeWithToken2022 écrit maintenant PlatformConfig.transfer_fee_extension_auth dans la withdraw_withheld_authority du nouveau mint de base au lieu du PDA authority de lancement, permettant à une plateforme de récupérer les frais de transfert retenus pendant la phase de courbe de liaison plutôt que d’attendre la graduation — le programme lui-même n’a pas d’instruction de retrait des frais retenus. MigrateToCpswap réassigne cette autorité uniquement quand le PDA la détient toujours, ce qui maintient la graduation fonctionnelle pour les mints des deux générations. transfer_fee_config_authority se déplace toujours à la graduation uniquement, donc faire tourner transfer_fee_extension_auth en cours de lancement laisse silencieusement les deux autorités sur des clés différentes. Aucune disposition de compte, instruction, argument ou code d’erreur n’a changé.Lire l’entrée complète →
​
LaunchLab : le plafond du taux de frais de plateforme augmente à 500 bps
Le plafond du fee_rate de plateforme passe à 50000 (500 bps) sur les deux chemins qui le valident. CreatePlatformConfig était plafonné à 10000 (100 bps) depuis la première version du programme ; UpdatePlatformConfig était plafonné à 25000 (250 bps) depuis 2026-01-27. Les deux vérifications s’accordent maintenant, donc une plateforme créée à n’importe quel taux autorisé peut également être mise à jour à ce taux — y compris via la variante en masse AllInfo, qui revalide fee_rate tout en réécrivant tous les autres champs. Les deux chemins lèvent toujours des erreurs différentes (InvalidInput à la création, InvalidPlatformInfo à la mise à jour). Aucune disposition de compte, instruction ou code d’erreur n’a changé, et aucune plateforme ou lancement existant ne change de prix. GlobalConfig.max_share_fee_rate reste à 100 bps et limite uniquement le share_fee_rate de parrainage par transaction.Lire l’entrée complète →
​
LaunchLab : mints de devis Token-2022
Un lancement peut maintenant être coté dans un mint Token-2022. CreateConfig, InitializeV2, InitializeWithToken2022, les quatre instructions de swap et chaque réclamation de frais acceptent l’un ou l’autre programme de jeton dans leur emplacement de programme de devis ; le Initialize déprécié reste réservé à l’héritage. Les limites de slippage de swap sont maintenant comparées à ce que le payeur paie ou reçoit réellement, net des frais de transfert du mint de devis. Le bit1 de PoolState.token_program_flag devient significatif, donc les décodeurs qui testent l’octet entier contre 0 mal interprètent un mint de base hérité comme Token-2022. MigrateToCpswap renomme ses deux comptes de programme de jeton en token_program / token_program_2022, et 6023 est réutilisé pour CalculateOverflow.Lire l’entrée complète →
​
LaunchLab : lancements CPMM uniquement et contrôles de configuration de plateforme
L’initialisation de lancement nouvelle nécessite maintenant CPMM tandis que l’état lié à l’AMM v4 hérité reste migratable. Avant cette version, creator_scale produisait une Clé de Frais détenue par le créateur ; les migrations CPMM exécutées après la mise à niveau consolident à la place platform_scale + creator_scale en une seule part de Clé de Frais détenue par la plateforme. Les plateformes peuvent également restreindre les lancements avec leurs propres PDAs PlatformAllowConfig, et les créateurs de migration doivent ajouter les deux PDAs de mint de support CPMM.Lire l’entrée complète →
​
CLMM : gel de NFT de position à émetteur restreint
Les nouveaux mints de NFT de position CLMM utilisent leur pool comme autorité de gel, mais leurs comptes de jeton restent dégelés par défaut. Le gel se produit uniquement sur OpenPositionV2 ou OpenPositionWithToken22Nft quand l’autorité de gel du mint du coffre sous-jacent correspond à la liste des émetteurs restreints. Une position correspondante ne peut pas transférer ou changer de propriétaire mais peut toujours gérer la liquidité. Son appel ClosePosition doit ajouter le pool pour que CLMM puisse dégeler, brûler et fermer atomiquement. Les positions existantes restent inchangées.Lire l’entrée complète →
​
CPMM : collecte de frais de créateur sans permission
Une instruction additive CollectCreatorFeePermissionless permet à n’importe quel payeur de récupérer tous les frais de créateur accumulés, tout en limitant le bénéficiaire et les deux destinations de jeton à PoolState.pool_creator et aux ATAs canoniques du créateur. Le chemin signé par le créateur original reste inchangé. CreatePermissionPda accepte également une autorité de subvention dédiée, tandis que ClosePermissionPda reste réservé à l’administrateur.Lire l’entrée complète →
​
CLMM : pools multi-permissionnés et garde de compte gelé pour ordres limites
Deux mises à jour du programme CLMM additives et rétro-compatibles. CreatePermissionedPool intègre un seed_index non nul fourni par le client dans les graines du PDA du pool, permettant à un opérateur autorisé (détenant un PDA Permission) de créer plusieurs pools par (config, mint0, mint1) — donc un ID de pool n’est plus canonique pour une paire. Les nouvelles instructions d’administrateur CreatePermissionPda / ClosePermissionPda gèrent ces subventions, et PoolState gagne un champ seed_index (taillé dans le remplissage, pas de changement de taille). Séparément, OpenLimitOrder prend maintenant les comptes du côté de la sortie et rejette les ordres dont le compte de jeton d’entrée ou de sortie est gelé (NotApproved).Lire l’entrée complète →
​
AMM v4 : suppression de la dépendance OpenBook / Serum
AMM v4 supprime sa dépendance longtemps dormante à OpenBook/Serum, tous les CPI du carnet de commandes et les instructions mortes de création de marché. SwapBaseIn / SwapBaseOut, Deposit et Withdraw conservent leurs dispositions (les comptes de marché supprimés sont maintenant ignorés, non validés) ; un WithdrawPnl cassant (17 → 10, pas de compatibilité) et SetParams (comptes réduits + param renuméroté) ; et Initialize, PreInitialize, MonitorStep, MigrateToOpenBook, WithdrawSrm, SimulateInfo, AdminCancelOrders ne sont plus appelables. Les dispositions de compte on-chain et les codes d’erreur restent stables ; migrez les swaps vers les points d’entrée V2.Lire l’entrée complète →
​
AMM stable : suppression du code OpenBook (marché) mort
AMM stable supprime ses comptes et code de création de marché OpenBook longtemps dormants. Dispositions plus petites SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12) et Withdraw (21/22 → 12) (les anciennes dispositions restent compatibles) ; un changement WithdrawPnl cassant (16 → 10, pas de compatibilité) ; les frais de parrainage supprimés ; et une formule d’actif de pool simplifiée réservée au coffre. La plupart des autres instructions AMM stable ne sont plus appelables.Lire l’entrée complète →
​
CLMM : ordres limites, frais unilatéraux, frais dynamiques
Trois capacités CLMM optionnelles et rétro-compatibles : ordres limites de première classe (avec un gardien de règlement limit_order_admin), collecte de frais unilatéraux (CollectFeeOn) et un frais dynamique suivi par la volatilité. Ajoute CreateCustomizablePool, une refonte de PoolState (changement cassant pour l’indexeur), nouveaux champs TickState, onze nouveaux codes d’erreur (avec un décalage numérique) et les ajouts correspondants du SDK / API.Lire l’entrée complète →
​
Publication initiale
Première version publique de l’ensemble de documentation Raydium, vérifiée par rapport aux déploiements mainnet-beta en direct et @raydium-io/raydium-sdk-v2@0.2.42-alpha.Lire l’entrée complète →

​
Conventions de documentation

  • Versioning : cette documentation utilise le versioning basé sur le calendrier (YYYY-MM-DD). Chaque mise à jour ajoute une nouvelle page d’entrée et une nouvelle ligne en haut de la chronologie ci-dessus.
  • Une page par version : chaque résumé de version vit sur sa propre page sous reference/changelog/, donc cet index reste court et chaque entrée est indépendamment liée.
  • Date de vérification : chaque entrée enregistre quand le contenu a été dernièrement recoupé 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 cassants : appelés dans un avertissement encadré sur les pages affectées et marqués dans l’entrée.
  • Couverture : ce journal des modifications couvre l’ensemble de documentation lui-même. La chronologie historique du protocole vit dans introduction/history-and-milestones et est la source de vérité pour « quand X s’est-il produit sur Raydium ».

​
Corrections

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

​
Pointeurs