SDK TypeScript

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

Banneau de version. Cette page documente @raydium-io/raydium-sdk-v2@0.2.64-alpha, la version épinglée que chaque démo de code sur ce site utilise. Le SDK est pré-1.0 et la surface des types a évolué entre les versions — épinglez votre version.L’épingle a été avancée de 0.2.42-alpha le 2026-09-09 aux côtés des mises à niveau du programme : 0.2.64-alpha est la version actuelle du SDK. Le dépôt raydium-sdk-V2-demo vers lequel les pages de démo de code renvoient installe 0.2.62-alpha, donc épinglez l’une ou l’autre si vous suivez une démo à la lettre. Les démos sur ces pages ont été exécutées pour la dernière fois contre 0.2.42-alpha (2026-04) ; leurs signatures d’appel ont été revérifiées contre la source 0.2.64-alpha le 2026-09-09, mais traitez toute divergence comme un bug de documentation et ouvrez un problème.

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 .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 une petite charge utile /config depuis api-v3.raydium.io au démarrage (listant les comptes AmmConfig actuels, les niveaux de frais, etc.). Définissez disableFeatureCheck: true dans les environnements hors ligne ; vous devrez fournir ces valeurs manuellement à certains constructeurs.

Les quatre façades de modules

Une fois chargé, l’objet raydium expose quatre façades de modules, une par surface de produit :

raydium.cpmm       // Pools CPMM : createPool, addLiquidity, withdrawLiquidity, swap, ...
raydium.clmm       // Pools CLMM : createPool, openPositionFromBase, increasePositionFromBase,
                   //             decreaseLiquidity, harvestAllRewards, swap, ...
raydium.liquidity  // Pools AMM v4 : computeAmountOut, swap, addLiquidity, removeLiquidity, ...
raydium.farm       // Farm v3/v5/v6 : deposit, withdraw, harvestAllRewards, create, setRewards
raydium.launchpad  // LaunchLab : createLaunchpad, buyExactIn, sellExactIn, graduate, ...
raydium.trade      // Routage multi-pool : quotes, route-execution (bêta en 0.2.41)
raydium.token      // Assistants : obtenir la liste des jetons, métadonnées, création d'ATA

(Oui, cinq façades au total — « quatre » est la façon dont Raydium les groupe publiquement, avec trade et token comme utilitaires de support.)

Constructeurs de transactions

Chaque fonction mutante retourne un constructeur plutôt que d’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 + 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 lors de la construction de transactions multi-programmes composées.
extInfo — extras spécifiques au produit. Par exemple, createPool retourne extInfo.poolId ; createLaunchpad retourne le PDA du nouvel état de lancement.

txVersion contrôle le format de transaction hérité par rapport à V0. V0 (tables de recherche d’adresses) est la recommandation par défaut — elle permet aux swaps plus importants de tenir dans une seule transaction.

Pourquoi les constructeurs asynchrones ?

Presque chaque constructeur récupère en interne l’état on-chain : les informations du pool (pour les devis), la propriété du programme de jetons (pour le routage Token-2022 vs SPL), l’exemption de loyer du compte (pour la création d’ATA), etc. Le SDK met en cache de manière agressive 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 (dernière version)

La façade CLMM a acquis des surfaces pour les nouvelles fonctionnalités de frais dynamiques, frais unilatéraux et ordres limites :

raydium.clmm.createCustomizablePool — sur-ensemble de createPool qui accepte collectFeeOn, enableDynamicFee, et dynamicFeeConfigId. Utilisez ceci pour tout nouveau pool qui a besoin des nouveaux paramètres ; le createPool classique continue de fonctionner pour les pools à frais par défaut.
raydium.clmm.openLimitOrder — ouvrir 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 — ajuster la portion non remplie d’un ordre existant. La diminution revient sur un ordre entièrement rempli avec InvalidOrderPhase.
raydium.clmm.settleLimitOrder / settleAllLimitOrder — balayer la sortie remplie vers l’ATA du propriétaire. Soit le propriétaire de l’ordre, soit le gardien limit_order_admin du pool peuvent les appeler.
raydium.clmm.closeLimitOrder / closeAllLimitOrder — fermer les ordres entièrement réglés pour récupérer le loyer.
raydium.api.getClmmDynamicConfigs() / getClmmLimitOrderConfigs() — assistants REST qui frappent les nouveaux points de terminaison /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/... devrait passer à @raydium-io/raydium-sdk-v2/libraries/.... Le baril du package de haut niveau est inchangé, donc la plupart des utilisateurs ne voient jamais le renommage. Les procédures pas à pas TypeScript de bout en bout se trouvent dans products/clmm/code-demos.

