Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Raydium existe depuis cinq ans. Plusieurs de ses programmes en sont à leur troisième ou quatrième génération. Cette page offre une vue d’opérateur : « Quelle version de programme dois-je utiliser, quel est le statut des anciennes versions, et comment passer de la version A à la version B si j’utilise actuellement l’ancienne version ? »

​
État synthétique

ProgrammeActuelleDépréciéeNouveaux déploiementsInstances existantes
AMM v4v4 (une seule génération)NonDécouragé mais acceptéEntièrement opérationnel
CPMMv1—Par défaut recommandéEntièrement opérationnel
CLMMv1—Recommandé pour les LP limitésEntièrement opérationnel
Farmv6v3, v5v6 uniquementv3 + v5 en cours de fermeture (surtout en lecture seule)
LaunchLabv1—Recommandé pour les nouveaux lancementsEntièrement opérationnel
Le point le plus important à retenir 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 plusieurs années d’historique de trading et ne sont pas en migration forcée. 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 de pool Raydium : tarification à produit constant (x · y = k). Il a été lancé comme un AMM hybride avec une intégration du carnet d’ordres OpenBook (anciennement Serum) qui reflétait certaines portions de la courbe sous forme d’ordres limités sur un marché associé. 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 pur à produit constant avec les comptes OpenBook conservés comme état inerte.

​
Ce qui est gelé

  • Plus de nouveaux paliers 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, sans expansion de portée.
  • Pas de support Token-2022. AMM v4 a été écrit avant que Token-2022 n’existe et l’intégration n’a jamais été rétroactive. 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 plus ou 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 d’échange actif pour de nombreuses paires à fort 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 routent toujours à travers. Jupiter et l’API Raydium Trade indexent tous les deux les pools v4 comme des lieux 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, bien négocié et vous souhaitez ajouter de la liquidité à la profondeur existante plutôt que de diviser un marché.
(Le routage 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. Consultez 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 de salle propre 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 d’ordres, support natif de Token-2022, empreinte transactionnelle plus petite.

​
Ce que CPMM vous donne par rapport à AMM v4

  • Meilleure économie de LP par défaut. La AmmConfig par défaut de CPMM route 100 % des frais de trading vers les LP (avec les frais de protocole basculables par palier). AMM v4 code en dur environ 12 % pour le protocole.
  • Coût de création de pool inférieur. Aucun 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 de frais de transfer, mints de transfer-hook (avec réserves), transferts confidentiels — tous soutenus 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 une 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 ne les utilisent 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 se compose de manière significative. Pour un pool à bas volume, la migration est davantage une question de viabilité future — meilleurs paramètres par défaut, 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. Le pas-à-pas complet est dans user-flows/migrate-amm-v4-to-cpmm ; la forme haut niveau :
  1. Créez un nouveau pool CPMM pour la même paire, au même palier de frais que vous souhaitez conserver.
  2. Coordonnez avec les LP : annoncez une fenêtre pendant laquelle l’ancien pool est drainé et le nouveau pool est rempli.
  3. Chaque LP se retire du pool v4 et se dépose dans le nouveau pool CPMM.
  4. (Optionnel) Mettez en place une ferme du côté CPMM pour attirer les LP incités vers le nouveau pool.
  5. Regardez le volume migrer alors que les agrégateurs rééquilibrent vers le pool plus profond.
La chaîne elle-même ne force rien de tout cela — l’API et l’interface de Raydium favorisent simplement quel que soit le pool plus profond, et les agrégateurs routent à travers quel que soit le moins cher pour l’utilisateur.

​
CLMM — programme unique, stable entre les versions

CLMM 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é par 24h), et non 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 légèrement quand une mise à niveau est expédiée, mais les mises en page de compte et les PDA sont stables. Ce qui a changé entre les mises à niveau de CLMM :
  • Instruction SwapV2 ajoutée pour supporter correctement les mathématiques de frais de transfer Token-2022. L’ancien Swap est toujours appelable ; les nouvelles intégrations doivent cibler SwapV2.
  • Extensions de flux de récompense — le compte de slot RewardInfo a été augmenté (l’original 3 → 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 le swap traversant de nombreux ticks. Invisibles en externe.
L’IDL vit dans le référentiel dédié raydium-idl (voir sdk-api/anchor-idl). Si vous exécutez un SDK plus ancien contre le programme actuel, le pire 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 distincts avec des ID de programme distincts et des mises en page d’état distinctes.

​
Générations

VersionLancéeStatutFonctionnalités clés
v32021En cours de fermeture. Les fermes existantes s’exécutent ; aucune nouvelle ferme acceptée.Flux de récompense unique. Émission basée sur les slots.
v5Oct 2022En cours de fermeture. Les fermes existantes s’exécutent ; aucune nouvelle ferme acceptée.Jusqu’à 2 flux de récompense. Émission basée sur les slots. Entier per_second.
v62024Actuelle. Toutes les nouvelles fermes.Jusqu’à 5 flux de récompense. Émission horloge murale. Virgule fixe Q64.64 per_second. Support Token-2022 jalonnement + récompense.

​
Pourquoi trois générations existent

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

​
Ce qui reste identique entre les générations

  • Le motif de comptabilité « déposer LP, accumuler compteur par part, 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 changent.
  • UserStake (v3/v5) et UserLedger (v6) sont conceptuellement le même enregistrement, avec des mises en page 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 jalonneurs 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 jalonnement.
  4. Les jalonneurs se rejalonent dans la nouvelle ferme.
La réalité on-chain est deux comptes de ferme sans rapport. Un utilisateur avec jalonnement dans les deux a deux enregistrements UserLedger (v6) / UserStake (v5).

​
Ce que « en cours 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 la cache de « active » mais la garde claimable.
  • 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, config évolutive

LaunchLab 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 verrouillage de 24h — pas comme de nouvelles générations. Ce qui a évolué à travers les mises à niveau :
  • Slot de frais du créateur. Ajouté pour que les lancements puissent router une portion des frais CPMM de trading 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é cross-product que les intégrateurs rencontrent régulièrement :
  • L’instruction SwapV2 de CLMM n’est pas la même que Swap. Si votre client ne parle que Swap, il va silencieusement mal gérer les frais de transfer Token-2022 — les mathématiques sont erronées du montant du frais. Mettez à jour vers SwapV2.
  • Le jalonnement Farm v6 avec les positions CLMM n’est pas soutenu de la même façon que le jalonnement de token 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 jalonnement Token-2022.
  • Les pools AMM v4 ne contiennent 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

Sources :
  • Pages de chapitres par produit citées en ligne ci-dessus.
  • Raydium SDK v2 — la logique de distribution consciente des versions confirme quel programme un pool donné appartient.
  • reference/program-addresses — IDs canoniques par version.