Divulgação responsável

​

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:
  • 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 — 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 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, 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: 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. 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).
• 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; 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: 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.

​

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.
• Squads Protocol Bug Bounty — cobre o próprio multisig. squads.so/security.
• Immunefi — cobre muitos protocolos DeFi incluindo Raydium. 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 — histórico de auditorias anteriores.
• security/admin-and-multisig — estrutura de autoridade.
• security/attack-vectors — classes de ataque conhecidas.

Fontes:

• Página do bounty Raydium no Immunefi — escopo canônico, termos de pagamento e caminho de contato.