Vetores de ataque

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.

Um AMM é um alvo apetitoso para código adversário: os fundos dos LPs estão em pools totalmente visíveis; cada swap altera o preço determinísticamente. Esta página cataloga as classes de ataque que foram demonstradas contra AMMs em qualquer lugar, como elas se aplicam ao Raydium especificamente, e o que o Raydium (e integradores) fazem para se defender.

​

1. Ataques de sandwich / MEV

​

Ataque

Um bot observa o mempool / fluxo de gossip, vê um swap do usuário, faz front-run com uma compra na mesma direção (empurrando o preço), deixa o tx do usuário executar a um preço pior, depois faz back-run com uma venda na direção oposta. O bot lucra o spread.

​

Exposição

• Mais exposto: pools CPMM com baixo TVL e pools AMM v4 — até trades pequenas movem o preço significativamente.
• Menos exposto: pools CLMM profundas — trades dentro do tick não movem o preço.
• Não exposto: colheitas de farm, depósitos de LP (razão forçada, não sensível a preço da mesma forma).

​

Defesas

• Jito bundles (integration-guides/routing-and-mev) ocultam o tx do mempool público.
• Slippage apertado — minimum-out mais próximo do esperado torna sandwiches não lucrativos. Abaixo de ~0,3%, a maioria dos sandwiches perde dinheiro.
• Tamanhos de trade menores — dividir um swap de $100k em 10× $10k; cada um move o preço menos.

​

Postura do Raydium

Os programas centrais do Raydium não forçam proteções anti-MEV — são neutros no nível do programa. A proteção acontece na camada de submissão (Jito, proteção integrada das carteiras). A UI padrão de slippage é 0,5%, o que é razoável para a maioria dos pools.

​

2. Manipulação de preço

​

Ataque

Um trader grande move temporariamente o preço de um pool (por um flash loan ou baleia auto-financiada), dispara alguma ação downstream que depende do preço (uma liquidação, um empréstimo derivado de oráculo, um pagamento de derivativo), depois retorna o preço ao normal.

​

Exposição

• Operações nativas do Raydium: não exposto. Um swap spot dentro e fora apenas incorre em taxas de ida e volta; o trader perde dinheiro.
• Programas integrados: expostos se lerem o preço do pool Raydium ingenuamente.

​

Defesas

• Use TWAPs, não preços spot, para composição (veja security/oracle-and-token-risks).
• CLMM ObservationState fornece uma TWAP de janela curta que não é manipulável sem comprometimento de capital sustentado.
• Consenso multi-oráculo: se seu programa lê Raydium e Pyth e Jupiter e só age quando concordam dentro de 1%, manipulação de flash-loan de qualquer fonte única não é suficiente.

​

Postura do Raydium

CLMM inclui suporte TWAP de ObservationState; integradores que o ignoram e usam preços spot estão por sua conta. O frontend do Raydium usa múltiplas fontes de preço para exibição em USD.

​

3. Ataques de doação / inflação

​

Ataque

Primeiro LP em um novo pool deposita uma quantia minúscula (ex., 1 token de cada mint de 6 casas decimais → 1 unidade de LP emitida). Então o atacante “doa” 1.000.000 de tokens diretamente para o cofre do pool via transferência SPL Token. Agora 1 unidade de LP representa 500.000 de cada mint. Qualquer LP subsequente depositando menos disso é arredondado para 0 unidades de LP e perde seu depósito.

​

Exposição

• CPMM / AMM v4: potencialmente exposto em pools recém-criados, com baixa liquidez.
• CLMM: não exposto (sem mint de LP compartilhado; cada posição é seu próprio NFT com valor de liquidez explícito).

​

Defesas

A instrução initialize do CPMM bloqueia uma quantidade mínima de LP para o pool (inspirado pelo padrão MINIMUM_LIQUIDITY do Uniswap V2). Isto significa que o primeiro LP recebe sqrt(x × y) - MINIMUM_LIQUIDITY, com a MINIMUM_LIQUIDITY (1000 unidades) queimada para null. Um ataque de doação exige que o atacante doe >> o depósito inicial, o que se torna não econômico. Adicionalmente, o SDK do Raydium avisa fortemente quando o depósito inicial é minúsculo e guia usuários para quantias sensatas.

