Bug Bounties de Cripto: Sendo pago por hackear blockchain

O estereótipo evocado pela palavra "hacker" é surpreendentemente resiliente: um jovem de moletom preto com capuz, encarando a tela de forma sombria em uma sala intensamente iluminada, roubando senhas de pessoas que depositaram confiança excessiva na internet. Essa imagem persistiu por décadas de cultura de segurança na vida real porque é uma maneira conveniente de transformar algo complexo em um vilão — e vilões são sempre úteis. O que geralmente se ouve menos é que alguns dos melhores hackers estão do outro lado dessa transação, encontrando brechas antes que os criminosos o façam (e sendo remunerados pelo seu trabalho). Essa prática tem um nome, uma memória institucional e uma estrutura profissional que remonta a várias décadas antes da concepção do blockchain.

O primeiro programa de bug bounty organizado e de estilo moderno foi iniciado em 10 de outubro de 1995 pela Netscape. A empresa estava trabalhando no Navigator 2.0, seu navegador líder na época, e fez uma chamada pública: encontre um bug de segurança, divulgue essa vulnerabilidade de forma responsável para a empresa e seja pago por seus esforços. Embora o orçamento fosse pequeno para os padrões atuais — US$ 50.000 distribuídos ao longo de todo o programa — a ideia em si era verdadeiramente original. A Netscape estava, na prática, admitindo publicamente que seu software tinha vulnerabilidades que não conseguia detectar internamente e que pessoas de Em meados da década de 2010, os programas de bug bounty tornaram-se comuns para qualquer empresa de tecnologia séria em relação à sua segurança, com serviços como HackerOne e Bugcrowd surgindo para facilitar esses programas em escala ao conectar empresas a pesquisadores de segurança freelancers que se dedicam à busca por vulnerabilidades em tempo integral.

No entanto, nem todas as grandes descobertas de segurança ocorreram em um programa formal de recompensas, e algumas das mais impactantes ilustraram o que pode acontecer quando eles não existem. Em 2014, duas equipes — Neel Mehta, do Google, e a equipe da empresa finlandesa Codenomicon — revelaram de forma independente uma falha grave no OpenSSL, a biblioteca criptográfica que sustenta grande parte de todo o tráfego criptografado da internet. Essa falha recém-descoberta, denominada Heartbleed, permitia que um invasor lesse a memória de um servidor (à qual não deveria ter acesso), expondo em texto simples chaves privadas, credenciais utilizadas por dezenas de milhares de serviços e dados de usuários. Não havia nenhum bug bounty para ser reivindicado. Embora a vulnerabilidade tenha sido reportada de forma responsável, ela passou mais tempo exposta entre a descoberta e a correção do que qualquer um de nós gostaria de imaginar, e o desdobramento resultou em uma mobilização global de meses por tudo, desde patches de software, atualizações de conteúdo e até mesmo encaminhamentos. O contrafactual — e se um serviço de inteligência governamental ou uma operação criminosa o tivesse descoberto antes — foi desconfortável o suficiente para apressar a implementação de programas de divulgação estruturada em toda a indústria.

Por que a Cripto Precisa de White Hats Mais do que a Maioria

Assim, o problema de segurança em blockchain é estruturalmente diferente (e fundamentalmente mais complexo) do que o problema médio de segurança de software, o que é relevante quando se trata de explicar por que os bug bounties se tornaram uma peça tão central neste cenário.

No software tradicional, uma vulnerabilidade é grave, mas limitada. A aplicação web comprometida de um banco pode vazar dados ou desencadear fraudes, mas o dano é contido em um sistema com leis, seguros, detecção de fraude e a capacidade de reverter transações ilícitas. O dinheiro possui um rastro. Um invasor não está trabalhando no vácuo.

Cenários de perda em DeFi, então: um exploit bem-sucedido (ou não) desenrola-se de forma diferente em quase todas as dimensões. Em questão de segundos, todos os fundos de um protocolo podem ser drenados se um invasor explorar uma falha de temporização no contrato inteligente. Se for bem-sucedido, o invasor terá obtido criptomoeda que não é apenas difícil de rastrear, mas quase impossível de recuperar sem a cooperação de seu proprietário. Ninguém pode desfazer a transação porque não existe uma autoridade central. A qualquer momento, bilhões de dólares repousam de forma imutável nestes contratos inteligentes de leitura pública e comportamento autônomo. Seu código é seu produto, e seu produto é um cofre. Para quase todos os mecanismos, a regra é de quem chegar primeiro, sendo o único recurso o registro inquebrável on-chain.

