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 →

​
Qu’est-ce qu’un IDL

Les programmes Anchor sur Solana publient un fichier IDL (Interface Definition Language) qui décrit leurs instructions, structures de comptes, énumérations d’erreurs et schémas de structures. L’IDL est la source de vérité pour la génération de code client — le SDK TS, la crate CPI Rust et les clients tiers sont tous générés à partir de celui-ci (ou écrits manuellement selon ses spécifications). Raydium publie des IDLs pour CPMM, CLMM et LaunchLab. AMM v4, Stable AMM et Farm (v3 / v5 / v6) sont antérieurs à Anchor ou ne sont pas distribués via Anchor — leurs structures de comptes sont maintenues manuellement dans le SDK.

​
Où les trouver

Les IDLs vivent dans un dépôt dédié : 
https://github.com/raydium-io/raydium-idl
Les fichiers exacts :
ProgrammeFichier IDL
CPMMraydium_cpmm/raydium_cp_swap.json
CLMMraydium_clmm/raydium_clmm.json
LaunchLabraydium_launchpad/raydium_launchpad.json
AMM v4pas d’IDL officiel — voir raydium-sdk-V2/src/raydium/liquidity/layout.ts pour les structures maintenues manuellement
Stable AMMpas d’IDL officiel — structures dans le SDK
Farmpas d’IDL officiel — structures dans le SDK
Les fichiers IDL sont versionnés dans l’historique git du dépôt ; épinglez un commit spécifique si vous avez besoin d’une reproductibilité byte-for-byte. Les IDLs peuvent également être récupérés directement à partir des programmes déployés via la fonctionnalité on-chain IDL d’Anchor (si l’éditeur du programme a choisi d’activer cette fonctionnalité) : 
anchor idl fetch <PROGRAM_ID> --provider.cluster mainnet
CPMM, CLMM et LaunchLab ont tous des IDLs on-chain. AMM v4, Stable AMM et Farm ne les ont pas (programmes antérieurs à Anchor).

​
Régénérer un client TypeScript

La génération de code d’Anchor produit un client typé à partir de l’IDL : 
# En utilisant la CLI anchor
anchor build
anchor idl parse \
  --file target/idl/cpmm.json \
  --out target/types/cpmm.ts

# Ou avec les assistants TS de `@coral-xyz/anchor` à l'exécution :

import { Program, AnchorProvider } from "@coral-xyz/anchor";
// Récupérez l'IDL directement du dépôt raydium-idl (ou intégrez-le dans votre projet).
import cpmmIdl from "./idls/raydium_cp_swap.json";

const provider = new AnchorProvider(connection, wallet, {});
const program  = new Program(cpmmIdl as any, CPMM_PROGRAM_ID, provider);

// Les méthodes typées sont auto-générées :
await program.methods
  .swapBaseInput(new BN(amountIn), new BN(minAmountOut))
  .accounts({ ... })
  .rpc();
La plupart des intégrateurs ne font pas cela — ils utilisent l’assistant de haut niveau raydium.cpmm.swap(...) qui encapsule les méthodes Anchor plus toute la comptabilité (création d’ATA, ajustement des frais de transfert, budget de calcul, routage du programme Token-2022). Régénérez uniquement si vous avez besoin d’une couche en dessous du SDK.

​
Régénérer un client Rust (crate CPI)

Raydium publie des crates Anchor pour les programmes qui ont des IDLs : 
# Cargo.toml
[dependencies]
raydium_cp_swap = { git = "https://github.com/raydium-io/raydium-cp-swap", branch = "master", features = ["cpi"] }
raydium_amm_v3 = { git = "https://github.com/raydium-io/raydium-clmm",    branch = "master", features = ["cpi"] }
La fonctionnalité cpi expose les structures de comptes cpi::accounts::<Ix> et les invocateurs cpi::<ix>() — des enveloppes CPI prêtes à l’emploi. Consultez sdk-api/rust-cpi pour les modèles d’utilisation. Si vous préférez générer de nouvelles liaisons : 
# À partir de l'IDL, en utilisant anchor-client
anchor idl parse \
  --file raydium_cpmm/raydium_cp_swap.json \
  --out src/generated/cpmm_bindings.rs

