> ## 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.

# Divulgação responsável

> Programa de bug bounty do Raydium: escopo (apenas código de programa on-chain), níveis de severidade e recompensas, caminhos de contato (Immunefi ou email de segurança), estrutura de pagamento, além do canal não-bounty para relatar problemas de SDK / API / UI.

<Info>
  **Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.**

  [Ver versão em inglês →](/security/disclosure)
</Info>

<Info>
  O Raydium executa um programa de bug bounty ativo **cobrindo apenas o código de programa on-chain** — os smart contracts Solana nos IDs de programa listados em [`reference/program-addresses`](/pt/reference/program-addresses). O programa está ativo no Immunefi desde 25 de abril de 2023. Os pagamentos variam conforme a severidade e o impacto econômico, chegando a \$505.000 no topo do nível crítico.

  **O SDK, APIs REST e frontend (raydium.io) não fazem parte do bounty.** Problemas lá não geram pagamento, mas relatórios ainda são bem-vindos — veja [Relatórios não-bounty (SDK / API / UI)](#relatórios-não-bounty-sdk-api-ui) abaixo para o caminho de contato.

  Esta página é a fonte oficial do que o bounty cobre, como relatar e o que esperar do processo de resposta.
</Info>

## Escopo

### Dentro do escopo do bounty (com pagamento)

O bounty se aplica **apenas ao código de programa on-chain implantado**:

* **Programas implantados** nos IDs de programa em [`reference/program-addresses`](/pt/reference/program-addresses):
  * AMM v4 (`675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`)
  * CPMM (`CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C`)
  * CLMM (`CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK`)
  * Stable AMM (`5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h`)
  * LaunchLab (`LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj`)
  * Farm v3 / v5 / v6
  * LP-Lock / Burn & Earn (`LockrWmn6K5twhz3y9w1dQERbmgSaRkfnTeTKbpofwE`)
  * AMM Routing
* **Bugs de composabilidade CPI de smart contract** onde o uso correto de um programa Raydium por um programa que o compõe causa mau funcionamento do próprio programa Raydium.

### Fora do escopo do bounty (bem-vindo relatar — veja abaixo)

* **Raydium SDK v2** (`@raydium-io/raydium-sdk-v2`) no npm.
* **APIs REST** (todos os hosts listados na aba [API Reference](/pt/api-reference) — `api-v3.raydium.io`, `transaction-v1.raydium.io`, `launch-*-v1.raydium.io`, etc.).
* **Frontend** (`raydium.io`) — incluindo XSS, CSRF, bugs de fluxo de autenticação, spoofing de carteira, estados de UI quebrados.
* **Indexadores off-chain, gateways de imagem / IPFS e qualquer outra infraestrutura** que fornece dados para a UI.

Estes não geram pagamento. Relatórios ainda são bem-vindos e úteis — envie-os através do [canal não-bounty](#relatórios-não-bounty-sdk-api-ui) abaixo.

### Fora de escopo (não elegível)

* Programas de terceiros que se compõem com Raydium (reporte aos seus times).
* Agregadores de terceiros que roteiam através do Raydium (ex: Jupiter).
* Ferramentas off-chain **não mantidas pelo Raydium** (SDKs comunitários em Python, bots de terceiros, etc.).
* Ataques de engenharia social contra membros do time Raydium.
* Qualquer descoberta que exija conluio do lado do validador ou ataques de stake majoritário (isto é camada Solana, não alvo de bounty DeFi).
* DoS via spam em endpoints RPC públicos.
* Saídas de ferramentas de scanning automatizado sem prova de conceito funcional.

**Exclusões específicas do programa (conforme a listagem Immunefi):**

* **Dependências AMM v4 / OpenBook** — bugs pertencentes a dependências OpenBook não estão no escopo. AMM v4 está definido como Status 6, então a liquidez não é mais compartilhada com mercados OpenBook.
* **Descobertas já sinalizadas em revisões de segurança anteriores** não são elegíveis: a revisão Ottersec do CLMM, e as revisões Kudelski, Ottersec e MadShield do programa Hybrid AMM. Re-relatar um problema já divulgado não gera pagamento.
* **Falha de reivindicação de yield CLMM por design** — o CLMM emite tokens de taxa de negociação e yield de farming para LPs. Se um atacante drenasse o vault ou tokens de taxa, os usuários seriam incapazes de reivindicar yield e as transações falhariam. Isto é por design e **não** é considerado uma vulnerabilidade.

### Zona cinzenta — discuta primeiro

* Bugs em primitivos de resistência a MEV que interagem com infraestrutura externa.
* Casos extremos de integração Token-2022 onde o comportamento "correto" é ambíguo.
* Ataques econômicos / teórico-dos-jogos que não mapeiam claramente para um bug de código.

Quando incerto, erre no lado de relatar.

## Severidade e recompensas

Relatórios são classificados usando o [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/), sob um modelo de **Primacy of Rules**: os termos nesta página e a listagem Immunefi governam e têm precedência sobre a classificação padrão onde diferem. Recompensas são denominadas em USD e pagas pelo time Raydium em **RAY, SOL ou USDC**.

Os níveis de recompensa de smart contract são:

| Severidade  | Recompensa                                                                                    |
| ----------- | --------------------------------------------------------------------------------------------- |
| **Crítica** | **10% dos fundos diretamente afetados**, limitado a **\$505.000**, com **mínimo de \$50.000** |
| **Alta**    | **\$5.000–\$40.000**                                                                          |
| **Média**   | **\$5.000 fixo**                                                                              |

Não há nível pago separado abaixo de Média. O mínimo crítico de \$50.000 existe especificamente para desencorajar pesquisadores de reterem um relatório quando os fundos diretamente afetados são pequenos.

### Cálculo de recompensa crítica

Para ativos em mainnet, a recompensa crítica é **10% dos fundos diretamente afetados**, até um máximo de **\$505.000**. Se 10% dos fundos em risco cair abaixo de **\$50.000**, o relatório ainda paga o **mínimo de \$50.000**. O limite e a base de 10%-de-fundos-em-risco se aplicam a relatórios críticos de smart contract.

### Impactos no escopo

O bounty usa a taxonomia de impacto padronizada do Immunefi. Exemplos específicos do Raydium são fornecidos para ilustrar como cada impacto mapeia para os programas.

**Crítica**

* **Roubo direto de qualquer fundo do usuário**, em repouso ou em movimento, exceto yield não reivindicado — ex: drenar fundos LP de um usuário via uma instrução Raydium válida, ou uma cunhagem ilimitada de tokens LP.
* **Congelamento permanente de fundos** — ex: corromper a contabilidade do pool para que fundos se tornem permanentemente irrecuperáveis.
* **Vulnerabilidades que poderiam congelar fundos do usuário permanentemente, ou que drenem ou roubem fundos sem aprovação de transação do usuário** — ex: contornar a autoridade de upgrade do programa, ou um bug de roubo-todas-as-taxas-do-protocolo.

**Alta**

* **Roubo de yield não reivindicado** — ex: roubar recompensas pendentes de farms ou posições CLMM.
* **Congelamento permanente de yield não reivindicado**.
* **Congelamento temporário de fundos por qualquer período de tempo** — ex: congelar a posição de um usuário para que não possa fechá-la via tx maliciosa.
* **Vulnerabilidades que poderiam congelar fundos do usuário temporariamente ou alterar intencionalmente o valor dos fundos do usuário** — ex: manipular a matemática do pool ou contornar proteção de slippage.

**Média**

* **Smart contract incapaz de operar devido à falta de fundos de token**.
* **Block stuffing para lucro**.
* **Griefing** (sem motivo de lucro para o atacante, mas dano aos usuários ou ao protocolo) — ex: DoS griefável onde todos os swaps em um pool revertam.
* **Roubo de gas**.
* **Consumo de gas ilimitado**.

## Caminhos de contato

### Primário: Immunefi

O bug bounty do Raydium está listado no [Immunefi](https://immunefi.com/bug-bounty/raydium/information/). Reporte através da plataforma Immunefi:

1. Crie uma conta Immunefi.
2. Navegue até a página do bounty Raydium.
3. Envie a descoberta com um PoC completo. **Uma prova de conceito é obrigatória para todas as severidades** — explicações e declarações não são aceitas, código funcional é obrigatório. Relatórios Críticos e Altos também devem incluir uma correção sugerida.
4. Relatórios são tratados rapidamente — o tempo mediano de resolução do programa é \~1 dia.

**Pagamentos são tratados pelo time Raydium diretamente**, não por escrow Immunefi — denominados em USD e pagos em RAY, SOL ou USDC. **Nenhum KYC é obrigatório** para processamento de pagamento.

### Alternativa: envio por email

Descobertas no escopo do bounty também podem ser enviadas por email em vez de (ou além de) Immunefi:

* `security@raydium.io`
* `security@reactorlabs.io`

Inclua um PoC funcional completo, e para relatórios Críticos / Altos uma correção sugerida, assim como no Immunefi. Criptografe detalhes sensíveis com a chave PGP do time se necessário — peça no email e o time trocará chaves. Não envie a mesma descoberta através de múltiplos canais ao mesmo tempo (escolha Immunefi *ou* email).

### Direto (para descobertas críticas e sensíveis ao tempo)

Se a descoberta está sendo explorada ativamente ou é iminente e você não pode esperar pela triagem Immunefi, o caminho secundário mais rápido é:

* **Email direto** para `security@raydium.io` ou `security@reactorlabs.io` — o caminho mais rápido para alcançar o time diretamente; sinalize a linha de assunto como um exploit ativo.
* **Botão de emergência Immunefi** na página do bounty — escala em minutos durante horário comercial.
* **Contato criptografado através do Immunefi** — Immunefi pode retransmitir uma mensagem criptografada ponta-a-ponta para o time Raydium.

Evite canais públicos (X / Twitter, Telegram, Discord) para relatórios de segurança — a própria divulgação pode desencadear exploração. Use Immunefi ou os emails de segurança acima tanto para o relatório quanto para qualquer contato de acompanhamento.

### Relatórios não-bounty (SDK / API / UI)

Para problemas em componentes **fora do bounty** — o SDK, as APIs REST, o frontend `raydium.io`, ou qualquer infraestrutura off-chain — não há pagamento, mas o time ainda quer ouvir sobre eles. Use:

* **Email**: `security@raydium.io` ou `security@reactorlabs.io` para qualquer coisa com implicações de segurança (XSS, CSRF, vazamentos de fluxo de autenticação, replay de mensagem assinada, spoofing de carteira, dados sensíveis expostos por uma API, etc.). Criptografe com a chave PGP do time se o bug for sensível; peça no email e o time trocará chaves.
* **Issues GitHub**: para bugs funcionais não-segurança no SDK, na documentação, ou em qualquer repositório open-source mantido pelo Raydium. Abra uma issue no repositório relevante (ex: [`raydium-io/raydium-sdk-V2`](https://github.com/raydium-io/raydium-sdk-V2)).
* **Discord** (`discord.gg/raydium`): adequado para feedback de UI / UX de baixo impacto que não toca segurança. **Não** poste nada que pudesse habilitar um exploit se lido por um estranho.

O que você recebe de relatórios não-bounty:

* **Reconhecimento** na resposta dentro de alguns dias úteis.
* **Coordenação entre repositórios** se a correção abrange o programa e o SDK.
* **Crédito público** (com seu consentimento) nas notas de lançamento ou changelog relevante.
* **Relatores repetidos de descobertas substantivas** às vezes são convidados para um programa de contribuidor; esse caminho é separado do bounty on-chain e é oferecido em base discricionária.

O que você não recebe:

* Um pagamento em escala, independentemente da severidade. O bounty é para descobertas de código de programa.
* Cobertura sob a política de safe harbor abaixo — essa política especificamente se refere a pesquisa no escopo do bounty. Para testes de SDK / API / UI, siga convenções de divulgação responsável normais e termos de serviço padrão.

## Regras de engajamento

### Faça

* **Teste apenas contra um fork local** de mainnet ou testnet público. Todo trabalho de prova de conceito deve ser feito em um fork local.
* Inclua um PoC funcional no relatório (obrigatório para todas as severidades).
* Estime o impacto econômico do melhor de seu conhecimento.
* Proponha uma correção — obrigatório para relatórios Críticos e Altos.

### Não faça

* **Teste em mainnet ou código implantado em testnet público.** Qualquer teste assim é proibido; use apenas forks locais.
* **Teste com oráculos de preço ou smart contracts de terceiros**, ou com sistemas, aplicações, extensões de navegador ou websites de terceiros.
* Divulgue publicamente a vulnerabilidade antes de uma correção ser implantada (divulgação pública de um bug não corrigido em um bounty embargado é proibida).
* Execute testes automatizados que geram tráfego significativo, ou qualquer ataque de negação de serviço contra ativos do projeto.
* Tente phishing ou outra engenharia social contra membros do time Raydium ou usuários.
* Envie a mesma descoberta através de mais de um canal ao mesmo tempo — escolha Immunefi *ou* email, não ambos, e nunca via DMs públicos.

Estes seguem as [Regras Immunefi](https://immunefi.com/rules/); violações invalidam o bounty.

## Cronograma de resposta

O programa tem **tempo mediano de resolução de cerca de 1 dia** (conforme a listagem pública Immunefi). As fases abaixo são indicativas de como um relatório progride; SLAs exatos são governados pela listagem Immunefi e processo de triagem, não por esta página:

| Fase                        | Tempo indicativo                         |
| --------------------------- | ---------------------------------------- |
| Triagem inicial             | \~1 dia (mediano)                        |
| Classificação de severidade | Alguns dias úteis                        |
| Desenvolvimento de correção | Depende de severidade + complexidade     |
| Implantação de correção     | Sujeito ao timelock do programa on-chain |

Para descobertas críticas, a trilha de correção se acelera: o time convoca o multisig, redige uma correção, submete para revisão e enfileira a implantação timelocked.

## O que não divulgar publicamente

Até uma correção ser implantada e o time Raydium ter coordenado divulgação com você:

* Não tuíte sobre a descoberta (mesmo vago "encontrei algo grande").
* Não descreva a classe de bug para terceiros.
* Não compartilhe código PoC com ninguém fora do time de triagem do Raydium.

Após implantação de correção + janela de divulgação coordenada:

* Writeups públicos são bem-vindos e encorajados.
* Raydium fará cross-promote de writeups substantivos.
* Pesquisadores que consentem em ser nomeados são creditados no [Immunefi Whitehat Hall of Fame](https://immunefi.com/hall-of-fame/).

## Política de safe harbor

Pesquisa conduzida dentro do escopo e regras acima é explicitamente autorizada. Raydium:

* Não buscará ação legal por pesquisa de boa fé que segue esta política.
* Não interferirá com atividades de pesquisa (ex: colocar carteiras de pesquisadores na lista negra).
* Colaborará no entendimento da descoberta.

Pesquisa *fora* do escopo ou regras não é protegida por safe harbor. Se seu plano de pesquisa é borderline, pergunte via canal "Ask Project" do Immunefi antes de testar.

## Divulgações notáveis anteriores

Estatísticas agregadas para o **bounty de código de programa**, que está ativo no Immunefi desde 25 de abril de 2023 (figuras conforme a listagem pública Immunefi):

* Recompensas totais pagas até agora: \~\$3,4M.
* Tempo mediano de resolução: \~1 dia.

O Immunefi Whitehat Hall of Fame lista pesquisadores que consentiram em ser nomeados. Relatórios não-bounty (SDK / API / UI) são rastreados separadamente e reconhecidos nas notas de lançamento do repositório relevante em vez de no Immunefi.

## Programas relacionados

* **Solana Foundation Bug Bounty** — cobre bugs do cliente validador Solana (sealevel, consensus). Reporte lá para problemas de camada Solana. [solana.com/security](https://solana.com/security).
* **Squads Protocol Bug Bounty** — cobre o próprio multisig. [squads.so/security](https://squads.so/security).
* **Immunefi** — cobre muitos protocolos DeFi incluindo Raydium. [immunefi.com](https://immunefi.com).

Um bug que abrange camadas (ex: um bug de validador Solana que se manifesta no Raydium) deve ser reportado a todos os programas aplicáveis.

## Referências

* [`security/audits`](/pt/security/audits) — histórico de auditorias anteriores.
* [`security/admin-and-multisig`](/pt/security/admin-and-multisig) — estrutura de autoridade.
* [`security/attack-vectors`](/pt/security/attack-vectors) — classes de ataque conhecidas.

Fontes:

* [Página do bounty Raydium no Immunefi](https://immunefi.com/bug-bounty/raydium/information/) — escopo canônico, termos de pagamento e caminho de contato.