Isso é o que torna a dinâmica da lança contra o escudo em cripto tão urgente. A partir do momento em que você implementa qualquer protocolo que possua valor, surgem vetores de ataque desde o primeiro dia. Os atacantes não são desorganizados. Alguns estão ligados a Estados-nação, outros são empresas criminosas avançadas, e muitos outros estão simplesmente seguindo o mapa da amoralidade e se alojando em Solidity; eles têm capital disponível e vigiam como falcões o que é implantado. Esperar que os usuários abandonem o protocolo (churn) devido a problemas de segurança não é uma estratégia de negócios sustentável. Não, a única opção é encontrar essas vulnerabilidades antes que outros o façam — e contratar pessoas talentosas o suficiente para encontrá-las.

Auditoria e testes de penetração — contratar uma empresa de segurança para revisar o código antes da implantação — são necessários, mas de forma alguma suficientes. As auditorias são tipicamente limitadas no tempo (time-boxed) e realizadas por equipes de tamanho finito. Um sistema de contratos "inteligentes" pode ter milhões de caminhos potenciais para interações, e uma equipe de auditoria sob restrição de tempo cobrirá os mais óbvios. Estes programas de bug bounty levam a busca a um horizonte muito mais amplo e trabalham com um pool global de pesquisadores com diferentes formações, diferentes modelos mentais e tempo indefinido. Uma combinação de ambos — auditoria interna abrangente antes da mainnet e, em seguida, um programa de recompensas permanente — é a lição fundamental para quem prioriza a segurança de protocolos hoje em dia.

A Matemática do CEO entre Mil Dólares ou Um Milhão

< Nenhuma discussão é capaz de proporcionar a compreensão necessária para explicar essa lógica matemática antes do lançamento — todo CEO que já passou por uma exploração de grande escala entende isso visceralmente. Aqueles que ainda não passaram por isso consideram os gastos com segurança apenas como mais um custo operacional a ser minimizado para cumprir requisitos de conformidade.

Os dados de custos são fornecidos pelo histórico de explorações em DeFi. Como exemplo, apenas em 2022, a ponte da rede Ronin sofreu uma perda de US$ 625 milhões. E uma ponte diferente, a Wormhole, foi hackeada em janeiro, com um custo de US$ 320 milhões. Nomad Bridge — US$ 190 milhões perdidos, pois qualquer usuário podia esvaziar o protocolo assim que o padrão de ataque inicial fosse determinado — uma vulnerabilidade que poderia ter custado apenas US$ 50.000 em recompensas (bounties) para ser descoberta e corrigida. Estes não são casos isolados. Este é o registro oficial do que acontece em um ambiente de alto valor, onde encontrar "brechas" de red teaming é muito bem recompensado e o custo para a exploração é zero.

O risco menos mencionado, na verdade, segue o caminho oposto. Um protocolo que abre um programa de bug bounty antes de estar devidamente preparado para isso está, efetivamente, pagando por um convite aberto para que encontrem tudo o que sua equipe interna deixou passar — e se a base de código (codebase) for mal auditada, isso pode muito bem ser quase tudo. Por exemplo, um programa com limite de US$ 100.000 iniciado contra um sistema de contratos com vinte vulnerabilidades críticas poderia sofrer divulgações simultâneas que esgotariam todo o orçamento de recompensas em dias, enquanto deixariam o protocolo operando de forma insegura.

Imagine este cenário que nos permite dizer que muitos dos primeiros projetos DeFi acabaram aproximadamente nesta situação: um programa de recompensas (bug bounty) é anunciado publicamente, e começam a surgir denúncias que revelam que a auditoria interna foi apenas superficial; no entanto, os custos de remediação superaram rapidamente o que a equipe havia reservado para toda a sua abordagem de segurança. A moral da história não é que os bug bounties sejam arriscados — é que eles exigem um padrão mínimo de qualidade de código. Os protocolos descobrem seus piores problemas da pior maneira possível ao lançar um programa de recompensas como substituto para um trabalho de segurança interna substancial, em vez de um complemento a ele.

