Ir para o conteúdo
Financial Context Wiki

Como funcionam os programas de bug bounty em cripto

Um bug bounty de cripto é um processo versionado de divulgação e recompensa cujo escopo, autorização, evidências, severidade, remediação, divulgação e pagamento devem ser auditados separadamente.

Atualizado

Somente para fins educacionais; não constitui aconselhamento jurídico, tributário ou de segurança. Um programa publicado, uma cláusula de proteção, uma classificação de severidade ou uma recompensa estimada não garantem autorização, imunidade, pagamento nem segurança do protocolo.

Resposta direta

Um bug bounty de cripto é um processo versionado no qual um projeto convida relatos privados sobre vulnerabilidades específicas e pode recompensar os que atendam às regras vigentes. Não é o mesmo que uma política de divulgação de vulnerabilidades: esta pode oferecer canal e termos de autorização sem prometer pagamento. Nenhum deles certifica segurança, funciona como seguro ou cria vínculo empregatício.

O objeto que controla a análise é uma cópia datada do programa, não o nome do projeto nem a página atual. Registre URL, revisão e horário; redes, contratos, implementações de proxy, repositórios, commits e versões exatos; impactos elegíveis; sistemas e métodos excluídos; tabela e teto de recompensa; regras de envio e divulgação; cláusula de proteção; e condições de identidade, sanções, tributos e pagamento. O escopo é a interseção de ativo, versão, rede, impacto e método permitido.

A cláusula de proteção pode indicar como a organização pretende tratar pesquisas de boa-fé que sigam suas regras. Ela não amplia o escopo, vincula terceiros ou autoridades, prevalece sobre outras jurisdições nem justifica invasão de privacidade, interrupção, extorsão ou movimentação não autorizada de fundos. Se a autorização for ambígua, pergunte pelo canal oficial antes de testar.

Mantenha quatro registros separados: autorização e evidências; explorabilidade técnica e impacto econômico; mitigação, remediação e divulgação; e recompensa, conformidade e pagamento. A etiqueta critical não determina sozinha a recompensa, a decisão de concedê-la não é recibo de pagamento e um patch aprovado em um teste unitário não prova que a implantação afetada é segura.

Como funciona

Os testes devem permanecer dentro das regras arquivadas. Uma prova de conceito mínima costuma avançar de análise estática e testes unitários ou de propriedades para um fork local ou outro ambiente expressamente autorizado. Testes em mainnet, testnet pública, negação de serviço, engenharia social, terceiros ou dados pessoais podem ser proibidos. Não transfira nem retenha ativos reais de usuários para demonstrar impacto e não presuma que um resgate durante ataque ativo esteja autorizado por um bounty comum.

Um bom relatório fixa rede, endereço, implementação, commit, bloco de estado e cópia do programa afetados. Informa pré-requisitos, passos exatos, comportamento esperado e observado, sequência de transações ou calldata, hashes dos artefatos, caminho técnico, limite realista do impacto, capital e privilégios do atacante, premissas e contato seguro. Criptografe material utilizável em ataques e dados sensíveis, minimize a coleta, registre acessos e preserve a cronologia.

A triagem deve separar escopo, duplicidade ou problema conhecido, explorabilidade técnica, impacto econômico, severidade e elegibilidade. Uma classe técnica não determina perda executável. Capital, permissões, concorrência, liquidez, janelas de oráculo, limites, pausas, reorganizações, repetibilidade e interação do usuário alteram o resultado. A primeira mensagem não é necessariamente o primeiro relato completo elegível; prevalecem a regra arquivada de duplicidade e a prova de conhecimento prévio.

Confirmação, reprodução, decisão de severidade, mitigação emergencial, remediação final, divulgação, aprovação e pagamento são estados e relógios distintos. Metas como 24 hours ou 72 hours só têm sentido quando definidas pelo programa ou plano de incidentes. O silêncio prejudica a operação, mas a expressão bug bounty não cria prazo universal.

Uma ação emergencial pode pausar função, reduzir limite, remover rota do frontend ou alterar monitoramento, mas não é correção definitiva. Um upgrade deve verificar autorização, timelock ou poderes emergenciais, implementação e inicializador, layout de armazenamento, migração e reversão. Transforme a prova original em teste de regressão, investigue caminhos e invariantes adjacentes, simule o estado implantado, confira recibos e monitore as versões efetivas em todas as redes afetadas.

A divulgação precisa de canal privado, início do embargo, cadência de atualizações, regras de extensão e publicação emergencial, crédito ou anonimato e termos de retenção ou exclusão de evidências. O pagamento requer conciliação própria: valor nominal, fórmula ou discricionariedade, moeda e referência cambial, KYC ou sanções, documentos tributários ou retenção, rede e endereço de destino, taxas, aprovação, identificador da transação e valor recebido.

