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 →

​
Résumé en un paragraphe

Le programme de routage AMM regroupe les swaps multi-sauts en une seule transaction on-chain qui enchaîne la liquidité entre les pools. Vous fournissez une route (une liste de pools et de mints intermédiaires) et une instruction avec des paramètres de slippage ; le routeur exécute tous les N sauts dans l’ordre, déplaçant la sortie d’un pool vers l’entrée du suivant. Aucune logique de routeur on-chain séparée n’est nécessaire pour le calcul des prix — chaque saut traite ses frais et sa courbe via son propre programme de pool par CPI — mais le routeur orchestre le passage des comptes et le mouvement des tokens.

​
Pourquoi un programme routeur séparé ?

Les clients Raydium et les agrégateurs peuvent toujours assembler les swaps multi-sauts côté client sans utiliser le routeur : construire N instructions de swap (une par pool) et les soumettre dans une seule transaction. Pourquoi, alors, avoir un programme routeur dédié ?

​
Raisons d’utiliser le routeur

  1. CPI depuis d’autres programmes. Si votre propre programme doit invoquer une route dans le cadre d’une transaction plus grande (par exemple, un gestionnaire de liquidité qui échange des frais pour un token cible), faire un CPI dans le routeur est plus propre que de regrouper N CPIs enfants et de gérer tous leurs comptes dans votre contrat.
  2. État atomique des comptes. Chaque liste de comptes du saut est validée dans un contexte d’instruction. Si l’état d’un pool intermédiaire est corrompu ou qu’une assertion de limite de prix échoue, toute la route échoue de manière atomique sans règlement partiel.
  3. Composition d’une seule instruction. Les SDKs et les interfaces peuvent représenter une route multi-sauts comme une seule opération logique, et non comme N instructions séparées qui se succèdent simplement.

​
L’assemblage côté client reste la norme

Pour la plupart des applications, construire des instructions Swap séparées pour chaque pool et les soumettre dans l’ordre est plus simple, plus composable et tout aussi valide. Le flux Trade.makeSwapTransaction du SDK Raydium et d’autres similaires fonctionnent exactement comme cela pour la plupart des routes. Le routeur est une alternative, pas un remplacement. Utilisez-le quand :
  • Vous implémentez un programme qui doit faire du routage dans le cadre d’une opération atomique plus large.
  • Vous construisez un agrégateur qui veut une seule opération « soumettre cette route ».

​
Comment ça marche

Une instruction du routeur transporte :
  • Arguments de swap : entrée exacte (amount_in, minimum_amount_out) ou sortie exacte (maximum_amount_in, amount_out).
  • Spécification de la route : une liste de program_id + comptes du programme enfant pour chaque saut, dans l’ordre. Le routeur lit le premier compte de chaque groupe de saut pour déterminer quel programme invoquer.
  • Limites de prix (pour CLMM) : une VecDeque<u128> de limites sqrt_price_x64. Utilisée uniquement pour les sauts dans les pools CLMM ; une deque vide est une erreur pour les variantes d’instructions plus anciennes.
Le routeur procède ensuite ainsi :
  1. Exécute le premier saut : transfère amount_in (ou calcule l’entrée requise pour une sortie exacte) au coffre-fort d’entrée du premier pool, invoque le swap de ce pool, et collecte la sortie.
  2. Enchaîne les sauts suivants : pour chaque saut N, utilise la sortie du saut N−1 comme entrée du saut N.
  3. Applique le slippage : à chaque saut CLMM, vérifie sqrt_price par rapport au limit_price correspondant ; au saut final, vérifie la sortie totale par rapport au minimum_amount_out global.
Les tokens intermédiaires peuvent circuler soit par ATAs contrôlés par l’utilisateur (un par saut, plus lent mais transparent), soit par un compte dérivé d’une PDA partagée (une adresse pour tous les sauts, plus rapide, opaque).

​
Délégation du calcul des prix et des frais

Le routeur ne calcule pas les prix lui-même. Chaque saut délègue à la courbe du programme enfant :
  • AMM v4 : utilise la formule de produit constant avec le pricing hybride OpenBook.
  • CPMM : utilise la formule de produit constant avec l’échelon de frais configuré.
  • CLMM : utilise les mathématiques de liquidité concentrée avec le pricing basé sur les ticks.
  • Stable : utilise la courbe stable-swap pour les tokens de même nature.
Les frais sont facturés par chaque pool selon sa propre configuration. Le routeur n’applique aucun frais qui lui serait propre.

​
Quand éviter le routeur

  • Faible nombre de sauts (1–2 sauts). Les frais généraux du passage des comptes sont minimes ; utilisez simplement deux instructions de swap séparées.
  • Pools autres que Raydium. Le routeur ne connaît que les quatre types de pools Raydium. Pour les routes qui traversent des programmes externes, assemblez les instructions côté client.
  • Routage conditionnel. Si vous devez brancher selon les prix ou les états des pools au milieu de la route, le routage on-chain est moins flexible que la composition côté client.

​
Modèle mental

Pensez au routeur comme une utilitaire d’empaquetage de transactions. Il prend votre spécification de route et l’empaquette dans une instruction, une transaction, un budget de calcul. Chaque saut fait un CPI en interne dans son programme de pool et gère les mathématiques de la courbe à cet endroit. Le travail du routeur est de passer les comptes correctement, de déplacer les tokens entre les sauts, et de vérifier le slippage.

​
Où aller ensuite