Pièges courants

1. Décalage de cluster

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

2. Oublier de pré-créer les ATA

Lors de la première interaction avec un mint, le compte de jeton associé de l’utilisateur peut ne pas exister. Le SDK pré-ajoute automatiquement une instruction AssociatedTokenAccount::create quand il détecte un ATA manquant, ce qui coûte une petite quantité de loyer. Si votre portefeuille est faible en SOL, cela échouera silencieusement. Vérifiez et financez avant de réessayer.

3. `poolInfo` obsolète

poolInfo est un instantané mis 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é par rapport à l’ancien état et tomber en dessous du montant de sortie on-chain, revenant. Re-récupérez poolInfo immédiatement avant de construire des transactions de grande valeur, ou utilisez le computeAmountOut du SDK qui re-interroge les réserves.

4. Frais de priorité

Le SDK n’ajoute pas de prix d’unité de calcul par défaut. Dans les fenêtres de volume élevé (lancements de nouveaux pools, événements de pièces mèmes), cela signifie que votre transaction entre en concurrence avec beaucoup d’autres et peut ne pas arriver. 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
  },
});

Consultez integration-guides/priority-fee-tuning pour les 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 ticks). 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 JavaScript number. Convertir les 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 final de l’interface utilisateur.

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 obtenu le support pour l’un ou l’autre), et il n’y a eu aucune version v1 depuis 2024. Traitez v1 comme fin de vie : ne l’utilisez pas pour le 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 consultez les notes de version GitHub lors de la mise à niveau.

Mise à niveau

Lors de la mise à niveau entre les versions mineures du SDK :

Re-vérifiez le type de retour de chaque appel mutant — les changements de forme (par exemple extInfo) arrivent fréquemment.
Régénérez les signatures de récupération poolInfo — un champ peut avoir été renommé.
Re-vérifiez votre gestion du slippage ; le SDK a basculé entre les comportements de liaison automatique et de liaison opt-in entre les versions.
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 :

Problèmes GitHub — déposez à github.com/raydium-io/raydium-sdk-V2/issues pour les bugs et les demandes de fonctionnalités. L’équipe Raydium surveille activement.
Discord — canal #dev-support à discord.gg/raydium pour l’aide synchrone.
Telegram — chat développeur lié depuis raydium.io (évitez les groupes Telegram non vérifiés).

Pour les problèmes de sécurité, ne postez pas dans les canaux publics — consultez security/disclosure.

Pointeurs

sdk-api/rest-api — le complément HTTP du SDK.
sdk-api/trade-api — transactions de swap construites par serveur.
sdk-api/anchor-idl — régénération des clients directement à partir des IDL de programme.
sdk-api/python-integration — équivalent Python via solana-py.
integration-guides/priority-fee-tuning — dimensionnement de computeBudgetConfig.

Sources :

Source Raydium SDK v2
Notes de version Raydium SDK.

Fondamentaux Solana

Démarrage rapide

SDK & API

Guides d'intégration

Installation

Initialisation

Les quatre façades de modules

Constructeurs de transactions

Pourquoi les constructeurs asynchrones ?

Ajouts du module CLMM (dernière version)

Pièges courants

1. Décalage de cluster

2. Oublier de pré-créer les ATA

3. `poolInfo` obsolète

4. Frais de priorité

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

6. `BN` vs `number`

Politique de versioning

Mise à niveau

Obtenir de l’aide

Pointeurs

​Installation

​Initialisation

​Les quatre façades de modules

​Constructeurs de transactions

​Pourquoi les constructeurs asynchrones ?

​Ajouts du module CLMM (dernière version)

​Pièges courants

​1. Décalage de cluster

​2. Oublier de pré-créer les ATA

​3. poolInfo obsolète

​4. Frais de priorité

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

​6. BN vs number

​Politique de versioning

​Mise à niveau

​Obtenir de l’aide

​Pointeurs

Installation

Initialisation

Les quatre façades de modules

Constructeurs de transactions

Pourquoi les constructeurs asynchrones ?

Ajouts du module CLMM (dernière version)

Pièges courants

1. Décalage de cluster

2. Oublier de pré-créer les ATA

3. `poolInfo` obsolète

4. Frais de priorité

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

6. `BN` vs `number`

Politique de versioning

Mise à niveau

Obtenir de l’aide

Pointeurs