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 : 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. L’instruction Initialize dépréciée échoue désormais inconditionnellement avec NotApproved. MigrateToCpswap est cassante pour le portefeuille de migration : les trois arguments et neuf comptes OpenBook ont disparu, suite à la suppression d’OpenBook dans AMM v4, et le programme n’initialise plus le marché par CPI. La porte d’horloge get_upgrade_timestamp est supprimée, donc les trois remaining_accounts des instructions de trading sont inconditionnellement requis (avec le slot system_program désormais validé), MigrateToCpswap emprunte toujours le chemin CPMM autorisé, et InitializeWithToken2022 supprime sa restriction amm_fee_on. Une nouvelle instruction 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 de MigrateToCpswap ont été déplacées dans le corps de l’instruction, changeant 2012 en 2502. 6031 ajouté. Aucune disposition de compte, instruction de trading 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 corrigés
CPMM passe à Anchor
1.0.2 sur Agave 3.1.10 et ajoute une instruction admin CollectExcessLamports qui retourne le loyer libéré par SIMD-0437 des coffres, des mints LP et des PDAs — y compris les coffres SOL enveloppés, via un aller-retour SyncNative / UnwrapLamports qui laisse le solde enveloppé intact. Trois changements comportementaux l’accompagnent : CreateAmmConfig écrit désormais les clés protocol_fee_owner et fund_fee_owner codées en dur au lieu du signataire (les configurations existantes ne sont pas migrées — lisez les champs), la liste blanche Token-2022 MINT_WHITELIST codée en dur à quatre adresses est supprimée donc le PDA du registre SupportMintAssociated est le seul contournement restant, et ClosePermissionPda accepte désormais 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 caisse solana-system-interface, et ajoute une instruction admin-only WithdrawExcessLamports (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 cassant : 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 de
PlatformConfig vers 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 — donc une plateforme peut enfin exprimer une bande de valeur, des niveaux alternatifs, un plafond de valorisation de graduation, un plancher de migration, un contrôle d’accès par type de jeton, ou un groupe qui bascule à 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 vecteur supprimé sortent tous du remplissage. Les décodeurs doivent supprimer 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 purement hors-chaîne afin 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 depuis la création du mint
InitializeWithToken2022 écrit désormais PlatformConfig.transfer_fee_extension_auth dans la withdraw_withheld_authority du nouveau mint de base au lieu du PDA authority de lancement, afin qu’une plateforme puisse 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éassigne 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, 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 : plafond du taux de frais de plateforme relevé à 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 désormais, 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 désormais ê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 slot de programme de devis ; l’instruction Initialize dépréciée reste legacy-only. Les limites de slippage de swap sont désormais 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 lisent un mint de base legacy 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 désormais CPMM tandis que l’état lié à AMM v4 legacy 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 constructeurs de migration doivent ajouter les deux PDAs de support-mint 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 lorsque l’autorité de gel du 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 afin 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 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 admin-only.Lire l’entrée complète →CLMM : multi-pools autorisé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 admin CreatePermissionPda / ClosePermissionPda gèrent ces subventions, et PoolState gagne un champ seed_index (taillé dans le remplissage, aucun changement de taille). Séparément, OpenLimitOrder prend désormais 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 OpenBook/Serum longtemps dormante, tous les CPIs 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 désormais ignorés, non validés) ; un WithdrawPnl cassant (17 → 10, aucune 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 →Stable AMM : suppression du code OpenBook (marché) mort
Stable AMM supprime ses comptes et code de création de marché OpenBook longtemps dormants. Dispositions plus petites de
SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12), et Withdraw (21/22 → 12) (les anciennes dispositions restent compatibles) ; un changement WithdrawPnl cassant (16 → 10, aucune compatibilité) ; les frais de parrainage retirés ; et une formule d’actif de pool simplifiée réservée au coffre. 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 opt-in 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 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 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 lui-même vit dans
introduction/history-and-milestoneset 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 de journal des modifications.Pointeurs
introduction/history-and-milestones— la chronologie du protocole lui-même.security/audits— historique des audits.ray/protocol-fees— répartition des frais de protocole.reference/program-addresses— source de vérité des ID de programme.