最新のバグバウンティログで、トランシェ型の利回り商品に重大そうな丸め誤差のバグを見つけました。償還ごとに100,000,000,000 weiが失われるというものです。2段階の変換処理で切り捨て誤差が積み重なっていました。「重大（High）」の重大度で報告書の下書きまで作成し、あとは提出するだけでした。しかし、私の検証ルールでは、どんな数値も信じる前にメインネットのフォーク環境で再現することになっています。ところが、意外な事実が：
モックプールは、小数桁数が18で、除数が1e30だと仮定していました。
実際のトークンは小数桁数が6で、除数は1e18です。
この1e12のスケールの不一致により、モックは償還のたびにゼロを返し、損失 == 要求額となっていました。プロトコルのバグではなく、私のテストハーネスが壊れていたのです。メインネットでは、実際の損失は償還1回あたり約2～3 weiで、開発者があらかじめ確保していた100 weiの丸め誤差の許容範囲内でした。設計どおりです。学んだこと：
モックだけを使って検証された指摘は、バグではなく仮説です。
uint256には単位がありません。12桁のスケール誤差があっても問題なくコンパイルされ、すべてのアナライザーを通過します。
主張する「損失」が全額に等しいなら、問題はコントラクトではなくスケールです。
深刻度を決める前に、開発者によるマージンやイプシロンについてのコメントを読んでください。結果：提出0件、検証で候補4件を排除、誠実な午後をひとつ、評判は無傷。次の「上限のない丸め損失」を報告する前に、フォーク上で実際のコントラクトに1単位を通してみてください。損失が開発者のイプシロンの範囲内なら、それは指摘事項ではなく、モックの問題です。
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
（NDAに配慮：一般的なログのみ。プロトコル名、アドレス、リポジトリ、稼働中のPoCは記載していません。）
詳しい技術解説はブログでご覧ください（リンクは最初のコメントにあります）👇