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-en une 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

​
CLMM : CreateCustomizablePoolV2 ouvre la création multi-pools à tous
CreatePermissionedPool est renommé en CreateCustomizablePoolV2 et perd sa porte PDA Permission, de sorte que n’importe quel payeur peut créer des pools supplémentaires pour la même paire et le même niveau de frais à une adresse dérivée de seed_index. Les arguments et la dérivation de l’adresse du pool restent inchangés, mais le discriminateur change et le compte permission quitte l’emplacement 3, donc les clients construits contre l’ancienne instruction doivent être reconstruits. pool_creator n’est pas authentifié, donc le owner d’un pool V2 n’est pas une preuve de qui l’a créé. Le compte Permission, CreatePermissionPda, ClosePermissionPda et la clé permission_pda_admin sont supprimés ; les PDAs Permission créés antérieurement restent sur la chaîne en tant que données inertes. Aucune disposition de compte ou code d’erreur n’a changé. L’IDL passe à 37 instructions.Lire l’entrée complète →
​
CLMM : Anchor 1.0, récupération des lamports excédentaires et propriétaires de frais fixes
CLMM passe à Anchor 1.0.2 sur Agave 3.1.10, le même passage que CPMM et LaunchLab ont effectué le 2026-09-09. Les deux crates CPI publiques épinglent maintenant =1.0.2, de sorte qu’un seul programme peut faire du CPI dans CPMM et CLMM. Un nouvel admin CollectExcessLamports retourne le loyer libéré par SIMD-0437. Il balaie un pool par appel : le PDA PoolState signe pour ses propres coffres et coffres de récompenses, les coffres wSOL passent par la boucle SyncNative / UnwrapLamports, et tout compte appartenant à CLMM dans remaining_accounts est débité jusqu’à son minimum de loyer. CreateAmmConfig écrit maintenant les clés protocol_fee_owner et fund_fee_owner codées en dur au lieu du signataire. Sur mainnet, ce sont les clés déjà stockées sur les 21 configs, et les configs existantes ne sont pas réécrites. 6052 ajouté. Aucune instruction ou disposition de compte visible par l’utilisateur n’a changé.Lire l’entrée complète →
​
CPMM : le protocole prend une part des frais du créateur
CPMM peut maintenant conserver une partie des frais du créateur. La répartition est appliquée lorsque les frais sont collectés, et non lorsqu’ils sont facturés : un swap accumule toujours les frais complets du créateur dans creator_fees_token*, et CollectCreatorFee / CollectCreatorFeePermissionless déplacent ensuite une part dans les compteurs protocol_fees_token* existants du pool et paient le reste au créateur — en arrondissant vers le bas, de sorte que la poussière reste avec le créateur. Le taux provient d’un nouveau AmmConfig.creator_fee_share_rate (extrait du remplissage ; le compte fait toujours 236 octets, mais l’ancien padding[0] est maintenant un champ actif) ou d’un PDA CreatorFeeShare par créateur qui le remplace, géré par les nouveaux admins CreateCreatorFeeShare / CloseCreatorFeeShare. Rupture pour les clients de frais de créateur : les deux instructions de collecte prennent de nouveaux comptes ajoutés à la fin de leurs listes — les comptes existants conservent leurs positions, mais les nouveaux sont obligatoires, de sorte qu’une transaction pré-mise à niveau est rejetée pour comptes manquants. UpdateAmmConfig gagne param = 8. PoolState, la mathématique de swap et la vérification k restent inchangées, et aucun code d’erreur n’a été ajouté. En parallèle : une correction d’ordre à deux passes dans CollectExcessLamports.Lire l’entrée complète →
​
LaunchLab : Anchor 1.0, récupération des lamports excédentaires et fin des portes de transition
LaunchLab passe à Anchor 1.0.2 sur Agave 3.1.10 et retire son échafaudage de transition. Le Initialize déprécié échoue maintenant inconditionnellement avec NotApproved. MigrateToCpswap est une rupture majeure pour le portefeuille de migration : les trois arguments et neuf comptes OpenBook ont disparu, suivant la propre suppression d’OpenBook d’AMM v4, et le programme n’initialise plus le marché par CPI. La porte d’horloge get_upgrade_timestamp est supprimée, de sorte que les trois remaining_accounts de trade sont inconditionnellement requis (avec l’emplacement system_program maintenant validé), MigrateToCpswap prend toujours le chemin CPMM autorisé, et InitializeWithToken2022 abandonne sa restriction amm_fee_on. Un nouvel admin CollectExcessLamports retourne le loyer libéré par SIMD-0437 — notez que les comptes source doivent être groupés selon lequel des trois PDAs d’autorité de coffre les possède. Trois contraintes d’adresse MigrateToCpswap ont été déplacées dans le corps de l’instruction, changeant 2012 en 2502. 6031 ajouté. Aucune disposition de compte, instruction de trade ou comportement de frais n’a changé.Lire l’entrée complète →
​
CPMM : Anchor 1.0, récupération des lamports excédentaires et propriétaires de frais fixes
CPMM passe à Anchor 1.0.2 sur Agave 3.1.10 et ajoute un admin CollectExcessLamports qui retourne le loyer libéré par SIMD-0437 des coffres, des mints LP et des PDAs — coffres SOL enveloppés inclus, via une boucle SyncNative / UnwrapLamports qui laisse le solde enveloppé intact. Trois changements comportementaux viennent avec : CreateAmmConfig écrit maintenant les clés protocol_fee_owner et fund_fee_owner codées en dur au lieu du signataire (les configs existantes ne sont pas migrées — lisez les champs), la MINT_WHITELIST Token-2022 à quatre adresses codée en dur est supprimée de sorte que le PDA du registre SupportMintAssociated est le seul contournement restant, et ClosePermissionPda accepte maintenant l’autorité de subvention dédiée. 6015 ajouté. Aucune instruction ou disposition de compte visible par l’utilisateur n’a changé.Lire l’entrée complète →
​
AMM v4 : dépendances Solana 3.0 et récupération des lamports excédentaires
AMM v4 se reconstruit par rapport à solana-program 3.0.0, spl-token 9.0.0, spl-associated-token-account 8.0.0 et la nouvelle crate solana-system-interface, et ajoute un WithdrawExcessLamports réservé aux admins (tag 18) qui retourne le loyer libéré par SIMD-0437. Chaque instruction destinée aux traders et aux LP conserve ses comptes, arguments et mathématiques, et rien dans la version n’est une rupture : CreateConfigAccount a cessé de lire sa sysvar de loyer finale mais accepte toujours l’ancienne liste de cinq comptes. AmmError gagne le code 60 (il numéroté à partir de 0, pas 6000).Lire l’entrée complète →
​
LaunchLab : les règles de courbe de plateforme remplacent la liste blanche des paramètres de courbe
Les restrictions de paramètres de lancement se déplacent hors de PlatformConfig dans des comptes PlatformCurveRule par config. 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 — de sorte qu’une plateforme peut enfin exprimer une bande de valeur, des niveaux alternatifs, un plafond de valorisation de graduation, un plancher de migration, un portail de type de jeton, ou un groupe qui bascule sur une date, aucun desquels la liste blanche d’égalité uniquement ne pouvait. PlatformConfig conserve sa taille de 944 octets : restrict_curve_param, curve_rule_manager, et le préfixe de longueur du vec supprimé sortent tous du remplissage. Les décodeurs doivent abandonner le Vec<PlatformCurveParam> final, et les constructeurs 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és. Actualisation IDL requise. Le SDK expédie deux vérifications pures hors chaîne de sorte 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 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 à partir de 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, de sorte qu’une plateforme peut balayer 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éaffecte cette autorité uniquement lorsque 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, de sorte que la rotation de transfer_fee_extension_auth en milieu 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 : plafond du taux de frais de plateforme relevé à 500 bps
Le plafond fee_rate de la 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, de sorte qu’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 re-valide 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 jetons 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, de sorte que les décodeurs qui testent l’octet entier par rapport à 0 mal lisent un mint de base hérité comme Token-2022. MigrateToCpswap renomme ses deux comptes de programme de jetons 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 appartenant au créateur ; les migrations CPMM exécutées après la mise à niveau consolident à la place platform_scale + creator_scale en une part de clé de frais appartenant à la plateforme. Les plateformes peuvent également restreindre les lancements avec leurs propres PDAs PlatformAllowConfig, et les constructeurs de migration doivent ajouter les deux PDAs de support-mint CPMM.Lire l’entrée complète →
​
CLMM : gel de position NFT à émetteur restreint
Les nouveaux mints de position NFT CLMM utilisent leur pool comme autorité de gel, mais leurs comptes de jetons restent dégelés par défaut. Le gel se produit uniquement sur OpenPositionV2 ou OpenPositionWithToken22Nft lorsque l’autorité de gel de l’un ou l’autre mint de 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 de sorte 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 balayer tous les frais de créateur accumulés, tout en contraignant le bénéficiaire et les deux destinations de jetons à 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é aux admins.Lire l’entrée complète →
​
CLMM : multi-pools autorisés et garde de compte gelé pour ordres limites
Deux mises à jour de programme CLMM additives et rétro-compatibles. CreatePermissionedPool intègre un seed_index non nul fourni par le client dans les graines PDA du pool, permettant à un opérateur autorisé (celui détenant un PDA Permission) de créer plusieurs pools par (config, mint0, mint1) — de sorte qu’un ID de pool n’est plus canonique pour une paire. Les nouvelles instructions admin CreatePermissionPda / ClosePermissionPda gèrent ces subventions, et PoolState gagne un champ seed_index (extrait du 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 jetons d’entrée ou de sortie est gelé (NotApproved).Lire l’entrée complète →
​
AMM v4 : supprimer la dépendance OpenBook / Serum
AMM v4 supprime sa dépendance OpenBook/Serum longtemps dormante, tous les CPIs du carnet de commandes et les instructions mortes de tenue 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 une rupture majeure (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 sur la chaîne et les codes d’erreur restent stables ; migrez les swaps vers les points d’entrée V2.Lire l’entrée complète →
​
Stable AMM : supprimer le code OpenBook (marché) mort
Stable AMM supprime ses comptes et code de tenue 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 une rupture majeure (16 → 10, pas de compatibilité) ; les frais de parrainage retirés ; et une formule de bien du pool simplifiée réservée aux coffres. La plupart des autres instructions 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 PoolState (changement de rupture d’indexeur), de nouveaux champs TickState, onze nouveaux codes d’erreur (avec un décalage numérique) et les ajouts SDK / API correspondants.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 un 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 se trouve sur sa propre page sous reference/changelog/, ce qui permet de garder cet index court et chaque entrée indépendamment liée.
  • Date vérifiée : chaque entrée enregistre quand le contenu a été dernièrement recoupé par rapport à l’état on-chain / API et à la source du programme. Si ce n’est pas indiqué, supposez la date principale de l’entrée.
  • Changements cassants : signalés dans un avertissement encadré sur les pages affectées et marqués dans l’entrée.
  • Couverture : ce changelog couvre l’ensemble de la documentation. La chronologie historique du protocole lui-même se trouve dans introduction/history-and-milestones et fait autorité pour « quand X s’est-il produit sur Raydium ».

​
Corrections

Si vous trouvez une erreur dans cette documentation, veuillez ouvrir une issue ou une pull request sur le dépôt de documentation. Les corrections sont enregistrées comme des entrées de changelog.

​
Pointeurs