​

Postura do Raydium

O bloqueio MINIMUM_LIQUIDITY é incluído no CPMM; AMM v4 tem um mecanismo similar. Usuários criando pools devem inicializar com pelo menos 10.000+ unidades de cada mint para tornar ataques de doação não econômicos de qualquer forma.

​

4. Abuso de transfer-hook do Token-2022

​

Ataque

O hook de transferência de uma mint é atualizável. Atacante implanta um hook inocente no lançamento da mint, é listado no Raydium, acumula LP de usuários. Depois, atualiza o hook para bloquear todas as transferências (efetivamente um soft-rug — usuários não conseguem sacar). Atacante torna o pool comercializável apenas em uma direção, compra LP barato, desbloqueia hooks, vence.

​

Exposição

Pools que incluem uma mint com transfer-hook.

​

Defesas

• Nível do programa: os programas Raydium invocam o hook durante swaps; se o hook bloquear, o swap reverte. Isto não previne o ataque mecanicamente.
• Nível da UI: Raydium marca pools com mints transfer-hook.
• Nível do integrador: agregadores devem pular mints transfer-hook por padrão e permitir apenas hooks verificados.

​

Postura do Raydium

Raydium não bane pools transfer-hook (hooks legítimos existem), mas as marca claramente. Agregadores filtrando tags.includes("TRANSFER_HOOK") podem excluir se desejado.

​

5. Exploits de composição / CPI

​

Ataque

Um programa compõe Raydium via CPI e introduz um bug: ex., passa o observation_state errado, os tick arrays errados para um swap CLMM, ou gasta duplo uma conta. Atacante identifica a composição bugada e explora.

​

Exposição

• O integrador bugado — geralmente a fonte do bug.
• Raydium — apenas se o bug dispara comportamento não intencional nos próprios programas Raydium.

​

Exemplos históricos

Nenhum dos programas do Raydium foi explorado via CPI — validadores de conta do Raydium capturam contas mal-formadas e revertam. Exploits no ecossistema mais amplo aconteceram via bugs de programa customizado que compuseram com um AMM mas não originaram do AMM.

​

Defesas

• Programas chamadores devem usar os helpers CPI do Anchor (não instruções construídas manualmente) quando possível — segurança de tipo captura a maioria dos maus usos.
• Testes de integração contra estado forked de mainnet cobrem os casos de composição.

​

6. Comprometimento de admin / chave

​

Ataque

Uma chave admin (autoridade de upgrade, admin de AmmConfig, reivindicação de taxa do protocolo) é comprometida. Atacante implanta um upgrade malicioso que drena pools, ou modifica AmmConfigs para rotear taxas para uma carteira do atacante, ou drena taxas do protocolo.

​

Exposição

Todos os papéis documentados em security/admin-and-multisig.

​

Defesas

• Multisig 3/4 na autoridade de upgrade requer comprometer 4 signatários independentes.
• Timelock de 24 horas em upgrades dá aos usuários tempo para desfazer antes que um upgrade malicioso seja ativado.
• Monitoramento operacional — alertas em qualquer atividade de multisig via fila pública do Squads.

​

Incidente histórico

A chave de autoridade do pool AMM v4 foi comprometida em dezembro de 2022 (pré-multisig). Correção: moveu toda a autoridade para multisig Squads. Pós-correção, nenhum incidente.

​

7. Ataques econômicos na matemática de tick do CLMM

​

Ataque

Um atacante sofisticado explora arredondamento ou casos extremos de contabilidade de taxas na matemática de tick do CLMM. Exemplos que foram encontrados em outras implementações de CLMM (não Raydium):