Use este fluxo:

  1. Salve o programa: URL, revisão e horário, ativos, redes, endereços, implementações, commits, impactos elegíveis, exclusões, recompensa, proteção e política de divulgação.
  2. Obtenha autorização escrita para pesquisador, sistema, ambiente, método, taxa, tratamento de dados e limite de terceiros; pare e pergunte diante de qualquer dúvida.
  3. Construa a menor prova não prejudicial no ambiente permitido; fixe código e estado, quantifique pré-requisitos e impacto e pare quando houver evidência suficiente.
  4. Envie pelo canal seguro autorizado com ID, horários, artefatos criptografados, hashes, passos, registro de impacto, premissas e histórico de contatos.
  5. Determine escopo e situação de duplicidade ou conhecimento prévio; avalie separadamente explorabilidade, impacto econômico, severidade e elegibilidade pelas regras salvas.
  6. Acompanhe como estados distintos mitigação, patch ou migração, revisão de upgrade e armazenamento, regressão e invariantes, recibos, monitoramento e divulgação coordenada.
  7. Concilie recompensa aprovada, moeda e câmbio, KYC, sanções, tributos, rede, endereço, taxas e recibo; retenha trilha auditável sem dados sensíveis desnecessários.

Exemplos

  • O escopo é menor que a coincidência de nomes. Um programa salvo lista 12 assets. O relato cita 9; apenas 7 correspondem à rede e versão implantada, enquanto um é oráculo de terceiro e outro commit não lançado. A coincidência nominal é 9 / 12 = 75%, mas a cobertura autorizada é 7 / 12 = 58.33333333%. A cópia, não o percentual, decide a elegibilidade.
  • Impacto, severidade e recompensa candidata são distintos. O valor direto reproduzível em risco é $8,000,000. Uma regra hipotética salva paga 10%, com piso de $50,000 e teto de $500,000. O cálculo bruto é $8,000,000 * 0.10 = $800,000; após o teto, a candidata é $500,000. Exigir signatário privilegiado pode mudar a faixa; o cálculo não é direito adquirido nem fórmula universal.
  • Cada relógio mede um estado. Envio 2026-08-13 09:00; confirmação às 11:30 leva 2.5 hours; triagem em 2026-08-14 16:00 leva 31 hours; limite temporário às 21:00 leva 36 hours; patch em 2026-08-16 21:00 leva 84 hours; divulgação em 2026-08-23 09:00 leva 240 hours, ou 10 days. Confirmação rápida não implica remediação ou pagamento rápidos.
  • Recompensa nominal e liquidação são separadas. Uma recompensa aprovada de $500,000 é paga em USDC a $1.002 per USDC; são devidos $500,000 / $1.002 = 499,001.996008 USDC. Se o projeto pagar separadamente $18 de taxa, o pesquisador recebe 499,001.996008 USDC; se descontar, o valor recebido é $499,982 no câmbio fixado. Tributos e retenções são lançamentos separados.

Riscos

  • A página muda e não há cópia datada.
  • Ativo, versão, rede, endereço ou implementação testados estão fora do escopo.
  • Um upgrade do proxy altera o código durante pesquisa ou remediação.
  • A cláusula de proteção é confundida com imunidade jurídica universal.
  • O teste alcança fornecedor, oráculo, usuário ou terceiro excluído.
  • A atividade em mainnet ou testnet pública viola as regras do ambiente.
  • A prova move fundos reais, interrompe serviço ou acessa dados pessoais.
  • A automação excede limites de carga ou vira negação de serviço.
  • Engenharia social, phishing, coação ou extorsão excedem a autorização.
  • A prova coleta ou expõe mais material ofensivo que o necessário.
  • Um canal inseguro vaza segredos, dados de usuários ou detalhes do exploit.
  • Hashes, horários, versões de código ou estado da rede não são reproduzíveis.
  • Faltam evidências de duplicidade, conhecimento prévio ou primeiro relato elegível.
  • O nome da falha ancora a severidade sem testar pré-requisitos e alcance.
  • Valor teórico em risco é confundido com perda realizável ou lucro do atacante.
  • Piso, teto, discricionariedade, moeda ou elegibilidade são mal interpretados.
  • KYC, sanções, tributos, fatura ou rede atrasam ou impedem a liquidação.
  • Silêncio, relógios ambíguos ou divulgação prematura elevam o risco.
  • Pausa, limite, upgrade, mudança de armazenamento ou migração causam novo dano.
  • Bounty, auditoria, prova formal ou monitoramento são tratados como garantia.

Erros comuns

  • “Um programa público autoriza qualquer ativo e método relacionado.” A autorização é limitada por ativo, versão, impacto, ambiente e conduta salvos.
  • “A cláusula de proteção garante imunidade em toda jurisdição.” É uma política condicional e não vincula todos os terceiros ou autoridades.
  • “Uma classificação crítica ou percentual fixa automaticamente o pagamento.” Severidade, elegibilidade, regras, tetos, discricionariedade e liquidação são distintos.
  • “A primeira mensagem sempre vence duplicidade, e mover fundos prova impacto.” Pode ser exigido o primeiro relato completo elegível; dano não autorizado pode desqualificar e gerar responsabilidade.
  • “Bounty e auditoria provam ausência de bugs depois que o patch passa.” Auditorias, métodos formais, testes, bounties, monitoramento e resposta cobrem versões, premissas e falhas diferentes.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...