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, par défaut, elle charge la liste des jetons (raydium.token.load()) depuis api-v3.raydium.io. Passez disableLoadToken: true pour éviter cette requête. La vérification de disponibilité des fonctionnalités est un appel distinct à /v3/main/AvailabilityCheckAPI et est déjà ignorée sauf si vous passez explicitement disableFeatureCheck: false. Les configurations de frais ne sont pas du tout récupérées au chargement — elles proviennent paresseusement de raydium.api.getCpmmConfigs() / getClmmConfigs() à la première utilisation.

Les façades de modules

Une fois chargé, l’objet raydium expose dix façades de modules plus un client d’API :

raydium.cpmm       // Pools CPMM : createPool, addLiquidity, withdrawLiquidity, swap, ...
raydium.clmm       // Pools CLMM : createPool, openPositionFromBase, increasePositionFromBase,
                   //             decreaseLiquidity, harvestAllRewards, swap, limit orders, ...
raydium.liquidity  // Pools AMM v4 : computeAmountOut, swap, addLiquidity, removeLiquidity, ...
raydium.farm       // Farm v3/v5/v6 : deposit, withdraw, harvestAllRewards, create,
                   //                restartReward(s), addNewRewardToken(s)
raydium.launchpad  // LaunchLab : createLaunchpad, buyToken, buyTokenExactOut, sellToken,
                   //            claimCreatorFee, constructeurs de curve-rule et de platform-config, ...
raydium.tradeV2    // Routage multi-pool : découverte de route, compute, route-execution
raydium.marketV2   // Création de marché OpenBook (héritée)
raydium.utils1216  // Assistants ponctuels de réclamation historique
raydium.token      // Liste de jetons + métadonnées : load(), getTokenInfo()
raydium.account    // Comptes de jetons du portefeuille, recherche et création d'ATA
raydium.api        // Le client REST (fetchPoolById, getCpmmConfigs, fetchLaunchConfigs, ...)

Constructeurs de transactions

Chaque fonction mutante retourne un constructeur plutôt que d’exécuter immédiatement :

import { Percent } from "@raydium-io/raydium-sdk-v2";

const { execute, builder, transaction, instructionTypes, signers, extInfo } =
  await raydium.cpmm.addLiquidity({
    poolInfo,
    inputAmount,              // BN — one side, not a pair
    baseIn: true,
    slippage: new Percent(1, 100),   // a Percent, not a number
    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 tous les signataires accumulés. builder.build() retourne un TxBuildData dont la transaction est une unique Transaction héritée ; builder.buildV0() retourne un TxV0BuildData avec une unique VersionedTransaction. Seuls buildMultiTx / buildMultiTxV0 produisent un tableau.
transaction — la Transaction / VersionedTransaction construite.
instructionTypes / signers — les étiquettes d’instructions et l’ensemble de signataires accumulés.
extInfo — extras spécifiques au produit. Par exemple, cpmm.createPool retourne extInfo.address.{poolId, lpMint, vaultA, vaultB} ; launchpad.createLaunchpad retourne extInfo.address (un LaunchpadPoolInfo plus poolId).

Il n’existe aucun champ innerTransactions sur le type de retour — le déstructurer est une erreur TypeScript. Les constructeurs dont le type de retour est MakeMultiTxData (par exemple clmm.harvestAllRewards, farm.harvestAllRewards, tradeV2.swap, launchpad.createLaunchpad) exposent transactions à la place, et leur execute exige { sequentially: boolean } et se résout en { txIds } plutôt qu’en { txId }.

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 et dynamicFeeConfig (la PublicKey du compte de configuration). C’est le fait de fournir dynamicFeeConfig qui active les frais dynamiques ; il n’existe pas de drapeau enableDynamicFee distinct, ni de dynamicFeeConfigId. Le createPool classique continue de fonctionner pour les pools à frais par défaut.
raydium.clmm.openLimitOrder — ouvrir un ordre limite à un seul tick. Prend poolInfo, baseIn (direction), orderTick, amount, et éventuellement tickArrayBitmap, noneIndex, ownerInfo. Utilisez l’assistant exporté getOrderTick({ baseIn, mintADecimal, mintBDecimal, tickSpacing, price }) pour quantifier le tick.
raydium.clmm.increaseLimitOrder / decreaseLimitOrder — ajuster la portion non remplie d’un ordre existant. Les deux prennent { poolInfo, limitOrder, amount } ; decreaseLimitOrder ajoute un slippage optionnel. 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. settleLimitOrder ne prend que { limitOrder } — pas de poolInfo. Soit le propriétaire de l’ordre, soit le gardien limit_order_admin du programme peuvent l’appeler.
raydium.clmm.closeLimitOrder / closeAllLimitOrder — fermer les ordres entièrement réglés pour récupérer le loyer.
raydium.api.getClmmDynamicConfigs() — assistant REST qui frappe le nouveau point de terminaison /main/clmm-dynamic-config. (Il n’existe ni assistant ni point de terminaison de configuration d’ordre limite : les ordres limites sont indexés par tick, et non par un compte de configuration par pool.)

Le paquet ne déclare aucun export de sous-chemin, donc @raydium-io/raydium-sdk-v2/<anything> ne se résout dans aucune orthographe — importez tout depuis le barrel de premier niveau. (En interne, src/raydium/clmm/utils/ a été renommé en src/raydium/clmm/libraries/, mais cela n’a jamais été un point d’entrée public.) 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,
  baseIn,                    // required: which side inputAmount is denominated in
  inputAmount: new BN(...),
  swapResult: ...,           // required: from CurveCalculator.swapBaseInput/Output
  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.tradeV2 (routage), re-vérifiez la forme de la route — c’est la partie la plus instable de la surface. Notez que la façade a été renommée de trade en tradeV2 ; l’ancien nom n’existe plus.

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 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 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 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