In my latest Bug Bounty Log I found what looked like a critical rounding bug in a tranche-based yield product: 100,000,000,000 wei lost per redeem. Compounded truncation down two conversion layers. A “High” severity draft, ready to file. But my validation rule says: reproduce on mainnet fork before believing any number. The twist:
The mock pool assumed 18 decimals and divisor 1e30.
The real token has 6 decimals and divisor 1e18.
That 1e12 scale mismatch made the mock return zero on every redeem, so loss == amount requested. It wasn’t a protocol bug — my harness was broken. On mainnet, real loss was ~2–3 wei per redeem, inside the 100-wei rounding budget the developer already reserved. By design. Takeaways:
A finding validated only against a mock is a hypothesis, not a bug.
uint256 has no units: a 12-digit scale error compiles clean and passes every analyzer.
If your claimed “loss” equals the full amount, the problem is your scale, not the contract.
Read the developer’s margin/epsilon comments before drafting severity. Result: 0 submissions, 4 candidates killed in validation, one honest afternoon, reputation intact. Before you file your next “unbounded rounding loss,” run one unit through the real contract on a fork. If your loss fits inside the developer’s epsilon, you don’t have a finding — you have a mock problem.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(NDA-safe: generic log, no protocol names, addresses, repos, or live PoCs.)
Read the full technical breakdown on my Blog (Link in the first comment) 👇