Versions et migration

​

Statut en un coup d’œil

L’enseignement le plus important de ce tableau : AMM v4 n’est pas déprécié, et CPMM est le nouveau standard — mais ils coexistent intentionnellement. Les pools AMM v4 ont des années d’historique de trading et ne sont pas forcément migrés. Le choix du programme sur lequel lancer un nouveau pool est une recommandation, pas une contrainte.

​

AMM v4 — statut et trajectoire

AMM v4 est la conception originale du pool Raydium : tarification à produit constant (x · y = k). Il a été lancé comme un AMM hybride avec une intégration du carnet de commandes OpenBook (anciennement Serum) qui reflétait des portions de la courbe sous forme d’ordres limités sur un marché lié. L’intégration OpenBook a depuis été désactivée — les pools ne partagent plus la liquidité avec OpenBook et tous les swaps s’exécutent purement contre la courbe via les points d’entrée de swap V2. AMM v4 aujourd’hui est, en pratique, un AMM à produit constant pur avec les comptes OpenBook conservés comme état inerte.

​

Ce qui est gelé

• Pas de nouvelles tranches de frais. La structure des frais AMM v4 est par pool et a été définie au déploiement. Les nouveaux pools acceptent le même frais de trading codé en dur d’environ 0,25 %, environ 12 % au protocole.
• Pas de nouveau travail de fonctionnalité. L’équipe n’a pas ajouté de nouvelles instructions à AMM v4 depuis que CPMM est devenu le nouveau standard. Le programme est en mode intendance — corrections de bugs uniquement, pas d’expansion de portée.
• Pas de support Token-2022. AMM v4 a été écrit avant l’existence de Token-2022 et l’intégration n’a jamais été rétrofittée. Les mints Token-2022 doivent utiliser CPMM (ou CLMM, le cas échéant).
• Intégration OpenBook désactivée. Chaque pool AMM v4 est toujours lié à un compte de marché OpenBook correspondant on-chain, mais le pool ne poste ni ne maintient plus d’ordres sur ce marché. Une panne OpenBook n’affecte plus les swaps AMM v4.

​

Ce qui fonctionne toujours

• Les pools existants se négocient normalement. Aucune migration d’état n’a été forcée ; les pools v4 créés en 2021 sont toujours le lieu actif pour de nombreuses paires à haut volume en 2026.
• Les LP peuvent déposer, retirer et récolter les récompenses de ferme comme d’habitude. La migration vers CPMM est optionnelle.
• Les agrégateurs continuent de router à travers. Jupiter et l’API Raydium Trade indexent tous deux les pools v4 comme des lieux de première classe.

​

Quand utiliser encore AMM v4

Honnêtement : rarement. Les cas où v4 est la meilleure réponse sont étroits :

• La paire a déjà un pool v4 profond et bien négocié et vous voulez ajouter de la liquidité à la profondeur existante plutôt que de diviser un marché.

(Le routing intégré OpenBook n’est plus une raison de choisir AMM v4 — cette intégration est désactivée.) Dans tous les autres cas, lancez les nouveaux pools sur CPMM. Voir user-flows/choosing-a-pool-type pour l’arbre de décision complet.

​

CPMM — courbe d’adoption et migration v4 → CPMM

CPMM (constant-product market maker, nom interne raydium-cp-swap) a été déployé en 2024 comme une réécriture en chambre stérile destinée à être le nouveau standard des pools à produit constant. C’est structurellement le plus simple des programmes Raydium : pur x · y = k, pas de carnet de commandes, support natif Token-2022, empreinte de transaction plus petite.

​

Ce que CPMM vous apporte par rapport à AMM v4

• Meilleures économies LP par défaut. La configuration AmmConfig par défaut de CPMM route 100 % des frais de trading vers les LP (avec les frais de protocole basculables par tranche). AMM v4 code en dur environ 12 % au protocole.
• Coût de création de pool inférieur. Pas de marché OpenBook nécessaire. La création est une transaction, environ 0,15 SOL de loyer contre environ 0,6 SOL pour v4.
• Token-2022. Mints avec frais de transfert, mints avec hook de transfert (avec réserves), transferts confidentiels — tous supportés sur CPMM, aucun sur v4.
• Surface d’intégrateur plus propre. CPMM a une caisse publiée conviviale pour Anchor-CPI (raydium-cp-swap), une liste de comptes plus simple et un IDL stable. AMM v4 expédie un IDL mais n’a jamais eu de caisse Rust CPI maintenue.
• Liste de comptes plus petite par swap. Environ 10 comptes contre environ 17 pour v4 (qui porte les comptes de marché OpenBook même quand on ne les utilise pas).

​

Quand la migration en vaut la peine

Pour un pool activement négocié, l’augmentation des frais LP seule justifie généralement la migration en quelques mois. L’arithmétique : un pool gagnant 0,25 % × $X de volume quotidien donne 0,03 % au protocole sur v4 (les 12 % manquants). Sur CPMM, cela revient aux LP. Sur un an, cela s’accumule de manière significative. Pour un pool à faible volume, la migration concerne davantage la pérennisation — meilleurs défauts, support Token-2022 si vous en avez jamais besoin, intégrations plus faciles.

​

Comment fonctionne la migration

Il n’y a pas de mise à niveau sur place. La migration est une séquence créer-nouveau-pool, drainer-ancien-pool, remplir-nouveau-pool. L’étape par étape complète est dans user-flows/migrate-amm-v4-to-cpmm ; la forme de haut niveau :

1. Créez un nouveau pool CPMM pour la même paire, sur la même tranche de frais que vous voulez conserver.
2. Coordonnez les LP : annoncez une fenêtre pendant laquelle l’ancien pool est drainé et le nouveau pool ensemencé.
3. Chaque LP se retire du pool v4 et dépose dans le nouveau pool CPMM.
4. (Optionnel) Configurez une ferme côté CPMM pour attirer les LP incités vers le nouveau pool.
5. Regardez le volume migrer alors que les agrégateurs se repondèrent vers le pool plus profond.

La chaîne elle-même n’impose rien de tout cela — l’API Raydium et le frontend favorisent simplement le pool le plus profond, et les agrégateurs routent à travers celui qui est le moins cher pour l’utilisateur.

​

CLMM — programme unique, stable entre les versions

CLMM en est à sa première version de programme. Il n’y a pas eu de v2 — les améliorations ont été expédiées comme des mises à niveau sur place du même ID de programme (derrière le multisig verrouillé 24h), pas comme une nouvelle génération. Cela signifie qu’il n’y a pas d’histoire de migration CLMM : les positions existantes restent où elles sont, et le comportement du programme peut changer subtilement quand une mise à niveau est expédiée, mais les dispositions de compte et les PDA sont stables. Ce qui a changé entre les mises à niveau CLMM :

• Instruction SwapV2 ajoutée pour supporter correctement les mathématiques des frais de transfert Token-2022. L’ancien Swap est toujours appelable ; les nouvelles intégrations doivent cibler SwapV2.
• Extensions de flux de récompenses — le nombre d’emplacements RewardInfo a été augmenté (les 3 originaux → toujours 3 actuellement, mais le motif de réservation a été resserré). Aucune migration de données nécessaire.
• Compaction de tableau de ticks — optimisation interne pour réduire les CU sur les swaps traversant de nombreux ticks. Invisible de l’extérieur.
• Reconstruction Anchor 1.0 (2026-09-30) : passe de Anchor 0.32.1 à 1.0.2 et ajoute l’admin CollectExcessLamports. Aucune instruction ou disposition de compte visible par l’utilisateur n’a changé. Voir l’entrée du changelog.

L’IDL vit dans le dépôt dédié raydium-idl (voir sdk-api/anchor-idl). Si vous exécutez un SDK plus ancien contre le programme actuel, le pire des cas est de manquer les nouvelles instructions.

​

Farm v3 → v5 → v6

De tous les programmes Raydium, Farm a l’historique de version le plus explicite et le seul chemin de migration forcée. Les trois générations sont des programmes séparés avec des ID de programme séparés et des dispositions d’état séparées.

​

Générations

​

Pourquoi trois générations existent

• v3 → v5 : nécessitait plusieurs flux de récompenses concurrents (par exemple, fermes à double incitation). La conception à flux unique de v3 ne pouvait pas le supporter sans une refonte.
• v5 → v6 : le taux d’émission entier u64 de v5 plafonne le taux minimum exprimable à « 1 unité de token par seconde ». Pour un mint à 9 décimales, c’est 1 lamport/sec — bien trop grossier pour les programmes à faible émission. Le taux fractionnaire Q64.64 de v6 corrige cela. v6 a également levé la mise à jour basée sur les slots à l’horloge murale, et a ajouté le support Token-2022.

​

Ce qui reste identique entre les générations

