Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →

​
Le routeur n’effectue aucun calcul

Le programme de routage n’implémente aucune logique de tarification. C’est un pur orchestrateur : il accepte une route, transmet les comptes aux programmes enfants et enchaîne les flux de jetons. Chaque saut détermine son prix selon la courbe de son propre programme de pool :
  • Sauts AMM v4 : utilisent la formule de produit constant (x · y = k) avec la tarification hybride OpenBook. Voir products/amm-v4/math.
  • Sauts CPMM : utilisent la formule de produit constant avec des niveaux de frais configurables. Voir products/cpmm/math.
  • Sauts CLMM : utilisent les mathématiques de tick de liquidité concentrée. Voir algorithms/clmm-math.
  • Sauts stables : utilisent la courbe stable-swap pour les actifs de même nature. Voir products/stable/math.
L’implication du routeur se limite à :
  1. Appeler l’instruction de swap de chaque pool via CPI.
  2. Collecter le montant de sortie.
  3. Le transmettre comme montant d’entrée au saut suivant.
  4. Vérifier la sortie finale par rapport à la limite de slippage de l’appelant.

​
Composition du slippage

Sur une route multi-saut, le slippage à chaque saut se compose. Un petit slippage au saut 1 devient un slippage plus important au saut 2 car le volume entrant au saut 2 est déjà réduit. Exemple :
Lorsque vous fournissez minimum_amount_out, le routeur vérifie votre sortie finale par rapport à cette limite globale. Chaque saut vérifie également son propre swap par rapport à sa structure de frais locale, mais le routeur ne re-cite pas en cours de route — vous devez pré-calculer la route et intégrer une tolérance de slippage suffisante.

​
Sauts CLMM et limit_prices

Pour chaque saut dans un pool CLMM, le routeur vérifie que le sqrt_price_x64 actuel du pool se situe dans une limite spécifiée. Les limites sont transmises sous forme de VecDeque<u128> appelée limit_prices :
  • Un sqrt_price_x64 par saut CLMM dans la route.
  • sqrt_price_x64 est la représentation de prix basée sur les ticks utilisée par CLMM. Voir algorithms/clmm-math pour la définition.
  • Le routeur applique :
pour chaque saut CLMM, rejetant le swap si le prix est hors limites.

​
Variantes d’instruction et limit_prices

  • SwapBaseInWithUserAccount, SwapBaseOutWithUserAccount (Hérité, tags 0 et 1) : la VecDeque limit_prices est requise. Une deque vide est rejetée avec une erreur si un saut est un pool CLMM. Vous devez fournir un prix par saut CLMM, dans l’ordre.
  • SwapBaseIn, SwapBaseOut (Actuel, tags 8 et 9) : la VecDeque limit_prices est optionnelle. Une deque vide est silencieusement ignorée ; aucune vérification de prix n’est effectuée. Le nouveau code devrait utiliser ceux-ci.

​
Construction de limit_prices

Pour une route avec M sauts CLMM, la deque doit contenir exactement M entrées. Ordonnez-les par saut :

​
Quand vérifier limit_prices

Le sqrt_price_x64 est un instantané du prix actuel du pool. Il change continuellement à mesure que les swaps s’exécutent. Vous devriez :
  1. Récupérer l’état actuel du pool depuis la chaîne.
  2. Calculer les limites acceptables (par exemple, ±0,5 % du prix actuel).
  3. Encoder ces limites dans limit_prices.
  4. Inclure les limites dans votre instruction de routeur.
Si le prix du pool dépasse vos limites avant que la transaction ne soit validée, le routeur la rejettera.

​
Gestion des frais

Chaque pool facture ses propres frais selon sa configuration :
  • AMM v4 : 0,25 % (fixe) répartis entre LP, protocole et fonds.
  • CPMM : configurable par AmmConfig (par défaut 0,25 %, la répartition varie selon le niveau).
  • CLMM : configurable par pool, prélevé sur le montant d’entrée.
  • Stable : 0,02 % (fixe), répartis 88 % LP / 12 % protocole.
Le routeur ne prélève aucun frais propre. Toute la gestion des frais est déléguée à chaque pool enfant. La sortie du saut N a déjà les frais de ce saut déduits. Consultez la documentation des frais du pool individuel :

​
Exemple de comptabilité multi-saut

Supposons que vous routez USDC → SOL → STEP sur deux pools de produit constant, chacun avec un frais de 0,25 % :
Le routeur vérifie :
Si faux, toute la route échoue de manière atomique.

​
Considérations de précision

Comme tous les programmes Solana, le routeur utilise l’arithmétique entière :
  • Tous les montants sont u64 (lamports ou plus petites unités de jeton).
  • Les calculs de courbe utilisent des intermédiaires u128 si nécessaire pour éviter le débordement.
  • Les conventions d’arrondi dépendent du programme enfant. Le routeur ne re-arrondit pas.
Si un saut produit un montant zéro en raison de ratios de prix extrêmes (par exemple, échanger 1 lamport sur un pool 1B:1), le routeur propage ce zéro au saut suivant, qui peut alors le rejeter comme insuffisant. Consultez les codes d’erreur du pool individuel.

​
Où aller ensuite