No meu registro mais recente de Bug Bounty, encontrei o que parecia ser um bug crítico de arredondamento em um produto de rendimento baseado em tranches: 100.000.000.000 wei perdidos por resgate. Truncamento acumulado em duas camadas de conversão. Um rascunho de gravidade “Alta”, pronto para enviar. Mas minha regra de validação diz: reproduza em um fork da mainnet antes de acreditar em qualquer número. A reviravolta:
O pool simulado presumia 18 casas decimais e divisor de 1e30.
O token real tem 6 casas decimais e divisor de 1e18.
Essa incompatibilidade de escala de 1e12 fazia o mock retornar zero em cada resgate, então a perda era igual ao valor solicitado. Não era um bug do protocolo — meu ambiente de testes estava quebrado. Na mainnet, a perda real era de ~2–3 wei por resgate, dentro do limite de arredondamento de 100 wei que o desenvolvedor já havia reservado. Por design. Lições:
Uma descoberta validada apenas com um mock é uma hipótese, não um bug.
uint256 não tem unidades: um erro de escala de 12 dígitos compila sem problemas e passa por todos os analisadores.
Se a “perda” que você alega equivale ao valor total, o problema está na sua escala, não no contrato.
Leia os comentários do desenvolvedor sobre margem/epsilon antes de definir a severidade. Resultado: 0 submissões, 4 candidatos descartados na validação, uma tarde honesta e reputação intacta. Antes de registrar sua próxima “perda de arredondamento ilimitada”, execute uma unidade no contrato real em uma fork. Se a sua perda estiver dentro do epsilon do desenvolvedor, você não tem uma descoberta — tem um problema com o mock.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(Seguro para NDA: log genérico, sem nomes de protocolos, endereços, repositórios ou PoCs ativos.)
Leia a análise técnica completa no meu blog (link no primeiro comentário) 👇