• Contabilidade de crescimento de taxa que arredonda contra o usuário, acumulando pó.
• Cruzamento de tick que credita/debita o delta de fee_growth errado.
• Overflow de inteiro em produtos sqrtPrice * liquidity.

​

Exposição

Matemática customizada complexa. Auditorias e fuzzing são a defesa primária.

​

Postura do Raydium

CLMM teve duas auditorias independentes (OtterSec + MadShield) mais fuzzing baseado em propriedades contínuo. Nenhum bug com impacto em produção encontrado até agora. A aritmética sqrt_price_x64 Q64.64 usa matemática de 128-bit saturante com testes unitários cobrindo ticks de limite.

​

8. Confusão de position-NFT

​

Ataque

Um usuário é enganado a assinar uma transação que transfere seu NFT de posição CLMM para um atacante. O atacante agora é dono da liquidez da posição.

​

Exposição

Qualquer detentor de position NFT.

​

Defesas

• UIs de carteira devem reconhecer position NFTs do Raydium e exibi-los distintamente (não como NFTs genéricos para “enviar”).
• Usuários devem desconfiar de assinar transações que transferem NFTs.

​

Postura do Raydium

Position NFTs implementam o padrão de metadados do Metaplex; aplicativos de carteira que entendem posições CLMM as exibem como posições de liquidez em vez de NFTs comercializáveis. A maioria das grandes carteiras Solana as exibem especialmente a partir de 2026.

​

9. Manipulação de fluxo de recompensa de farm

​

Ataque

Um criador de farm financia o cofre de recompensas, atrai stakers, depois chama restartRewards com parâmetros que tornam a computação de recompensa pendente wonky, roubando valor de colheita.

​

Exposição

Farms com criadores maliciosos. Farm v6 limita fortemente os poderes do criador; este ataque não funciona.

​

Defesas

As instruções admin do Farm v6 (setRewards, restartRewards, addReward) preservam direitos pro-rata — a reward_per_share é ajustada no momento da mudança, então nenhuma acumulação pré-mudança é retroativamente corrompida.

​

Postura do Raydium

A auditoria de farm do OtterSec testou especificamente cenários de restart-rewards; nenhuma exploração encontrada.

​

10. Divergência de simulação vs execução

​

Ataque

Um atacante constrói uma transação que simula com sucesso mas reverte na execução (ou vice-versa). Usado para afligir carteiras que dependem de simulação para exibição.

​

Exposição

Carteiras mostrando “você receberá X” baseado em simulação.

​

Defesas

• Use simulateTransaction com o mesmo blockhash da submissão real.
• Exiba saída esperada como ”≈” (aproximadamente) não exato.
• Re-simule imediatamente antes de submissão.

​

Postura do Raydium

A simulação CLMM é determinística dado o estado atual do pool; divergência só acontece se o estado muda entre simulação e execução (caso normal, tratado via limites de slippage).

​

Tabela de resumo

​

O que usuários podem fazer

• Padrão para slippage apertado; aumente apenas quando necessário.
• Use carteiras / fluxos de swap habilitados para Jito.
• Verifique extensões de mint antes de LP.
• Monitore multisig Squads para upgrades pendentes.
• Diversifique entre pools; não concentre todo seu LP em um pool de novo lançamento.

​

O que integradores podem fazer

• Use TWAPs de ObservationState para precificação de derivativos.
• Valide restrições de conta ao compor via CPI.
• Filtre pools por campo tags (pule scam, honeypot, transfer-hook não verificado).
• Defina limites de slippage razoáveis; não aceite slippage 0 da entrada do usuário.
• Use simulateTransaction com cuidado — documente que é uma estimativa.

​

Referências

• security/oracle-and-token-risks — Riscos do Token-2022 em profundidade.
• security/admin-and-multisig — estrutura de autoridade.
• security/disclosure — programa de bug-bounty.
• integration-guides/routing-and-mev — mitigações de MEV.

Fontes:

• Rekt News — post-mortems DeFi informando esta lista.
• Relatórios de auditoria vinculados em security/audits.