I almost reported a critical bug that didn't exist. One constant saved me.

Last week I was reviewing the staking engine of a protocol before its mainnet launch. Deep in a 1,400-line contract, I found what looked like a serious bug. The reward math multiplied three values before dividing: uint256 delta = (lot.amount * rBase * midpointRate) / (RAY * RAY); Enter fullscreen mode Exit fullscreen mode Multiply-before-divide. If that intermediate product overflows uint256, the whole epoch settlement reverts — and since every stake, withdraw, and setStake runs it, the post's funds get permanently frozen. That's a High-severity, fund-locking DoS. I had the finding half-written. lot.amount can reach 10M tokens (1e25). rBase grows with elapsed time. midpointRate can hit RAY. Multiply those and you blow past 2^256... I was ready to send it. Then I did the one thing that separates a real audit from false-positive spam: I checked the actual constants before writing the claim. uint256 private constant RAY = 1e18; // I'd assumed 1e27 Enter fullscreen mode Exit fullscreen mode RAY was 1e18, not the 1e27 I'd been carrying in my head. And the interest rate had a hard cap — MAX_RATE_MAX_RAY = 5e18, enforced even against a fully-captured timelock. I ran the numbers with the real values: For that multiplication to overflow, the protocol would need to go 2.3 × 10¹⁵ years without a single state update. Not reachable. The bug didn't exist. I deleted the finding. Why this matters more than the bug would have If I'd sent that report, here's what happens: the team's engineer clones the repo, plugs in the real constants, and realizes in ten minutes that I flagged an overflow that can't happen. Every other finding in my report now gets read with a raised eyebrow. My credibility — the entire product — is gone. This is the dirty secret of automated smart-contract auditing: the bottleneck isn't finding issues. It's not drowning the real ones in false positives. Anyone can run a scanner and paste 40 "criticals." A team that has to triage 40 flags to find the 2 that matter will — correctly — stop trusting you. The bar I hold: zero false positives on OpenZeppelin Here's a concrete, checkable standard I keep: my scanner runs clean — zero findings — across the entire OpenZeppelin contracts library. All 248 source files. If a tool can't stay silent on the most-reviewed Solidity code on earth, it has no business flagging your code. It's a claim I re-verify obsessively, because it's easy to break. In fact, I recently caught it broken. My access-control detector had started flagging OZ's ERC1967Utils.upgradeToAndCall as "unprotected" — but that function is internal. It isn't externally callable; it can't be an access-control bug (the auth lives in the public entry point that calls it). One rule — skip internal/private functions — and OZ was clean again. A few more false-positive classes I've had to kill, each one a lesson: The virtual-shares + 1 isn't "rounding up." A correct ERC-4626 vault writes totalSupply() + 10**offset and totalAssets() + 1 — that's the OZ inflation-attack mitigation. A naive detector reads the + 1 as ceil-rounding and screams "share inflation risk" on correct code. It would fire on almost every well-built vault. A permissionless emergencyWithdraw() that moves funds into internal claimable state isn't a fund-sweep. The caller can't redirect anything; it's a keeper-resilience pattern. Flagging it wastes everyone's time. Auth written in assembly is still auth. if iszero(eq(sload(admin), caller())) { revert } protects a function just as well as onlyOwner. Gas-optimized code isn't unprotected code. Each of these looks like a bug to a pattern-matcher. None of them are. Knowing the difference is the job. The discipline, stated plainly Verify against reality, not against your assumptions. I nearly shipped a bug because I remembered a constant wrong. Read the actual value. Every time. Detectors surface; a human confirms. Heuristics are for recall — cast a wide net. Precision comes from a person who reads the code and asks "is this actually exploitable?" before it reaches the client. A clean bill is a finding too. When I dug into that vault's donation-attack surface and found the mitigation was there — reimplemented correctly, just not inherited from OZ — I wrote that down and said so. "It's solid, and here's why" is worth as much as a bug. It's honest, and it's what a team actually needs before they ship. The overflow that wasn't taught me the same thing the clean vault did: the value isn't in what you flag. It's in what you can stand behind. I do fast, honest Solidity security reviews — custom detectors plus manual verification, no false-positive noise. I only report what's real, and I'll tell you plainly when your code is solid. If that's the kind of review you want before mainnet, my details are in my profile.