Vetores de ataque

​

1. Ataques sandwich / MEV

​

Ataque

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

​

Exposição

• Mais exposto: pools CPMM de baixo TVL e pools AMM v4 — até mesmo pequenos trades movem o preço significativamente.
• Menos exposto: pools CLMM profundos — trades dentro do tick não movem o preço.
• Não exposto: colheitas de farm, depósitos de LP (proporção imposta, não sensível ao preço da mesma forma).

​

Defesas

• Jito bundles (integration-guides/routing-and-mev) ocultam a 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 — divida um swap de $100k em 10× $10k; cada um move o preço menos.

​

Postura do Raydium

Os programas principais do Raydium não impõem 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 grande trader move temporariamente o preço de um pool (por um flash loan ou auto-financiado), dispara alguma ação downstream que depende do preço (uma liquidação, um empréstimo derivado de oráculo, um pagamento de derivativo) e 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: exposto se lerem o preço do pool Raydium ingenuamente.

​

Defesas

• Use TWAPs, não preços spot, para composabilidade (veja security/oracle-and-token-risks).
• CLMM ObservationState fornece um 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 fornece suporte TWAP ObservationState; integradores que o ignoram e usam preços spot estão por conta própria. 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 quantidade minúscula (por exemplo, 1 token cada de mints de 6 decimais → 1 unidade de LP emitida). Depois o atacante “doa” 1.000.000 de tokens diretamente para o vault do pool via transferência SPL Token. Agora 1 unidade de LP representa 500.000 de cada mint. Qualquer LP subsequente depositando menos do que isso é arredondado para 0 unidades de LP e perde seu depósito.

​

Exposição

• CPMM / AMM v4: potencialmente exposto em pools recém-criados de 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 (inspirada no padrão MINIMUM_LIQUIDITY do Uniswap V2). Isso significa que o primeiro LP recebe sqrt(x × y) - MINIMUM_LIQUIDITY, com o MINIMUM_LIQUIDITY (1000 unidades) queimado para nulo. Um ataque de doação requer que o atacante doe >> o depósito inicial, o que se torna não econômico. Além disso, o SDK do Raydium avisa fortemente quando o depósito inicial é minúsculo e orienta os usuários para quantidades sensatas.

​

Postura do Raydium

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

​

4. Abuso de transfer-hook Token-2022

​

Ataque

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

​

Exposição

Pools que incluem um mint com transfer-hook.

​

Defesas

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

​

Postura do Raydium

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

​

5. Exploits de composabilidade / CPI

​

Ataque

Um programa compõe Raydium via CPI e introduz um bug: por exemplo, 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 — os validadores de conta do Raydium pegam 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 — type-safety pega a maioria dos usos indevidos.
• Testes de integração contra estado mainnet-forked cobrem os casos de composição.

​

6. Compromisso de admin / chave

​

Ataque

Uma chave de admin (upgrade authority, AmmConfig admin, protocol fee claim) é comprometida. Atacante implanta uma atualização maliciosa que drena pools, ou modifica AmmConfigs para rotear taxas para uma carteira de atacante, ou drena taxas de protocolo.

​

Exposição

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

​

Defesas

• Multisig 3/4 na upgrade authority requer comprometer 4 signatários independentes.
• Timelock de 24 horas em upgrades dá aos usuários tempo para se desfazer antes de uma atualização maliciosa ativar.
• Monitoramento operacional — alertas em qualquer atividade multisig via fila pública do Squads.

​

Incidente histórico

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

​

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

​

Ataque

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

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

​

Exposição

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

​

Postura do Raydium

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

​

8. Confusão de posição-NFT

​

Ataque

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

​

Exposição

Qualquer detentor de NFT de posição.

​

Defesas

• UIs de carteira devem reconhecer NFTs de posição Raydium e exibi-los distintamente (não como NFTs genéricos para “enviar”).
• Usuários devem ser cautelosos ao assinar transações que transferem NFTs.
• Uma nova posição é congelada apenas quando usa um caminho aberto V2 e a autoridade de congelamento do mint de vault subjacente corresponde à lista de issuer restrito do CLMM. Essa posição correspondente não pode ser transferida ou ter seu proprietário de token-account alterado; todas as outras novas posições permanecem transferíveis.

​

Postura do Raydium

NFTs de posição 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 negociáveis. A maioria das carteiras Solana principais as exibem especialmente a partir de 2026. Congelamento de issuer restrito é direcionado e não protege posições transferíveis ordinárias.

​

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

​

Ataque

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

​

Exposição

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

​

Defesas

As instruções de admin do Farm v6 (setRewards, restartRewards, addReward) preservam direitos pro-rata — o reward_per_share é ajustado 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 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 atormentar 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 da submissão.

​

Postura do Raydium

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 fluxos de carteira / 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 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.

​

Ponteiros

• security/oracle-and-token-risks — Riscos 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.