En mi último registro de recompensas por errores encontré lo que parecía un error crítico de redondeo en un producto de rendimiento por tramos: se perdían 100.000.000.000 wei por canje. Truncamiento acumulado en dos capas de conversión. Un borrador con gravedad “Alta”, listo para enviar. Pero mi regla de validación dice: reprodúcelo en una bifurcación de la red principal antes de creer cualquier cifra. La sorpresa:
El pool simulado suponía 18 decimales y un divisor de 1e30.
El token real tiene 6 decimales y un divisor de 1e18.
Ese desajuste de escala de 1e12 hacía que el mock devolviera cero en cada canje, así que la pérdida == la cantidad solicitada. No era un error del protocolo: mi entorno de pruebas estaba mal. En la red principal, la pérdida real era de ~2–3 wei por canje, dentro del margen de redondeo de 100 wei que el desarrollador ya había reservado. Por diseño. Conclusiones:
Un hallazgo validado solo con un mock es una hipótesis, no un error.
uint256 no tiene unidades: un error de escala de 12 dígitos compila sin problemas y supera todos los analizadores.
Si la “pérdida” que alegas equivale al importe total, el problema está en tu escala, no en el contrato.
Lee los comentarios del desarrollador sobre el margen/epsilon antes de asignar la gravedad. Resultado: 0 informes enviados, 4 posibles hallazgos descartados durante la validación, una tarde bien aprovechada y la reputación intacta. Antes de enviar tu próximo caso de “pérdida por redondeo sin límite”, prueba una unidad en el contrato real dentro de una bifurcación. Si tu pérdida cabe dentro del epsilon del desarrollador, no tienes un hallazgo: tienes un problema con el mock.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(Seguro para el NDA: registro genérico, sin nombres de protocolos, direcciones, repositorios ni PoC activos.)
Lee el análisis técnico completo en mi blog (enlace en el primer comentario) 👇