A constatação dessas lições resultou na seguinte sequência no mundo real: revisão interna, uma ou mais auditorias externas por empresas de confiança e, em seguida, o lançamento em produção com um programa de bug bounty permanente. Outros incorporam uma medida adicional de lançamento faseado (staged rollout) — limitando o valor máximo em risco (value-at-risk) do protocolo por um tempo definido enquanto o programa de recompensas está ativo, e expandindo a liquidez apenas quando nenhuma falha crítica surgir. Isso é mais lento e, muitas vezes, mais caro do que simplesmente lançar o produto. A alternativa é, ocasionalmente, catastrófica.

Ecossistema: plataformas, programas e pagamentos recordes

A infraestrutura de bug bounty em cripto amadureceu significativamente desde os primeiros dias de e-mails de divulgação informais e recompensas ad hoc.

A Immunefi é a maior plataforma do setor e foi lançada em dezembro de 2020. Já distribuiu mais de US$ 100 milhões a pesquisadores em mais de 3.000 relatórios de bugs, e afirma ter ajudado a prevenir perdas de mais de US$ 25 bilhões em pelo menos 500 protocolos até o início de 2026. A plataforma atende a uma comunidade de cerca de 45.000 pesquisadores de segurança registrados, suporta processos de divulgação estruturados e intermedia as negociações que ocorrem entre pesquisadores e protocolos sobre a classificação de severidade e os valores de pagamento.

A Immunefi recebe uma porcentagem dos pagamentos de recompensas, o que alinha razoavelmente seus incentivos com ambas as extremidades do mercado: eles lucram mais quando os pesquisadores encontram bugs reais e os protocolos pagam por eles.

O maior pagamento individual na história da plataforma continua sendo uma recompensa de US$ 10 milhões paga em fevereiro de 2022 a um de seus pesquisadores, sob o pseudônimo "satya0x", por encontrar uma vulnerabilidade de proxy não inicializado na ponte Wormhole. A vulnerabilidade, se explorada, teria exposto recursos bloqueados no valor de aproximadamente US$ 736 milhões. O pesquisador realizou a divulgação responsável e foi premiado com o que era, na época, o maior pagamento de bug bounty já registrado. Em dezembro de 2021, a Polygon adquiriu um bug crítico do pesquisador Leon Spacewalker por US$ 2,2 milhões, o qual poderia ter permitido a cunhagem de até 9,3 bilhões de tokens MATIC — o que equivalia a bilhões de dólares, considerando as cotações da época. A lógica matemática é clara em ambos os sentidos: a recompensa foi alta em termos absolutos e pequena em termos relativos ao que poderia ter sido perdido com os ataques evitados.

Programas de incentivo dedicados executados no nível do protocolo atingiram agora números que seriam difíceis de imaginar há apenas alguns anos. O pagamento máximo é de US$ 15,5 milhões para vulnerabilidades críticas no programa v4 da Uniswap. A LayerZero possui recompensas abertas de US$ 15 milhões. Em 2026, o pagamento máximo da Ethereum Foundation subiu para US$ 1 milhão.

Esses valores não apenas precisam estar correlacionados ao valor do que esses protocolos tentam proteger, mas também precisam escalar de acordo com o calibre do pesquisador cuja atenção se deseja atrair — um teto de US$ 1.000 não incentivará alguém capaz de explorar uma vulnerabilidade crítica em um protocolo multibilionário.

A Code4rena e a Sherlock são um pouco diferentes: você organiza um concurso de auditoria competitiva dentro de um prazo especificado, onde vários pesquisadores inspecionam a base de código simultaneamente e recebem partes da premiação total com base na severidade e validade das descobertas. Com uma comunidade de mais de 8.300 auditores registrados e mais de 24.000 descobertas únicas em todas as auditorias da Code4rena. Já foram realizados mais de 175 desses concursos pela Sherlock. Um formato competitivo altera a estrutura de incentivos; os pesquisadores são incentivados a procurar problemas que outros possam não notar, já que descobertas em volumes tão notáveis frequentemente recebem apenas um pagamento pequeno ou nenhum. Geralmente, isso também revela problemas em uma escala maior do que auditorias sequenciais ou programas de bounty abertos conseguem abordar separadamente. Programas de cripto para outros detentores de Bitcoin Cash, como Coinbase e MakerDAO, ainda são hospedados no GitHub. Em todo o mercado ativo de bug bounty na Web3, há agora bem mais de US$ 162 milhões em recompensas oferecidas caso algo não saia como planejado, o que representa tanto a magnitude do que está em jogo quanto um indício da trajetória de profissionalização percorrida por muitos pesquisadores.

