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

The near-miss

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);

Multiply-before-divide. If that intermediate product overflows uint256, the whole epoch settlement reverts - and since every stake, withdraw, and setStake runs it, the protocol'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²⁵⁶... 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 RAY was 1e27, not the 1e18 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.