• Le motif comptable « déposer LP, accumuler compteur par action, réclamer au retrait » est identique entre v3/v5/v6. Les mathématiques ne changent pas ; seule la précision du compteur de taux et le nombre de flux supportés.
• UserStake (v3/v5) et UserLedger (v6) sont conceptuellement le même enregistrement, avec des dispositions différentes. Le SDK normalise les deux.

​

Chemin de migration

Il n’y a pas de migration sur place entre les versions de ferme. Pour passer de v3/v5 à v6 :

1. Attendez que les émissions de la ferme existante se terminent (ou les réduisez).
2. Les stakers se retirent et réclament les récompenses en attente sur l’ancienne ferme.
3. L’opérateur de ferme crée une nouvelle ferme v6 contre le même mint de staking.
4. Les stakers re-stakent dans la nouvelle ferme.

La réalité on-chain est deux comptes de ferme non liés. Un utilisateur avec du stake dans les deux a deux enregistrements UserLedger (v6) / UserStake (v5).

​

Ce que « phase de fermeture » signifie pour v3 et v5

• Les programmes v3 et v5 sont toujours déployés et appelables. Les fermes existantes peuvent toujours distribuer les récompenses en attente et accepter les retraits.
• L’interface utilisateur Raydium affiche toujours les fermes v3 et v5 avec des récompenses actives ; une fois que le end_time d’une ferme v3/v5 passe, l’interface utilisateur la cache de « actif » mais la garde réclamable.
• L’équipe ne créera pas de nouvelles fermes v3/v5. Les aides SDK pour « créer une ferme » routent vers v6 uniquement.
• v3 et v5 reçoivent des mises à jour de sécurité mais pas de travail de fonctionnalité. Si un bug critique est trouvé, il est corrigé ; si une fonctionnalité pourrait être utile, elle est ajoutée à v6 à la place.

Les détails complets par version sont dans products/farm-staking/accounts et products/farm-staking/instructions.

​

LaunchLab — programme unique, configuration évolutive

LaunchLab en est à sa première version de programme. Comme CLMM, les améliorations sont expédiées comme des mises à niveau sur place derrière le verrou 24h — pas comme de nouvelles générations. Ce qui a évolué à travers les mises à niveau :

• Emplacement des frais du créateur. Ajouté pour que les lancements puissent router une portion des frais de trading CPMM post-graduation vers le créateur original. Voir products/launchlab/creator-fees.
• Configurabilité de la formule de courbe. Originalement codée en dur quadratique ; maintenant la LaunchConfig sélectionne parmi un petit ensemble de formes de courbe.

Les lancements LaunchLab existants ne sont pas affectés par les mises à niveau — une fois qu’un lancement est initialisé, ses paramètres sont gelés jusqu’à la graduation.

​

Compatibilité des versions entre programmes

Quelques notes de compatibilité entre produits que les intégrateurs rencontrent régulièrement :

• L’instruction CLMM SwapV2 n’est pas la même que Swap. Si votre client ne parle que Swap, il gérera silencieusement mal les frais de transfert Token-2022 — les mathématiques sont fausses du montant des frais. Mettez à jour vers SwapV2.
• Le staking Farm v6 avec les positions CLMM n’est pas supporté de la même manière que le staking des tokens LP. Les positions CLMM sont des NFT, pas des tokens LP fongibles. CLMM a son propre mécanisme de récompense natif à la place — voir products/clmm/fees.
• Les pools CPMM soutenus par les mints Token-2022 ne fonctionnent dans les fermes que sur Farm v6. v3 et v5 rejettent les mints de staking Token-2022.
• Les pools AMM v4 n’ont jamais de mints LP Token-2022. Si vous en voyez un, c’est un faux — AMM v4 ne supporte pas cette combinaison.

​

Où en savoir plus

• introduction/history-and-milestones — la chronologie de lancement et pourquoi chaque version a atterri quand elle l’a fait.
• user-flows/migrate-amm-v4-to-cpmm — le runbook d’opérateur pour le passage v4 → CPMM.
• user-flows/choosing-a-pool-type — arbre de décision pour les nouveaux déploiements de pool.
• products/farm-staking/accounts — schéma côte à côte pour v3 / v5 / v6.
• reference/changelog — ce qui a changé dans cette documentation à mesure que les versions de programme ont évolué.

Sources :

• Pages de chapitre par produit citées en ligne ci-dessus.
• Raydium SDK v2 — la logique de dispatch consciente de la version confirme quel programme un pool donné appartient.
• reference/program-addresses — ID canoniques par version.