​
Régénérer un client Python

Il n’existe pas de SDK Python officiel de Raydium. Les générateurs tiers incluent :
  • anchorpy — port Python de @coral-xyz/anchor. Génère des constructeurs de méthodes typées à partir d’IDLs.
  • solders — primitives Solana de bas niveau (transactions, paires de clés, clés publiques) dans des liaisons Rust ; utilisées sous anchorpy.
pip install anchorpy solders solana

from anchorpy import Program, Provider
from solana.rpc.async_api import AsyncClient
from pathlib import Path
import json

idl = json.loads(Path("cpmm.json").read_text())
provider = Provider(AsyncClient("https://api.mainnet-beta.solana.com"), wallet)
program  = Program(idl, CPMM_PROGRAM_ID, provider)

await program.rpc["swap_base_input"](amount_in, min_amount_out, ctx=Context(accounts={...}))
Consultez sdk-api/python-integration pour une description plus complète.

​
Politique de changement d’IDL

Raydium suit ces règles pour la stabilité de l’IDL :
  1. Les discriminateurs d’instruction ne changent jamais. L’ajout de nouvelles instructions étend l’énumération à la fin ; les discriminateurs existants restent stables.
  2. Les structures de comptes évoluent uniquement de manière additive. Les nouveaux champs vont à la fin, précédés d’une augmentation de taille dans le schéma on-chain. Les champs existants conservent leurs décalages.
  3. Les codes d’erreur énumérés ne font qu’augmenter. Un code d’erreur existant signifie toujours la même chose.
  4. Les changements radicaux sont livrés dans de nouveaux programmes. Lorsqu’une refonte est nécessaire, l’équipe déploie un nouvel ID de programme (par exemple, CPMM en tant que programme indépendant plutôt que de mettre à niveau AMM v4). Les anciens pools continuent à fonctionner sur l’ancien programme ; les nouveaux pools vont vers le nouveau.
Cette politique rend les clients régénérés rétrocompatibles : un client généré selon un IDL de deux versions plus ancien décodera toujours correctement l’état actuel (il voit les octets de fin supplémentaires comme du remplissage).

​
Que faire quand l’IDL change

  1. Mettez à jour le SDK. npm update @raydium-io/raydium-sdk-v2.
  2. Régénérez votre code client si vous utilisez directement la génération de code Anchor.
  3. Comparez la structure du compte. Les champs de fin de la nouvelle structure sont la seule chose que votre code n’a pas vue ; confirmez si vous les avez besoin.
  4. Ne supposez pas que les anciens discriminateurs d’instruction sont invalides. Selon la règle 1, ils fonctionnent toujours.
  5. Re-lancez les tests d’intégration sur devnet avant de basculer vers mainnet.

​
Dépannage d’IDL

​
Erreurs « Invalid discriminator »

Cela signifie généralement qu’un client construit selon la version N de l’IDL tente d’invoquer une instruction qui n’existait que dans une version pré-déploiement du programme. Re-récupérez l’IDL à partir du programme actif : 
anchor idl fetch <PROGRAM_ID>

​
Échecs du décodage des comptes

Si program.account.<Name>.fetch(pubkey) lève une erreur « Invalid account discriminator », le compte a été créé par une version précédente du programme et Anchor rejette son discriminateur de 8 octets. La solution est d’utiliser l’analyseur de structure brut du SDK (PoolInfoLayout.decode(accountData)) qui n’applique pas les discriminateurs Anchor.

​
Instructions manquantes dans le client généré

La génération de code TS d’Anchor génère uniquement des méthodes pour les instructions dont l’entrée IDL a un name qui s’analyse comme un identifiant valide. Les instructions de Raydium satisfont toutes à cela, mais si vous voyez une incohérence, vérifiez si le fichier IDL provient de la version SDK actuelle.

​
Pointeurs

Sources :