Analisando o Trabalho Artesanal e Por Que Não é Dinheiro Fácil

A imagem do caçador de bug bounty como alguém que encontra uma vulnerabilidade em uma tarde e recebe um pagamento de seis dígitos não é confirmada pela realidade do trabalho. Seus profissionais, que ganham a vida pesquisando segurança no espaço cripto, são geralmente especialistas, cujo caminho para se tornarem tais exige muitos anos de preparação técnica em áreas onde a maioria dos desenvolvedores raramente se aventura.

Encontrar os defeitos de maior gravidade em códigos de contratos inteligentes em produção exige expertise na Ethereum Virtual Machine — não apenas saber escrever em Solidity, mas entender no que ele se compila, o que a EVM realmente faz ao executar o bytecode e quais recursos da linguagem são garantidos ou reconhecidamente executados por seu compilador, em contraste com seus potenciais casos extremos que podem se tornar problemas de segurança quando combinados com escolhas de otimização de gas feitas por desenvolvedores com recursos limitados e sob prazos apertados. Isso requer não apenas a compreensão das classes comuns de vulnerabilidade — reentrada, estouro de inteiro, manipulação de flash loan, manipulação de preço de oráculo, falhas de controle de acesso, vulnerabilidades de inicialização — mas também a capacidade de detectar novos vetores de ataque que não se conformam a nenhum padrão conhecido. As descobertas mais úteis são aquelas que ninguém estava sequer procurando.

O conjunto de ferramentas que os pesquisadores trazem para este trabalho amadureceu significativamente e agora inclui ferramentas que, na maioria dos casos, são indistinguíveis das que um agente malicioso utilizaria:

O Slither, um framework de análise estática desenvolvido pela Trail of Bits, pode escanear seu código Solidity em busca de 40 padrões de vulnerabilidade conhecidos e fornecer uma saída ordenada. É um primeiro passo, não o último — ele apresenta falsos positivos e ignora completamente vulnerabilidades na camada de lógica.

O Mythril utiliza execução simbólica para percorrer os estados possíveis de um contrato e verifica se algum estado alcançável viola certas propriedades de segurança especificadas pelo pesquisador. No entanto, ele é caro e permite apenas uma análise superficial de contratos complexos.

É um fuzzer baseado em propriedades: dado um conjunto de invariantes que um contrato deve sempre satisfazer, o pesquisador os passa para o Echidna, que percorrerá milhares de sequências aleatórias de transações tentando quebrá-los. Somos especialmente bons em buscar casos extremos na lógica aritmética e de gerenciamento de estado.

A maioria das pesquisas sérias de segurança está sendo realizada atualmente usando o Foundry, pois ele possui um mapeamento mínimo entre "acho que isso funcionará" → "posso provar que isso funciona", especialmente porque a maioria dos pesquisadores escreve seus testes e exploits em Solidity diretamente com o Foundry.

Com as ferramentas de verificação formal da Certora, os pesquisadores podem usar especificações de comportamento de contrato na forma de contratos matemáticos e, em seguida, realizar a verificação contra o bytecode real. Este é o método mais desafiador e também o mais difícil de implementar em termos de habilidade e esforço.

Outra ferramenta da Trail of Bits, o Manticore realiza análise dinâmica e pode ser usado para gerar automaticamente entradas que percorrem certos caminhos de código no contrato — algo que a análise estática não consegue alcançar.

Não existe uma ferramenta única que encontre automaticamente vulnerabilidades críticas a partir de qualquer uma dessas ferramentas. Elas restringem o espaço de candidatos potenciais e destacam aqueles que um humano deve, então, avaliar. Se um pesquisador não consegue ler o assembly da EVM, raciocinar sobre a ordenação de transações e entender a economia de um protocolo DeFi em nível de sistema, ele será incapaz de fazer muito com o resultado de qualquer uma dessas ferramentas. Essas ferramentas são amplificadores de expertise, e não substitutos para ela.

