Skip to main content
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 exatos: 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:
Existem agora dois mecanismos de IDL on-chain, e os programas Raydium estão divididos entre eles — o que importa porque uma determinada versão do Anchor CLI pode conhecer apenas um:
CPMM não tem conta anchor:idl legada. Seu IDL foi migrado para o programa Program Metadata, então anchor idl fetch CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C falha em qualquer Anchor CLI que apenas verifica o PDA legado. Use o IDL fornecido com o SDK, ou leia a conta de metadados acima, até que sua CLI suporte o programa de metadados.
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:
A maioria dos integradores não faz isso — eles usam o helper de nível superior 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:
No código, refira-se a eles pelos seus nomes de lib, 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 sob anchorpy.
Veja 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:
  1. Discriminadores de instrução nunca mudam. Adicionar novas instruções estende o enum no final; discriminadores existentes permanecem estáveis.
  2. 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_params foi 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.
  3. Códigos de enum de erro são apenas anexados. Um código de erro existente sempre significa a mesma coisa.
  4. 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.
Esta política mantém clientes regenerados principalmente compatíveis com versões anteriores: um cliente gerado contra um IDL mais antigo continua decodificando os campos que conhece, nos offsets que conhece. O que ele não verá é um campo esculpido a partir do que ainda trata como padding — e, no raro caso de aposentadoria, um campo que decodifica pode não ser mais escrito. Ele não vê “bytes finais extras”: o comprimento da conta não muda.

O que fazer quando o IDL muda

  1. Atualize o SDK. npm update @raydium-io/raydium-sdk-v2.
  2. Regenere seu código cliente se usar codegen Anchor diretamente.
  3. 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.
  4. Não assuma que discriminadores de instrução antigos são inválidos. Pela regra 1, eles ainda funcionam.
  5. 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:
Para CPMM isso não funcionará — veja a tabela de localização de IDL acima; puxe o IDL fornecido com o SDK em vez disso.

Falhas de decodificação de conta

Se program.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 um name 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

Fontes: