> ## 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. # Vetores de ataque > Padrões de ataque conhecidos contra AMMs e exposições específicas do Raydium — sandwich/MEV, manipulação de preço, ataques de doação, abuso de hooks do Token-2022, bugs de composição — incluindo como o Raydium se defende contra cada um. **Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.** [Ver versão em inglês →](/security/attack-vectors) 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`](/pt/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`](/pt/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`](/pt/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 | Vetor | Específico do Raydium | Defendido em | Risco residual para usuários | | ------------------------ | --------------------- | ------------------------------------ | -------------------------------- | | Sandwich / MEV | Sim | Camada de submissão (Jito, slippage) | Baixo se Jito usado | | Manipulação de preço | Apenas composição | Use TWAPs | Baixo se TWAP consumido | | Ataque de doação | CPMM | MINIMUM\_LIQUIDITY | Baixo | | Abuso de transfer-hook | Pools Token-2022 | Marcas de UI | Médio para hooks não verificados | | Exploits de CPI | Bugs de integradores | Validadores Raydium revertam | Baixo (bug fica no integrador) | | Comprometimento de admin | Todos os programas | Multisig + timelock | Baixo (24h para reagir) | | Matemática de tick CLMM | CLMM | Auditorias + fuzzing | Baixo | | Confusão de position NFT | CLMM | UX de carteira | Baixo com carteiras modernas | | Manipulação de farm | Farm v6 | Poderes de criador limitados | Baixo | | Divergência de simulação | Qualquer | UX de carteira | Baixo | ## 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`](/pt/security/oracle-and-token-risks) — Riscos do Token-2022 em profundidade. * [`security/admin-and-multisig`](/pt/security/admin-and-multisig) — estrutura de autoridade. * [`security/disclosure`](/pt/security/disclosure) — programa de bug-bounty. * [`integration-guides/routing-and-mev`](/pt/integration-guides/routing-and-mev) — mitigações de MEV. Fontes: * [Rekt News](https://rekt.news) — post-mortems DeFi informando esta lista. * Relatórios de auditoria vinculados em [`security/audits`](/pt/security/audits).