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 →

​
Installation

npm install @raydium-io/raydium-sdk-v2 @solana/web3.js @solana/spl-token
# ou
pnpm add @raydium-io/raydium-sdk-v2 @solana/web3.js @solana/spl-token
Le SDK est écrit en TypeScript et fournit les fichiers .d.ts aux côtés de son artefact JS. Chaîne d’outils minimale : Node 18+, TypeScript 5.0+, moduleResolution: "bundler" ou "node16".

​
Initialisation

Le point d’entrée est Raydium.load : 
import { Raydium } from "@raydium-io/raydium-sdk-v2";
import { Connection, Keypair, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(process.env.RPC_URL ?? clusterApiUrl("mainnet-beta"));
const owner      = Keypair.fromSecretKey(/* ... */);

const raydium = await Raydium.load({
  owner,
  connection,
  cluster: "mainnet",           // "mainnet" | "devnet"
  disableFeatureCheck: true,    // skip the SDK's startup feature-detect API call
  blockhashCommitment: "confirmed",
});
Raydium.load est asynchrone car elle récupère un petit payload /config auprès de api-v3.raydium.io au démarrage (listant les comptes AmmConfig actuels, les échelons de frais, etc.). Définissez disableFeatureCheck: true dans les environnements hors ligne ; vous devrez fournir manuellement ces valeurs à certains constructeurs.

​
Les quatre façades de module

Une fois chargé, l’objet raydium expose quatre façades de module, une par surface de produit : 
raydium.cpmm       // CPMM pools: createPool, addLiquidity, withdrawLiquidity, swap, ...
raydium.clmm       // CLMM pools: createPool, openPositionFromBase, increasePositionFromBase,
                   //             decreaseLiquidity, harvestAllRewards, swap, ...
raydium.liquidity  // AMM v4 pools: computeAmountOut, swap, addLiquidity, removeLiquidity, ...
raydium.farm       // Farm v3/v5/v6: deposit, withdraw, harvestAllRewards, create, setRewards
raydium.launchpad  // LaunchLab: createLaunchpad, buyExactIn, sellExactIn, graduate, ...
raydium.trade      // Multi-pool routing: quotes, route-execution (beta in 0.2.41)
raydium.token      // Helpers: get token list, metadata, ATA creation
(Oui, cinq façades au total — « quatre » est la manière dont Raydium les groupe publiquement, avec trade et token comme utilitaires de support.)

​
Constructeurs de transactions

Chaque fonction modifiante retourne un constructeur plutôt que de s’exécuter immédiatement : 
const { execute, builder, transaction, innerTransactions, extInfo } =
  await raydium.cpmm.addLiquidity({
    poolInfo,
    amountInA,
    amountInB,
    slippage: 0.005,
    txVersion: TxVersion.V0,
  });
Champs retournés :
  • execute — une fonction de commodité qui signe et envoie. Équivalent à builder.execute.
  • builder — l’instance TxBuilder avec toutes les instructions et les signataires accumulés. Appelez .build() pour obtenir un VersionedTransaction[] ; utile quand vous devez injecter vos propres instructions ou signer avec des signataires externes.
  • transaction / innerTransactions — les tableaux d’instructions brutes. À utiliser pour la construction de transactions multi-programmes composées.
  • extInfo — extras spécifiques au produit. Par exemple, createPool retourne extInfo.poolId ; createLaunchpad retourne la nouvelle PDA d’état de lancement.
txVersion contrôle le format de transaction legacy ou V0. V0 (address lookup tables) est la recommandation par défaut — elle permet aux swaps plus importants de tenir dans une seule transaction.

​
Pourquoi des constructeurs asynchrones ?

Presque chaque constructeur récupère en interne l’état de la chaîne : info du pool (pour les devis), propriété du programme de jetons (pour le routage Token-2022 vs SPL), exonération de loyer du compte (pour la création ATA), etc. Le SDK met en cache agressivement mais le premier appel pour un nouveau pool implique des allers-retours RPC. Conservez une instance raydium longue durée pour éviter de re-récupérer.

​
Ajouts du module CLMM (version la plus récente)

La façade CLMM a acquis des surfaces pour les nouvelles fonctionnalités de frais dynamiques, frais unilatéraux et ordres à limite :
  • raydium.clmm.createCustomizablePool — surensemble de createPool qui accepte collectFeeOn, enableDynamicFee, et dynamicFeeConfigId. Utilisez ceci pour tout nouveau pool qui a besoin des nouveaux contrôles ; le classique createPool continue de fonctionner pour les pools avec frais par défaut.
  • raydium.clmm.openLimitOrder — ouvre un ordre à limite à un seul tick sur un pool qui les supporte. Prend poolInfo, poolKeys, limitOrderConfig (depuis /main/clmm-limit-order-config), inputMint, inputAmount, et le tick cible.
  • raydium.clmm.increaseLimitOrder / decreaseLimitOrder — ajuste la portion non remplie d’un ordre existant. La diminution revient sur un ordre entièrement rempli avec InvalidOrderPhase.
  • raydium.clmm.settleLimitOrder / settleAllLimitOrder — balaye la production remplie vers l’ATA du propriétaire. Soit le propriétaire de l’ordre, soit le gardien limit_order_admin du pool peut les appeler.
  • raydium.clmm.closeLimitOrder / closeAllLimitOrder — ferme les ordres entièrement règlés pour récupérer le loyer.
  • raydium.api.getClmmDynamicConfigs() / getClmmLimitOrderConfigs() — des aides REST qui hit les nouveaux endpoints /main/clmm-dynamic-config et /main/clmm-limit-order-config.
Une petite réorganisation a également déplacé utils/ vers libraries/. Le code qui importait depuis @raydium-io/raydium-sdk-v2/utils/... doit passer à @raydium-io/raydium-sdk-v2/libraries/.... Le barril au niveau supérieur du package est inchangé, donc la plupart des utilisateurs ne voient jamais le renommage. Les procédures pas à pas TypeScript de bout en bout vivent dans products/clmm/code-demos.

​
Pièges courants

​
1. Désaccord de cluster

La config de démarrage du SDK est spécifique au cluster. Mélanger cluster: "mainnet" avec une Connection devnet cause un mal-routage silencieux : le SDK devis contre la AmmConfig mainnet mais envoie vers devnet. Passez toujours les deux.

​
2. Oublier de créer les ATA au préalable

À la première interaction avec un mint, le Compte de Jeton Associé de l’utilisateur peut ne pas exister. Le SDK ajoute automatiquement une instruction AssociatedTokenAccount::create quand il détecte une ATA manquante, ce qui coûte une petite quantité de loyer. Si votre portefeuille a peu de SOL, cela échouera silencieusement. Vérifiez et financez avant de réessayer.

​
3. poolInfo obsolète

poolInfo est un snapshot en cache. Si l’état du pool a changé depuis que vous l’avez récupéré (un grand échange a déplacé le prix, par exemple), le minAmountOut du swap peut être calculé contre l’ancien état et atterrir en dessous du montant-out en chaîne, en révisant. Re-récupérez poolInfo immédiatement avant de construire des transactions de haute valeur, ou utilisez le computeAmountOut du SDK qui re-requête les réserves.

​
4. Frais de priorité

Le SDK n’ajoute pas les prix des unités de calcul par défaut. Dans les fenêtres de haut volume (lancements de nouveaux pools, événements de pièces meme) cela signifie que votre transaction rivalise avec beaucoup d’autres et peut ne pas atterrir. Fournissez un computeBudgetConfig explicite : 
const { execute } = await raydium.cpmm.swap({
  poolInfo,
  inputAmount: new BN(...),
  swapResult: ...,
  slippage: 0.005,
  txVersion: TxVersion.V0,
  computeBudgetConfig: {
    units: 250_000,          // CU limit
    microLamports: 50_000,   // priority fee per CU
  },
});
Voir integration-guides/priority-fee-tuning pour des conseils de dimensionnement.

​
5. La tolérance de slippage doit correspondre au type de pool

CPMM et AMM v4 sont des mathématiques CPMM (faible impact sur les échanges normaux). CLMM est par morceaux (l’impact saute aux croisements de tick). Si vous copiez une tolérance de slippage de 0,5 % d’un exemple CPMM dans un swap CLMM qui traverse plusieurs ticks, la transaction est susceptible de revenir. Le computeAmountOut du SDK retourne priceImpact ; dimensionnez votre tolérance au-dessus.

​
6. BN vs number

Tous les champs de montant dans le SDK sont des instances BN de bn.js — jamais un number JavaScript. La conversion des valeurs de montant via .toNumber() tronque silencieusement à 2^53 ; pour toute valeur au-dessus d’environ 9 quadrillions (pas rare sur les mints à 9 décimales), cela produit le mauvais résultat. Gardez tout en BN jusqu’au rendu UI final.

​
Politique de versioning

  • @raydium-io/raydium-sdk-v2 est le seul SDK que Raydium maintient. Tous les docs, démos et conseils d’intégration le ciblent.
  • Un ancien package v1 (@raydium-io/raydium-sdk) existe sur npm pour des raisons historiques. La maintenance s’est terminée après que CPMM et LaunchLab aient été expédiés (v1 n’a jamais acquis le support pour l’un ou l’autre), et il n’y a eu aucune version v1 depuis 2024. Traitez v1 comme étant en fin de vie : ne l’utilisez pas pour du nouveau code, et migrez toute intégration v1 restante vers v2.
  • Le SDK v2 est pré-1.0. Les changements de rupture entre les versions mineures 0.x sont possibles ; épinglez la version que vous avez vérifiée et vérifiez les notes de publication GitHub lors de la mise à jour.

​
Mise à niveau

Lors de la mise à niveau entre les versions mineures du SDK :
  1. Re-vérifiez le type de retour de chaque appel modifiant — les changements de forme (par ex. extInfo) arrivent fréquemment.
  2. Régénérez les signatures de récupération de poolInfo — un champ peut avoir été renommé.
  3. Re-vérifiez votre gestion du slippage ; le SDK a basculé entre les comportements de liaison auto et de liaison opt-in à travers les versions.
  4. Si vous utilisez raydium.trade (routage), re-vérifiez la forme de la route — c’est la partie la plus instable de la surface.

​
Obtenir de l’aide

Pour les questions sur le SDK et l’API : Pour les problèmes de sécurité, ne publiez pas dans les canaux publics — voir security/disclosure.

​
Pointeurs

Sources :