Essas dificuldades práticas vão muito além do técnico. A competição é intensa. Durante um concurso de auditoria na Code4rena ou na Sherlock, dezenas de desenvolvedores estudam a mesma base de código ao mesmo tempo.

Geralmente, um pesquisador reivindica uma descoberta crítica — todos os outros que encontram o mesmo problema não recebem nada ou apenas migalhas. Um pesquisador que dedica uma semana a um concurso e encontra apenas problemas de gravidade média pode sair com apenas algumas centenas de dólares. A variabilidade de renda é alta e os períodos de seca são reais.

No entanto, provar um resultado pode ser tão difícil quanto resolvê-lo. É necessário fazer uma demonstração prática de explorabilidade (geralmente com um exploit de prova de conceito real). Alguns, novamente, contestam a classificação de gravidade de uma descoberta crítica ou média, argumentando que certos aspectos mitigam seu status. Pesquisadores que não documentam cuidadosamente seu trabalho, e pesquisadores que carecem da influência decorrente da reputação, podem se ver sub-remunerados por descobertas importantes.

E, finalmente, o ambiente jurídico e tributário torna-se uma complicação à parte. A maioria das recompensas (bounties) é paga em alguma forma de cripto — seja USDT, USDC, ETH ou o token nativo de um protocolo. Receber uma transferência de USDT como renda resulta em um evento tributável, criando a exigência de que o destinatário rastreie o valor no momento do recebimento antes de convertê-lo para fins de declaração, além de estar sujeito a ganhos de capital sobre qualquer variação de preço se o pagamento foi feito por meio de algum tipo de ativo digital. Bug bounties trazem custos operacionais reais — estabelecer uma prática de bug bounty, como qualquer negócio, exige equilibrar as compensações entre o tempo investido e os resultados tangíveis — se você ignorar a parte administrativa, isso se torna outro problema que se agrava silenciosamente.

Mas o desafio mais profundo é que este trabalho tem um teto alto e um piso zero para ganhos. Um pesquisador que desenvolve expertise real com um histórico comprovado — alguém que descobriu vulnerabilidades críticas em protocolos, cujo nome aparece em relatórios de auditoria / postmortems — pode ganhar valores comparáveis aos salários de engenheiros seniores em grandes empresas. É necessária uma condição genética peculiar de nascimento ou anos de aperfeiçoamento de um ofício específico para chegar lá. Quase qualquer pessoa que tente viver exclusivamente disso descobre rapidamente que o tempo de aprendizado é muito mais longo do que o esperado, que a concorrência se preparou melhor do que o previsto e que, durante o treinamento, a renda simplesmente não é suficiente para cobrir as despesas.

Isso não significa necessariamente que seja uma área ruim. Isso a torna uma área honesta. O conjunto exato de habilidades que permite a um pesquisador de bug bounty ter sucesso — foco técnico profundo, pensamento sistêmico, criatividade diante da incerteza e disposição para trabalhar por horas em algo que pode não trazer retorno sobre o esforço — é precisamente o conjunto de habilidades desejado por profissionais de segurança em todos os domínios. Uma pessoa que desenvolveu essas habilidades até o ponto necessário para a pesquisa de segurança cripto está em posição de escolha. Uma dessas carreiras é o caminho do bug bounty, e cada vez mais para os poucos que o seguem.

Esta é uma ótima notícia para qualquer pessoa que opere um fluxo de trabalho baseado em USDT — desde decidir quem recebe qual recompensa, até dividir pagamentos entre vários colaboradores ou apenas retirar a recompensa do protocolo. A Calculadora de Transferência de USDT da Netts faz exatamente isso: insira os endereços de remetente e destinatário e ela informará precisamente quanta Energia e Largura de Banda serão necessárias para a transação, o que é queimado em relação ao padrão ou se recursos existentes são utilizados, juntamente com uma comparação de custos para enviar para um endereço que já possui USDT (13,84 TRX vs. 2-3 TRX para Energia alugada) ou um novo (27,70 TRX vs. 4-5 TRX em recursos alugados) — uma economia de mais de 80% em ambos os casos!