Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
Qué es un IDL
Los programas Anchor en Solana publican un archivo IDL (Interface Definition Language) que describe sus instrucciones, esquemas de cuentas, enumeración de errores y esquemas de estructuras. El IDL es la fuente de verdad para la generación de código cliente — el SDK de TS, la crate de CPI de Rust y los clientes de terceros se generan a partir de él (o se escriben manualmente contra él). Raydium publica IDLs para CPMM, CLMM y LaunchLab. AMM v4, Stable AMM y Farm (v3 / v5 / v6) son anteriores a Anchor o no se distribuyen con Anchor — sus estructuras de cuentas se mantienen manualmente en el SDK.Dónde encontrarlos
Los IDLs viven en un repositorio dedicado:
Los archivos IDL están versionados en el historial de git del repositorio; fija un commit específico si necesitas reproducibilidad byte por byte.
Algunos IDLs también se pueden extraer directamente de mainnet:
Las tres cuentas IDL heredadas son escribibles por la autoridad de IDL
2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt, que es separada de la autoridad de actualización BPF de los programas — por lo que un IDL puede actualizarse sin reimplementar, y también puede retrasarse respecto a una reimplementación. Trata el IDL en cadena como una conveniencia, no como prueba de la forma del bytecode implementado.
Regenerar un cliente TypeScript
El codegen de Anchor produce un cliente tipado a partir del IDL:raydium.cpmm.swap(...) que envuelve los métodos de Anchor más toda la contabilidad (creación de ATA, ajuste de tarifa de transferencia, presupuesto de cómputo, enrutamiento del programa Token-2022). Regenera solo cuando necesites una capa por debajo del SDK.
Regenerar un cliente Rust (crate de CPI)
Raydium publica crates de Anchor para los programas que tienen IDLs:raydium_cp_swap y raydium_clmm. No existe una crate llamada raydium_amm_v3 bajo ninguna ortografía. Ten en cuenta que las ramas difieren: la rama master de raydium-cp-swap aún fija anchor-lang 0.32.1, por lo que una integración de Anchor-1.0 necesita chore/upgrade-anchor; CLMM está en 0.32.1 de cualquier forma, por lo que los dos no pueden compartir una crate.
La característica cpi expone estructuras de cuentas cpi::accounts::<Ix> e invocadores cpi::<ix>() — envoltorios de CPI listos para usar. Consulta sdk-api/rust-cpi para patrones de uso.
Si prefieres generar enlaces frescos:
Regenerar un cliente Python
No hay un SDK oficial de Python para Raydium. Los generadores de terceros incluyen:anchorpy— puerto de Python del cliente TypeScript de Anchor. Genera constructores de métodos tipados a partir de IDLs.solders— primitivas de Solana de bajo nivel (transacciones, pares de claves, claves públicas) en enlaces de Rust; se usa debajo deanchorpy.
sdk-api/python-integration para un recorrido más completo.
Política de cambios de IDL
Raydium sigue estas reglas para la estabilidad del IDL:- Los discriminadores de instrucciones nunca cambian. Agregar nuevas instrucciones extiende la enumeración al final; los discriminadores existentes permanecen estables.
- Los tamaños de cuentas son estables; los nuevos campos salen del relleno reservado. Cada estructura de estado de Raydium lleva una región de relleno final dimensionada en la creación, y un nuevo campo se extrae de ese relleno en lugar de agregarse — por lo que la longitud de bytes de la cuenta y los desplazamientos de todos los campos preexistentes permanecen fijos. El corolario es que los bytes que previamente leías como relleno pueden volverse significativos, y un campo puede retirarse nuevamente al relleno (como
PlatformConfig.curve_paramsfue en la versión 2026-08-31). Relee la definición de estructura después de una actualización; no asumas que el relleno permanece en cero. - Los códigos de enumeración de errores son solo de adición. Un código de error existente siempre significa lo mismo.
- Los cambios disruptivos se envían en nuevos programas. Cuando se necesita un rediseño, el equipo implementa un nuevo ID de programa (por ejemplo, CPMM como un programa nuevo en lugar de actualizar AMM v4). Los pools antiguos continúan ejecutándose en el programa antiguo; los nuevos pools van al nuevo.
Qué hacer cuando cambia el IDL
- Actualiza el SDK.
npm update @raydium-io/raydium-sdk-v2. - Regenera tu código cliente si usas codegen de Anchor directamente.
- Compara el esquema de cuenta. Los campos finales del nuevo esquema son lo único que tu código no ha visto; confirma si los necesitas.
- No asumas que los discriminadores de instrucciones antiguos son inválidos. Según la regla 1, aún funcionan.
- Vuelve a ejecutar pruebas de integración contra devnet antes de pasar a mainnet.
Solución de problemas de IDL
Errores “Invalid discriminator”
Generalmente significa que un cliente construido contra la versión N del IDL está intentando invocar una instrucción que existía solo en una versión anterior a la implementación del programa. Vuelve a extraer el IDL del programa en vivo:Fallos de decodificación de cuenta
Siprogram.account.<Name>.fetch(pubkey) lanza con “Invalid account discriminator”, la cuenta fue creada por una versión anterior del programa y Anchor está rechazando su discriminador de 8 bytes. La solución es usar el analizador de esquema sin procesar del SDK (PoolInfoLayout.decode(accountData)) que no aplica discriminadores de Anchor.
Instrucciones faltantes en el cliente generado
El codegen de TS de Anchor solo genera métodos para instrucciones cuya entrada de IDL tiene unname que se analiza como un identificador válido. Las instrucciones de Raydium todas satisfacen esto, pero si ves una discrepancia, verifica si el archivo IDL es de la versión actual del SDK.
Referencias
sdk-api/rust-cpi— usando las crates de CPI de Rust.sdk-api/python-integration— Python víaanchorpy.sdk-api/typescript-sdk— el cliente de TS de nivel superior.

