Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
O que é um IDL
Programas Anchor no Solana publicam um arquivo IDL (Interface Definition Language) que descreve suas instruções, layouts de contas, enum de erros e esquemas de structs. O IDL é a fonte de verdade para geração de código cliente — o SDK TS, crate CPI Rust e clientes de terceiros são todos gerados a partir dele (ou escritos manualmente contra ele). Raydium publica IDLs para CPMM, CLMM e LaunchLab. AMM v4, Stable AMM e Farm (v3 / v5 / v6) são anteriores ao Anchor ou não são distribuídos via Anchor — suas estruturas de contas são mantidas manualmente no SDK.Onde encontrá-los
IDLs vivem em um repositório dedicado:
Os arquivos IDL são versionados no histórico git do repositório; fixe um commit específico se precisar de reprodutibilidade byte-por-byte.
Alguns IDLs também podem ser obtidos diretamente da mainnet:
As três contas IDL legadas são graváveis pela autoridade IDL
2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt, que é separada da autoridade de upgrade BPF dos programas — então um IDL pode ser atualizado sem reimplantar, e também pode ficar atrás de uma reimplantação. Trate o IDL on-chain como uma conveniência, não como prova da forma do bytecode implantado.
Regenerando um cliente TypeScript
O codegen do Anchor produz um cliente tipado a partir do IDL:raydium.cpmm.swap(...) que envolve os métodos Anchor mais toda a contabilidade (criação de ATA, ajuste de taxa de transferência, orçamento de computação, roteamento do programa Token-2022). Regenere apenas quando precisar de uma camada abaixo do SDK.
Regenerando um cliente Rust (crate CPI)
Raydium publica crates Anchor para os programas que têm IDLs:raydium_cp_swap e raydium_clmm. Não existe um crate chamado raydium_amm_v3 sob nenhuma grafia. Preste atenção no branch. Os repositórios master de ambos ainda fixam anchor-lang 0.32.1, então uma integração Anchor 1.0 precisa de chore/upgrade-anchor em cada um. Com ambos os crates nesse branch, eles compartilham =1.0.2 e podem viver em um crate. Misturar um crate master com um crate de branch de upgrade não compila.
O recurso cpi expõe structs de contas cpi::accounts::<Ix> e invocadores cpi::<ix>() — wrappers CPI prontos para usar. Veja sdk-api/rust-cpi para padrões de uso.
Se preferir gerar bindings frescos:
Regenerando um cliente Python
Não há SDK Python oficial do Raydium. Geradores de terceiros incluem:anchorpy— porta Python do cliente TypeScript do Anchor. Gera construtores de método tipados a partir de IDLs.solders— primitivos Solana de baixo nível (transações, keypairs, pubkeys) em bindings Rust; usado por baixo deanchorpy.
sdk-api/python-integration para um passo a passo mais completo.
Política de mudanças de IDL
Raydium segue estas regras para estabilidade de IDL:- Discriminadores de instruções nunca mudam. Adicionar novas instruções estende o enum no final; discriminadores existentes permanecem estáveis.
- Tamanhos de contas são estáveis; novos campos saem do padding reservado. Cada struct de estado Raydium carrega uma região de padding final dimensionada na criação, e um novo campo é esculpido a partir desse padding em vez de ser anexado — então o comprimento em bytes da conta e os offsets de todos os campos pré-existentes permanecem fixos. O corolário é que bytes que você anteriormente lia como padding podem se tornar significativos, e um campo pode ser aposentado de volta para padding (como
PlatformConfig.curve_paramsfoi na versão de 2026-08-31). Releia a definição da struct após uma atualização; não assuma que o padding permanece zero. - Códigos de enum de erro são apenas anexados. Um código de erro existente sempre significa a mesma coisa.
- Mudanças quebradas são enviadas em novos programas. Quando um redesenho é necessário, o time implanta um novo ID de programa (por exemplo, CPMM como um programa novo em vez de atualizar AMM v4). Pools antigos continuam a rodar no programa antigo; novos pools vão para o novo.
O que fazer quando o IDL muda
- Atualize o SDK.
npm update @raydium-io/raydium-sdk-v2. - Regenere seu código cliente se usar codegen Anchor diretamente.
- Faça diff do layout da conta. Os campos finais do novo layout são a única coisa que seu código não viu; confirme se você precisa deles.
- Não assuma que discriminadores de instruções antigos são inválidos. Pela regra 1, eles ainda funcionam.
- Re-execute testes de integração contra devnet antes de passar para mainnet.
Solução de problemas de IDL
Erros “Invalid discriminator”
Geralmente significa que um cliente construído contra a versão N do IDL está tentando invocar uma instrução que existia apenas em uma versão pré-implantação do programa. Re-puxe o IDL do programa ao vivo:Falhas de decodificação de conta
Seprogram.account.<Name>.fetch(pubkey) lança com “Invalid account discriminator”, a conta foi criada por uma versão anterior do programa e Anchor está rejeitando seu discriminador de 8 bytes. A correção é usar o analisador de layout bruto do SDK (PoolInfoLayout.decode(accountData)) que não impõe discriminadores Anchor.
Instruções ausentes no cliente gerado
O codegen TS do Anchor apenas gera métodos para instruções cuja entrada IDL tem umname que analisa como um identificador válido. As instruções Raydium todas satisfazem isso, mas se você vir uma discrepância, verifique se o arquivo IDL é da versão atual do SDK.
Referências
sdk-api/rust-cpi— usando os crates CPI Rust.sdk-api/python-integration— Python viaanchorpy.sdk-api/typescript-sdk— o cliente TS de nível superior.

