> ## 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. # Anchor IDL > Où trouver l'IDL de chaque programme Raydium, comment régénérer les clients TS / Rust / Python à partir de celui-ci, et la politique de changement d'IDL du protocole. **Cette page est traduite automatiquement par IA. La version anglaise fait foi.** [Voir la version anglaise →](/sdk-api/anchor-idl) ## Qu'est-ce qu'un IDL Les programmes Anchor sur Solana publient un fichier **IDL** (Interface Definition Language) décrivant leurs instructions, les dispositions des comptes, l'énumération des erreurs et les 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 contre celui-ci). 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 par Anchor — leurs structures de compte sont maintenues manuellement dans le SDK. ## Où les trouver Les IDLs se trouvent dans un dépôt dédié : ``` https://github.com/raydium-io/raydium-idl ``` Les fichiers exacts : | Programme | Fichier IDL | | - | - | | CPMM | [`raydium_cpmm/raydium_cp_swap.json`](https://github.com/raydium-io/raydium-idl/blob/master/raydium_cpmm/raydium_cp_swap.json) | | CLMM | [`raydium_clmm/raydium_clmm.json`](https://github.com/raydium-io/raydium-idl/blob/master/raydium_clmm/raydium_clmm.json) | | LaunchLab | [`raydium_launchpad/raydium_launchpad.json`](https://github.com/raydium-io/raydium-idl/blob/master/raydium_launchpad/raydium_launchpad.json) | | AMM v4 | pas d'IDL officiel — voir [`raydium-sdk-V2/src/raydium/liquidity/layout.ts`](https://github.com/raydium-io/raydium-sdk-V2/blob/master/src/raydium/liquidity/layout.ts) pour les dispositions écrites manuellement | | Stable AMM | pas d'IDL officiel — dispositions dans le SDK | | Farm | pas d'IDL officiel — dispositions 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é octet par octet. Certains IDLs peuvent également être extraits directement du mainnet : ```bash theme={null} anchor idl fetch --provider.cluster mainnet ``` Il existe maintenant **deux** mécanismes d'IDL en chaîne, et les programmes de Raydium sont répartis entre eux — ce qui importe car une version donnée d'Anchor CLI ne peut connaître qu'un seul : | Programme | Où son IDL se trouve | Compte | Rapports | | - | - | - | - | | CLMM | Compte `anchor:idl` Anchor hérité | `FbDNAPsgm8Y5jWXQkXjpfN6Bp8xHeRkhMmsstAooPyY9` | `raydium_clmm` 0.1.0 — 38 instructions, 52 erreurs (39 / 53 après la [mise à jour du 2026-09-30](/fr/reference/changelog/2026-09-30-clmm-anchor-1-and-excess-lamports)) | | LaunchLab | Compte `anchor:idl` Anchor hérité | `E6wT2uNeoWUvDrwdch1R8ETsyewR1ZM4WAwsa5hLJK5Z` | `raydium_launchpad` 0.2.0 — 27 instructions | | Lock (Burn & Earn) | Compte `anchor:idl` Anchor hérité | `HzLkUWn57cdtyQNQLJpyu2EPF8qQAiGt4iuiEo1XnEFK` | 4 instructions (spécification IDL pré-`metadata`) | | **CPMM** | **Programme Metadata program** `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` | `FHuJXL7cEttfHk4sXdTAXVaRymBdKfVs7ZH6cMgA1ihk` (canonique, seed `idl`) | `raydium_cp_swap` 0.2.0 | | AMM v4, Stable AMM, AMM Routing, Farm v3 / v5 / v6 | Nulle part | — | Programmes non-Anchor ; aucun IDL n'est publié | **CPMM n'a pas de compte `anchor:idl` hérité.** Son IDL a été migré vers le Programme Metadata program, donc `anchor idl fetch CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C` échoue sur tout Anchor CLI qui ne vérifie que le PDA hérité. Utilisez l'IDL fourni avec le SDK, ou lisez le compte de métadonnées ci-dessus, jusqu'à ce que votre CLI supporte le programme de métadonnées. Les trois comptes IDL hérités sont modifiables par l'autorité IDL `2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt`, qui est distincte de l'autorité de mise à niveau BPF des programmes — donc un IDL peut être actualisé sans redéploiement, et peut également être en retard sur un redéploiement. Traitez l'IDL en chaîne comme une commodité, pas comme une preuve de la forme du bytecode déployé. ## Régénérer un client TypeScript La génération de code d'Anchor produit un client typé à partir de l'IDL : ```bash theme={null} # Utilisation de l'Anchor CLI anchor build anchor idl parse \ --file target/idl/cpmm.json \ --out target/types/cpmm.ts # Ou avec les assistants TS `@anchor-lang/core` à l'exécution : ``` ```ts theme={null} import { Program, AnchorProvider } from "@anchor-lang/core"; // Extrayez l'IDL directement du dépôt raydium-idl (ou vendez-le dans votre projet). import cpmmIdl from "./idls/raydium_cp_swap.json"; const provider = new AnchorProvider(connection, wallet, {}); // Anchor >= 0.30 lit l'ID du programme à partir de `idl.address` — ces IDLs sont spec 0.1.0 // et le portent. La forme à trois arguments `new Program(idl, programId, provider)` est // pré-0.30 et lève une exception. const program = new Program(cpmmIdl as any, provider); // Les constructeurs de méthodes typés générés automatiquement : 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 niveau supérieur `raydium.cpmm.swap(...)` qui enveloppe 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 lorsque 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 : ```toml theme={null} # Cargo.toml — la clé de dépendance doit être le nom PACKAGE de la crate. [dependencies] raydium-cp-swap = { git = "https://github.com/raydium-io/raydium-cp-swap", branch = "chore/upgrade-anchor", features = ["cpi"] } raydium-clmm = { git = "https://github.com/raydium-io/raydium-clmm", branch = "chore/upgrade-anchor", features = ["cpi"] } ``` Dans le code, référencez-les par leurs noms **lib**, `raydium_cp_swap` et `raydium_clmm`. Il n'existe pas de crate appelée `raydium_amm_v3` sous aucune orthographe. Attention à la branche. Les deux dépôts `master` épinglent toujours `anchor-lang 0.32.1`, donc une intégration Anchor 1.0 a besoin de `chore/upgrade-anchor` sur chacun. Avec les deux crates sur cette branche, elles partagent `=1.0.2` et peuvent vivre dans une seule crate. Mélanger une crate `master` avec une crate de branche de mise à niveau ne compile pas. La fonctionnalité `cpi` expose les structures de compte `cpi::accounts::` et les invocateurs `cpi::()` — des wrappers CPI prêts à l'emploi. Voir [`sdk-api/rust-cpi`](/fr/sdk-api/rust-cpi) pour les modèles d'utilisation. Si vous préférez générer des liaisons fraîches : ```bash theme={null} # À 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 Raydium. Les générateurs tiers incluent : * **`anchorpy`** — port Python du client TypeScript d'Anchor. Génère des constructeurs de méthodes typés à partir d'IDLs. * **`solders`** — primitives Solana de bas niveau (transactions, paires de clés, clés publiques) dans les liaisons Rust ; utilisé sous `anchorpy`. ```bash theme={null} pip install anchorpy solders solana ``` ```python theme={null} 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={...})) ``` Voir [`sdk-api/python-integration`](/fr/sdk-api/python-integration) pour une présentation 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 tailles de compte sont stables ; les nouveaux champs sortent du remplissage réservé.** Chaque structure d'état Raydium porte une région de remplissage finale dimensionnée à la création, et un nouveau champ est extrait de ce remplissage plutôt qu'ajouté — donc la longueur en octets du compte et les décalages de tous les champs *pré-existants* restent fixes. Le corollaire est que les octets que vous lisiez précédemment comme remplissage peuvent devenir significatifs, et un champ peut être retiré dans le remplissage (comme `PlatformConfig.curve_params` l'a été dans la version du 2026-08-31). Relisez la définition de la structure après une mise à niveau ; ne supposez pas que le remplissage reste zéro. 3. **Les codes d'énumération d'erreur sont en ajout uniquement.** Un code d'erreur existant signifie toujours la même chose. 4. **Les changements de rupture se font 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 nouveau programme plutôt que de mettre à niveau AMM v4). Les anciens pools continuent à s'exécuter sur l'ancien programme ; les nouveaux pools vont au nouveau. Cette politique maintient les clients régénérés largement rétro-compatibles : un client généré contre un IDL plus ancien continue de décoder les champs qu'il connaît, aux décalages qu'il connaît. Ce qu'il ne verra *pas*, c'est un champ extrait de ce qu'il traite toujours comme du remplissage — et, dans le rare cas de retraite, un champ qu'il décode peut ne plus être écrit. Il ne voit pas « d'octets supplémentaires à la fin » : la longueur du compte ne change pas. ## 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 la génération de code Anchor directement. 3. **Comparez la disposition du compte.** Les champs finaux de la nouvelle disposition sont la seule chose que votre code n'a pas vue ; confirmez si vous en avez besoin. 4. **Ne supposez pas que les anciens discriminateurs d'instruction sont invalides.** Selon la règle 1, ils fonctionnent toujours. 5. **Réexécutez les tests d'intégration** sur devnet avant de passer au mainnet. ## Dépannage de l'IDL ### Erreurs « Invalid discriminator » Signifie généralement qu'un client construit contre la version N de l'IDL essaie d'invoquer une instruction qui n'existait que dans une version pré-déploiement du programme. Réextrayez l'IDL du programme en direct : ```bash theme={null} anchor idl fetch ``` Pour CPMM, cela ne fonctionnera pas — voir le tableau des emplacements d'IDL ci-dessus ; extrayez plutôt l'IDL fourni avec le SDK. ### Échecs du décodage du compte Si `program.account..fetch(pubkey)` lève une exception avec « 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 consiste à utiliser l'analyseur de disposition brute 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 ne génère des méthodes que 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 discordance, vérifiez si le fichier IDL provient de la version actuelle du SDK. ## Pointeurs * [`sdk-api/rust-cpi`](/fr/sdk-api/rust-cpi) — utilisation des crates CPI Rust. * [`sdk-api/python-integration`](/fr/sdk-api/python-integration) — Python via `anchorpy`. * [`sdk-api/typescript-sdk`](/fr/sdk-api/typescript-sdk) — le client TS de niveau supérieur. Sources : * [Dépôt Raydium IDL](https://github.com/raydium-io/raydium-idl) * [Spécification Anchor IDL](https://www.anchor-lang.com/docs/basics/idl) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.