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 →
Fonte de verdade. As tabelas abaixo são regeneradas a partir de error.rs em cada programa nos repositórios públicos do Raydium. Quando um programa é atualizado e uma nova variante é adicionada, execute novamente a extração (link no final de cada tabela) e acrescente à tabela em vez de reorganizar — os códigos de erro Anchor são atribuídos por ordem de origem, não por nome, então reorganizar quebra o tratamento de erros dos integradores.

Como funcionam os códigos de erro Anchor

Anchor atribui a cada variante do enum ErrorCode de um programa um código numérico começando em 6000. Uma transação que falha expõe:
  • Código de erro numérico (ex: 0x1771 = 6001) nos logs da transação.
  • Nome do erro (ex: InvalidOwner) do IDL.
  • String #[msg(...)] que Anchor emitiu em log_messages.
Integradores devem fazer correspondência no código numérico, não na string de mensagem (a string pode ser reformulada sem aumentar uma versão).

Erros CPMM (AMM Padrão)

ID do programa: veja reference/program-addresses. Fonte: raydium-cp-swap/programs/cp-swap/src/error.rs. Fonte de regeneração: github.com/raydium-io/raydium-cp-swap — error.rs.

Erros CLMM

ID do programa: veja reference/program-addresses. Fonte: raydium-clmm/programs/amm/src/error.rs.
Nota sobre renumeração. O enum ErrorCode do CLMM foi renumerado nesta versão: cinco variantes legadas (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) e vários erros de digitação (Liquitity, enought, emissiones) foram removidos/corrigidos, e onze novas variantes foram adicionadas (6040–6050) pelo lançamento de ordens limitadas; 6051 (InvalidTickArrayBitmapExtensionAccount) veio de uma mudança separada e posterior. Isso dá 52 variantes no total, 6000–6051 — a mesma contagem que o IDL on-chain do programa implantado informa. Como Anchor numera erros por ordem de origem, cada código em ou após 6000 mudou em relação a compilações pré-lançamento. Clientes que codificaram códigos numéricos contra uma versão anterior precisam remapear.
Fonte de regeneração: github.com/raydium-io/raydium-clmm — error.rs.

Erros AMM v4, Farm v3 / v5 / v6, LaunchLab

Esses programas são documentados em seus respectivos capítulos (veja products/amm-v4/instructions, products/farm-staking/instructions, products/launchlab/instructions). Como esses programas usam uma mistura de superfícies de erro Anchor e Solana simples, suas tabelas de erro vivem ao lado da referência de instrução em vez de aqui. Os códigos abaixo são reservados por esses capítulos: Os lançamentos recentes do LaunchLab mantêm códigos 6000–6021 inalterados. O lançamento de 2026-08-17 removeu os antigos erros de acesso global da plataforma e atribuiu 6022 ao erro de validação de conta de permissão; o lançamento de 2026-08-24 acrescenta 6023; o lançamento de 2026-08-31 acrescenta 6024–6030; o lançamento de 2026-09-09 acrescenta 6031: As antigas variantes PlatformGlobalAccessDenied (6022) e InvalidPlatformGlobalAccess (6023) são removidas. Não decodifique 6022 usando o IDL anterior, e note que 6023 — desocupado pelo lançamento de 2026-08-17 — é reutilizado pelo lançamento de 2026-08-24 para um erro não relacionado, portanto não deve ser decodificado com um IDL de nenhuma versão anterior. 6020 é retido deliberadamente. Anchor numera variantes por posição, então deletá-lo mudaria cada código após ele e quebraria cada cliente que decodifica 6021–6031.

AMM v4: AmmError não é numerado por Anchor

AMM v4 é anterior ao Anchor. AmmError é um enum thiserror simples com FromPrimitive, convertido através de ProgramError::Custom(e as u32), então seus códigos começam em 0, não 6000 — e, como o Anchor, são atribuídos por ordem de origem. O upgrade de 2026-09 acrescenta uma variante: Códigos 0–59 não foram alterados, então nada muda. Nos logs de transação, isso aparece como custom program error: 0x3c. Fonte de regeneração: github.com/raydium-io/raydium-amm — error.rs.

Mapeando erros do SDK para erros do programa

O SDK TypeScript oficial envolve erros on-chain em SendTransactionError e, para programas Anchor, AnchorError:
Se você não estiver usando Anchor no lado do cliente, analise os logs de transação:
O padrão Error Number: (\d+) é estável entre versões do Anchor e seguro para corresponder.

Regenerando essas tabelas

Quando um programa é atualizado e adiciona um novo erro, re-extraia da origem:
Sempre atualize reference/changelog quando uma nova variante é adicionada, para que os integradores que atualizam o SDK saibam atualizar seus manipuladores de erro. Fontes: