Saltar para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
As auditorias detectam algumas classes de bugs (padrões de ataque conhecidos, erros de controle de acesso, overflow de inteiros) e perdem outras (falhas de design econômico, manipulação teórico-jogo, bugs de integração com outros programas). Os programas do Raydium passaram por múltiplas rodadas de auditorias; esta página as lista e discute o que cada auditoria realmente verificou.

​
Tabela de auditoria por programa

ProgramaAuditorDataRelatório
Order-book AMMKudelski SecurityQ2 2021Visualizar
Concentrated liquidity (CLMM)OtterSecQ3 2022Visualizar
Updated order-book AMMOtterSecQ3 2022Visualizar
StakingOtterSecQ3 2022Visualizar
Order-book AMM & OpenBook migrationMadShieldQ2 2023Visualizar
Constant-product AMM (CPMM)MadShieldQ1 2024Visualizar
Burn & Earn (liquidity locker)HalbornQ4 2024Visualizar
LaunchLabHalbornQ2 2025Visualizar
CPMM (update)Sec3Q3 2025Visualizar
CLMM update — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Visualizar
Membros do time Neodyme também realizaram revisões extensivas através de acordos de bug-bounty. Todos os relatórios de auditoria dos programas Raydium estão espelhados sob github.com/raydium-io/raydium-docs/audit/. Cada auditor também publica em seu próprio site.

​
O que as auditorias cobrem

Uma auditoria típica do Raydium (~3–6 semanas, 2 auditores) cobre:
  • Controle de acesso — cada operação privilegiada está corretamente protegida?
  • Aritmética — overflows, underflows, direção de arredondamento, precisão de ponto fixo.
  • Validação de contas — cada conta tem o proprietário, mint, autoridade corretos?
  • Padrões semelhantes a reentrância — o estado é atualizado antes ou depois de um CPI?
  • Derivação de PDA — as seeds são consistentes em todos os locais?
  • Códigos e mensagens de erro — as condições de erro revertam de forma limpa?
  • Qualidade de código — Rust idiomático, código morto, ramos inacessíveis.

​
O que as auditorias não cobrem

  • Teoria dos jogos econômicos — por exemplo, “se eu posso criar 1000 pools gratuitamente, posso prejudicar o roteador?”
  • MEV / ordenação — ataques sandwich, front-running via colusão de validadores.
  • Infraestrutura off-chain — confiabilidade de RPC, correção do indexador, frontend.
  • Integrações com outros programas — bugs que só se manifestam quando compostos com contratos de empréstimos, opções ou agregadores específicos.
  • Comportamentos emergentes ao longo do tempo — o que acontece após 10 milhões de posições? As auditorias observam casos de teste em pequena escala.
É por isso que auditoria ≠ garantia de segurança. Raydium complementa auditorias com bug bounties, monitoramento e engenharia defensiva.

​
Status de resolução de descobertas

Cada auditoria produz uma lista de descobertas (crítico / alto / médio / baixo / informativo), com contagens de severidade e status por descoberta (Corrigido / Reconhecido / Não será corrigido). Os detalhes por descoberta não são duplicados aqui — leia cada relatório diretamente através da tabela acima.

​
Re-auditoria após mudanças significativas

Quando um programa lança uma atualização significativa (nova instrução, novo campo de conta, novo suporte a extensão), o Raydium comissiona uma re-auditoria. A revisão Sec3 Q3 2025 do CPMM e a revisão Sec3 Q2 2026 do CLMM (Limit Order, Dynamic Fee, Single Asset Fee) listadas na tabela acima são ambas re-auditorias desse tipo. O escopo da re-auditoria é mais estreito (apenas o diff), mas é genuinamente uma re-auditoria — não apenas uma revisão de código. Os relatórios de re-auditorias são anexados ao relatório de auditoria primária.

​
Verificação on-chain

O hash do programa implantado deve corresponder ao hash do código auditado. Qualquer um pode verificar: 
# Pull the deployed program bytecode.
solana program dump <PROGRAM_ID> program.so

# Build the repo at the audited commit.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# Compare.
sha256sum program.so target/deploy/raydium_cp_swap.so
Os builds verifiable do Anchor produzem bytecode determinístico; os hashes devem corresponder exatamente. Se não corresponderem, o programa implantado não é o auditado — escale. O Raydium publica os hashes esperados por deploy na seção de releases do repositório.

​
Como ler um relatório de auditoria

Um guia breve para não-auditores:
  1. Vá diretamente ao resumo de descobertas — uma tabela com contagens de severidade. Se a contagem de “Crítico” for >0 e você vir status “Aberto”, investigue.
  2. Leia a descrição e status de cada descoberta. “Corrigido no commit XYZ” significa resolvido; “Reconhecido” significa que o time aceitou o risco; “Parcialmente corrigido” vale uma investigação mais profunda.
  3. Escaneie a seção de escopo. Se a auditoria não cobriu a instrução ou conta de que você se preocupa, a ausência de descobertas lá não é evidência de segurança.
  4. Folheie a seção de recomendações do auditor. Frequentemente mais útil que as descobertas — revela notas “não conseguimos provar formalmente mas estamos desconfortáveis”.

​
Integração de bug-bounty

As auditorias são executadas pré-deploy; os bug bounties são executados continuamente pós-deploy. O programa de bounty do Raydium (security/disclosure) cobre tudo que as auditorias cobrem além disso:
  • Ataques econômicos que as auditorias não cobrem.
  • Bugs encontrados em novas integrações.
  • Bugs de implementação em SDKs e componentes off-chain.
Uma descoberta de whitehat no programa de bounty geralmente é paga mais rapidamente do que esperar pelo próximo ciclo de auditoria; os incentivos estão alinhados para divulgar rapidamente. O programa ativo é hospedado no Immunefi: immunefi.com/bug-bounty/raydium/information.

​
Incidentes históricos

Os programas do Raydium tiveram dois incidentes notáveis no mundo real:

​
Exploração de autoridade de pool (Dezembro 2022)

O que: A chave privada da autoridade do pool AMM v4 foi comprometida, permitindo que um invasor drenasse vários pools. Escopo: Gerenciamento operacional de chaves, não um bug do programa. A auditoria não havia sinalizado o código porque o código estava correto; o processo de gerenciamento de chaves foi a falha. Correção: Migração de multisig (todos os papéis de autoridade movidos para multisig do Squads); controles operacionais adicionais. Lição: As auditorias não cobrem gerenciamento de chaves. Veja security/admin-and-multisig.

​
Congelamento de integração OpenBook (Janeiro 2023)

O que: Uma atualização do programa OpenBook alterou a semântica da conta; o MonitorStep crank do AMM v4 não conseguiu liquidar o PnL até que um patch do AMM v4 fosse lançado. Escopo: Bug de integração — nenhum programa estava errado isoladamente. Correção: Patch do AMM v4 e deploy coordenado. Lição: As auditorias do programa A não detectam bugs na integração do programa A com o programa B. A ferramenta correta é testes de integração + rollouts em etapas.

​
Referências

Fontes: