Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Cette page est le diagramme d’architecture canonique de la documentation. Tous les autres chapitres y renvoient plutôt que de redessiner le système. Les ID de programme ne sont pas intégrés dans cette page — ils se trouvent dans reference/program-addresses pour pouvoir être mis à jour en un seul endroit.

​
Ce que Raydium est réellement

Raydium n’est pas un seul programme. C’est un ensemble de programmes Solana on-chain indépendants qui partagent une surface off-chain commune (API REST, SDK TypeScript, registre IDL) et quelques conventions (PDAs d’autorité, comptes de configuration des frais, multisig administratif). Une interaction utilisateur — un swap, un dépôt, une récolte de ferme — s’achemine vers exactement l’un de ces programmes ; la surface off-chain est ce qui les fait ressembler à un seul produit. L’empreinte on-chain se divise en quatre types de programmes :
  1. Programmes AMM — quatre programmes de pool distincts, chacun avec son propre format et sa propre mathématique de tarification :
    • AMM v4 — l’AMM constant-product original. Initialement une conception hybride qui reflétait la courbe sur un marché OpenBook (anciennement Serum) ; l’intégration OpenBook a depuis été désactivée et les pools fonctionnent maintenant comme des AMMs purs par rapport à la courbe. Toujours le lieu le plus profond pour de nombreuses paires majeures.
    • CPMM — un AMM constant-product simple (x · y = k) construit nativement sur Solana, avec support de Token-2022 de première classe. Le programme recommandé pour les nouveaux pools constant-product.
    • CLMM — un AMM à liquidité concentrée dans le style Uniswap v3. La liquidité est fournie dans des plages de prix ; les frais s’accumulent par position ; l’état est organisé autour des ticks et d’un sqrt_price_x64.
    • Stable AMM — un programme StableSwap-style à liquidité fine (forké d’AMM v4 avec une courbe de tarification par table de recherche) que le routeur utilise pour les paires corrélées aux stablecoins. Non exposé comme une option de création de pool de première classe dans l’interface utilisateur aujourd’hui.
  2. Distribution des récompenses — Farm (v3 / v5 / v6, avec v6 comme génération active ; v3/v5 sont en phase de fermeture uniquement).
  3. Lancement de token — LaunchLab, un programme de courbe de liaison. Les lancements nouvellement initialisés graduent vers CPMM. L’instruction de migration AMM v4 héritée reste pour l’état de lancement existant.
  4. Primitives de liquidité — AMM Routing (le routeur multi-pool on-chain qui CPI dans les quatre programmes AMM en une seule transaction) et LP-Lock / Burn & Earn (verrouille les positions LP tout en gardant les réclamations de frais ouvertes).
Tout le reste de la pile — les API REST, l’API Transaction, le SDK TypeScript, l’interface utilisateur — est une infrastructure off-chain qui compose ces programmes au-dessus de Solana et SPL Token / Token-2022. La surface Perps est une intégration séparée au-dessus d’Orderly Network et n’est pas un programme Raydium on-chain ; elle est exclue de ce diagramme.

​
Diagramme canonique

Les invariants clés que ce diagramme capture :
  • Les programmes AMM sont des pairs. CPMM n’appelle pas CLMM ; CLMM n’appelle pas AMM v4 ; Stable AMM est son propre programme. Un swap direct sur un pool touche exactement un programme AMM. Le seul programme qui compose plusieurs AMMs en une seule transaction est AMM Routing, qui CPI dans AMM v4 / CPMM / CLMM / Stable AMM selon les besoins quand une route traverse les types de pool.
  • Le SDK et l’API Transaction sont des couches de composition, pas des programmes. Quand l’interface web ou un agrégateur construit une transaction « swap à travers trois pools », le SDK (côté client) ou l’API Transaction (côté serveur) assemble les instructions en utilisant des devis récupérés de l’API REST. La chaîne voit une seule transaction Solana avec N instructions — aucun programme orchestrateur ne possède le flux entier.
  • Le câblage OpenBook d’AMM v4 est inerte. AMM v4 était le seul AMM jamais lié à OpenBook, mais l’intégration a été désactivée — les pools ne partagent plus la liquidité avec OpenBook, MonitorStep n’est plus cranké, et une panne OpenBook n’a aucun impact sur le trafic de swap actuel. Les comptes de marché restent sur le AmmInfo du pool pour la compatibilité rétroactive mais font référence à un état inutilisé. CPMM, CLMM et Stable AMM n’ont jamais eu de dépendance CLOB.
  • Les nouveaux pools LaunchLab graduent vers CPMM. L’initialisation nécessite maintenant migrate_type = CPSWAP. MigrateToAmm reste pour l’état hérité existant. Avant la mise à niveau du 2026-08-17, la migration CPMM verrouillait creator_scale séparément pour le créateur. Les migrations exécutées après combinent cela avec platform_scale en une seule position LP verrouillée appartenant à la plateforme. Les clés de frais antérieures restent inchangées.
  • LP-Lock est un wrapper, pas un cinquième AMM. Il détient les positions LP au nom des créateurs sous une PDA afin que les frais sous-jacents puissent toujours être réclamés sans exposer la capacité à retirer la liquidité. Il compose sur les pools CPMM et CLMM.
  • Les surfaces off-chain se complètent. L’API REST est en lecture seule avec mise en cache ; l’API Transaction construit des transactions prêtes à signer côté serveur ; le SDK les construit côté client. Les trois dépendent du même registre IDL comme source de vérité du schéma.

​
Flux de données : un swap CPMM, de bout en bout

Pour rendre le tableau concret, voici ce qui se passe quand un utilisateur échange USDC → RAY sur un pool CPMM depuis l’interface Raydium. (AMM v4 et CLMM diffèrent dans les comptes dont ils ont besoin, pas dans la forme de haut niveau.)
  1. Demande de devis (off-chain). L’interface appelle GET https://api-v3.raydium.io/compute/swap-base-in avec le mint d’entrée, le mint de sortie, le montant et une tolérance de slippage. L’API consulte son indexeur, choisit une route (possiblement à travers plusieurs pools) et retourne un devis plus la liste des ID de programme, des ID de pool et des comptes de frais dont le client aura besoin.
  2. Construction de transaction (client + SDK). Le client transmet le devis à raydium-sdk-v2. Le SDK résout chaque PDA dont il a besoin (PDA d’autorité, état du pool, observation, vaults — voir products/cpmm/accounts), injecte les comptes de token associés de l’utilisateur (les créant avec le programme Associated Token si manquants) et émet une Transaction non signée.
  3. Signature du portefeuille. Le portefeuille de l’utilisateur signe la transaction. Rien de spécifique à Raydium ici ; c’est le flux de portefeuille Solana standard.
  4. Exécution on-chain. La transaction signée atteint le programme CPMM de Raydium, qui (a) valide l’état du pool, (b) applique la courbe constant-product avec la configuration des frais du pool, (c) déplace les tokens entre les ATAs de l’utilisateur et les vaults du pool via CPI dans SPL Token / Token-2022, (d) met à jour le compte observation pour le TWAP, et (e) retourne.
  5. Ingestion de l’indexeur. Le RPC Solana quelques slots plus tard expose les journaux du programme. L’indexeur de Raydium les analyse, met à jour les réserves du pool, le volume 24h et l’APR, et sert les valeurs mises à jour à la prochaine demande /pools/info/ids.
Les quatre étapes 2–4 se produisent dans une seule transaction Solana. L’API n’est impliquée que dans l’étape 1 (devis) et l’étape 5 (indexation pour la prochaine fois). Si l’API est hors ligne, un client avec un SDK actif et un RPC Solana peut toujours effectuer des transactions — il doit juste calculer la route lui-même.

​
Infrastructure partagée

Plusieurs primitives sont utilisées par chaque produit et méritent d’être nommées une fois pour que les chapitres ultérieurs puissent y faire référence sans redéfinition. Les détails se trouvent dans protocol-overview/shared-infrastructure ; ceci est l’index.

​
Surface off-chain : API vs SDK vs IDL

Ces trois sont régulièrement confondus. Ils font des choses différentes :
  • API REST (api-v3.raydium.io) est une vue en lecture seule, mise en cache de l’état on-chain plus le moteur de devis. Elle vous dit quels pools existent, quelles sont leurs réserves, comment les APRs se présentent et quelle est la meilleure route pour un swap. Elle ne construit pas les transactions.
  • SDK TypeScript (@raydium-io/raydium-sdk-v2) est un constructeur de transactions. Il connaît la disposition de chaque compte de programme et le format d’instruction. Il récupère l’état frais d’un RPC (pas de l’API) avant de composer une instruction, afin qu’il puisse signer des transactions précises. Il parle à l’API uniquement quand il a besoin d’un devis.
  • Registre IDL est le schéma sur lequel les deux ci-dessus dépendent. Si vous écrivez des CPIs Rust dans un programme Raydium, l’IDL est le contrat ; si vous écrivez une intégration TS, vous utilisez les IDLs indirectement via le SDK.

​
Où chaque chapitre s’inscrit

Le diagramme ci-dessus réapparaît — sous forme réduite — tout au long de la documentation. Voici où se trouve le traitement complet de chaque pièce pour que vous puissiez approfondir :
  • Programmes on-chain : un chapitre par produit sous products/. Chaque chapitre suit le même modèle (aperçu → comptes → mathématiques → instructions → frais → démos de code).
  • Primitives partagées entre programmes : protocol-overview/shared-infrastructure et algorithms/ pour les mathématiques qui réapparaissent (constant-product, liquidité concentrée, tarification de courbe).
  • Surface off-chain : sdk-api/ a la référence complète du SDK et de l’API REST, plus sdk-api/anchor-idl et sdk-api/rust-cpi.
  • Flux au niveau utilisateur (créer un pool, swapper, LP, réclamer des récompenses, lancer un token) : user-flows/.
  • Modèles d’intégration pour d’autres équipes (agrégateurs, portefeuilles, bots) : integration-guides/.
  • Surface de sécurité, clés administrateur, risques connus, audits : security/.
  • Changements versionnés et l’histoire de migration AMM v4 → CPMM / Farm v3 → v6 : protocol-overview/versions-and-migration.

​
Non-objectifs de ce diagramme

Quelques omissions délibérées, pour que personne ne lise plus que ce qui y est :
  • Pas d’oracles de prix. Raydium ne dépend pas de Pyth, Switchboard ou d’un oracle externe pour sa tarification AMM de base. Les devis proviennent des réserves on-chain. Le compte observation existe pour que d’autres contrats puissent lire un TWAP Raydium — Raydium lui-même n’en a pas besoin.
  • Pas de programme de vote de token on-chain. Les actions administrateur telles que les mises à jour de configuration des frais et les mises à niveau de programme sont exécutées par un multisig. Les clés multisig et la politique de rotation se trouvent dans security/admin-and-multisig.
  • Pas de ponts. Raydium est natif à Solana. Les flux inter-chaînes sont le problème de l’intégrateur et se trouvent en dehors de ce diagramme.
Sources :