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 conta 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:
Todas 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. Note que os branches diferem: o master de raydium-cp-swap ainda fixa anchor-lang 0.32.1, então uma integração Anchor-1.0 precisa de chore/upgrade-anchor; CLMM está em 0.32.1 de qualquer forma, é por isso que os dois não podem compartilhar um crate.
O recurso cpi expõe structs de conta 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 sobanchorpy.
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ção nunca mudam. Adicionar novas instruções estende o enum no final; discriminadores existentes permanecem estáveis.
- Tamanhos de conta 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 ao 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, a equipe 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.
- Diferencie o 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ção 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 do 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.

