Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Le rôle d’un agrégateur est de proposer au utilisateur le meilleur prix possible sur plusieurs pools, en divisant potentiellement une entrée unique sur plusieurs routes de pool, et l’exécuter de manière atomique. Cette page documente les éléments spécifiques à Raydium : la découverte, les devis, et l’assemblage des transactions.
Découverte
Inventaire des pools
Vous avez besoin de la liste complète des pools Raydium actifs pour chaque produit. Trois options :- API REST (la plus simple) :
GET https://api-v3.raydium.io/pools/info/list?poolType=all&pageSize=1000&page=1retourne les pools par lots de 1000. Paginez jusqu’à les avoir tous. Mettez en cache pendant 1–5 minutes. - Scan on-chain :
getProgramAccountssur les ID de programme CPMM, CLMM et AMM v4, filtrés par le discriminateur du compte d’état. Retourne ~tous les pools actifs en ~10s de temps RPC. Utile quand l’API est indisponible ou limitée en débit. - Hybride : utilisez l’API comme source principale ; exécutez un scan on-chain quotidien comme vérification de cohérence. L’équipe s’engage à maintenir l’API complète, mais les pools créés via CPI direct (sans frontend) peuvent occasionnellement être en retard.
Recherche de paires de mints
Pour une paire(mintA, mintB) spécifique, utilisez GET /pools/info/mint?mint1=...&mint2=...&poolType=all&sort=liquidity. Retourne tous les pools à n’importe quel niveau de frais et type de produit. Jusqu’à ~10 résultats par paire est courant sur les mints bien utilisés ; triez par TVL et prenez les premiers pour le routage.
Devis
Les mathématiques des devis diffèrent par produit. Utilisez les fonctions mathématiques pures du SDK pour ne pas réimplémenter :amountOut (avant slippage) de chacun.
Fraîcheur du cache
L’état du pool devient obsolète rapidement. Cibles de fraîcheur recommandées :
Pour un agrégateur prenant des devis à latence interactive, abonnez-vous aux mises à jour de compte WebSocket (
accountSubscribe) sur chaque état de pool pertinent. Cela bascule le modèle du polling au push.
Ajustements Token-2022
Si un mint dans la route a des frais de transfert Token-2022, les mathématiques du devis doivent ajuster les entrées et sorties selonalgorithms/token-2022-transfer-fees. Le SDK gère cela si poolInfo.mintA.extensions.transferFeeConfig est rempli. Confirmez en regardant le champ .extensions avant de faire confiance au devis.
Routage
Routes à pool unique
La plupart des routes sont à pool unique. Choisissez le pool dontamountOut est le plus élevé. Si plusieurs sont proches, départagez par niveau de frais (plus bas est mieux), puis par TVL (plus est plus sûr).
Routage divisé
Pour les gros trades où un pool unique a >5% d’impact de prix, divisez sur plusieurs pools. Un algorithme glouton simple :[(pool_A, 0.6), (pool_B, 0.3), (pool_C, 0.1)] qui minimise l’impact agrégé. Une solution d’optimisation convexe appropriée (par ex. égaliser les prix marginaux sur les pools) est à ~1% du résultat glouton en pratique.
Routes multi-hop
USDC → RAY → SOL via deux pools séparés est courant quand aucun pool direct USDC-SOL ne donne un bon devis (rare). Appliquez des limites de slippage par hop ; chaque hop applique son propre minAmountOut. Voir algorithms/slippage-and-price-impact.
Multi-hop sur le même pool (par ex. deux hops CLMM sur SOL-USDC) est toujours sous-optimal vs un hop unique — ne générez pas de telles routes.
Assemblage des transactions
Single-hop, single-pool
Pour un pool unique, appelez le constructeur de swap du type de pool —raydium.liquidity.swap, raydium.cpmm.swap ou raydium.clmm.swap. raydium.tradeV2.swap est l’exécuteur de route multi-hop et prend une forme complètement différente ({ swapInfo, swapPoolKeys, routeProgram, ownerInfo, txVersion }); il n’y a pas de raydium.trade.
Divisé et multi-hop
Composez les ATAs + instructions manuellement. Motif :Atomicité
Les agrégateurs doivent garantir l’atomicité : soit la route complète se déploie, soit rien ne se déploie. Les instructions de swap de Raydium reviennent surExceededSlippage, donc une route multi-pool où un hop échoue cause le revert de la transaction entière. Gratuit.
L’une exception : si votre route passe par Raydium + un DEX tiers, assurez-vous que ce DEX a aussi un modèle de revert-on-slippage. Certains programmes ignorent les limites de slippage (rare).
Pièges
1. Devis obsolètes
Entre le moment où l’utilisateur voit « Vous recevez 125.43 RAY » et l’atterrissage de la transaction, les réserves peuvent changer. Re-fetch l’état du pool immédiatement avant la soumission ; re-quote ; si le nouveau devis est >1% pire, pausez et re-confirmez avec l’utilisateur.2. Listes noires de pools
Certains pools Raydium sont des jetons arnaque avec des frais de transfert fixés à 99% ou avec des extensions non transférables. L’API REST les étiquette (voir le champtags) ; ignorez tout pool étiqueté scam ou honeypot. Exécuter vos propres vérifications de sécurité en plus des tags de Raydium est prudent.
3. Exigence d’état d’observation sur CLMM
CLMMSwapV2 prend un compte observation_state. Le SDK le remplit pour vous ; les instructions construites à la main l’oublient souvent, ce qui cause le revert du programme avec AccountNotFound. Incluez-le toujours.
4. Tables de lookup d’adresses
Raydium maintient des tables de lookup publiques pour ses comptes les plus utilisés (mints principaux, ID de programme, AmmConfigs). Les agrégateurs devraient les consommer — cela économise ~100 octets par transaction et permet aux routes plus grandes de tenir en V0. Récupération des adresses LUT :5. Gestion de la congestion
Pendant les fenêtres de haut volume, les transactions peuvent rester dans le mempool pendant plusieurs blocs. La retry agressive sur expiration TX (pas sur revert — les reverts sont déterministes) est recommandée. L’optionsendAndConfirm du SDK fait des retries basiques ; les agrégateurs de production superposent leur propre logique (bundles Jito, broadcast multi-RPC) par-dessus.
Liste de contrôle
Avant de passer en production, vérifiez :- La découverte de pools couvre CPMM + CLMM + AMM v4 de manière complète.
- Les devis correspondent au devis de l’interface Raydium à 1 point de base près sur une poignée de trades de test.
- Le routage divisé s’active pour les trades >5% d’impact sur un pool unique.
- Les frais de priorité sont dimensionnés par rapport aux frais récents du programme de pool (voir
integration-guides/priority-fee-tuning). - Les frais de transfert Token-2022 sont calculés et affichés à l’utilisateur.
- Les transactions reviennent proprement quand le slippage est dépassé.
- La logique de retry distingue l’expiration tx (retry) du revert (ne pas retry).
Pointeurs
integration-guides/routing-and-mev— résistance aux sandwichs, bundles.integration-guides/priority-fee-tuning— dimensionnement des instructions de budget de calcul.sdk-api/rest-api— points de terminaison de liste de pools.

