DEV Community: juan23z

5 false positives your Solidity scanner is probably reporting right now

juan23z — Thu, 06 Aug 2026 10:00:11 +0000

Every automated Solidity security tool has the same disease: it cries wolf. Run one on an audited protocol and you get 600 "findings," 98% of which are noise. The tragedy isn't the wasted time — it's that after the tenth false alarm, you stop reading. The one real bug then hides in the noise.

I spent this week hand-verifying every flag my scanner produced against production protocols (Ember, Euler, Liquity, Arcadia, Rubicon, and more). Every single one was a false positive. Here are five of the most common classes, why a naive tool reports them, and the deterministic check that kills each — no AI guesswork required.

1. The "spec violation" that's just... the design

A tool reads a spec or a NatSpec comment — "only the rate manager can update the rate" — and flags the function as a violation because it "can't prove" the restriction. On Ember's vaults this produced a CRITICAL:

function pause() external onlyGuardian { ... }
function processWithdrawalRequests(uint256 n) external onlyOperator { ... }
function setMaxTVL(uint256 v) external onlyAdmin { ... }

Every one is a correctly access-controlled, intended feature. The tool listed the protocol's own role design and called it a bug.

The fix: before emitting, find the affected function and check whether the restriction is actually enforced (onlyX / onlyRole / require(msg.sender == ...)). If it is, it's the design, not a violation. If there's genuinely no guard, it still fires. Safe direction.

2. Fee-on-transfer on a token that can't be fee-on-transfer

A vault does token.transferFrom(user, address(this), amount) and uses amount for accounting. Fee-on-transfer tokens arrive short, so the internal books inflate → the tool screams "insolvency."

Real? Only if users can deposit arbitrary tokens. Two very common cases where they can't:

// (a) the deposit is onlyOwner — the owner picks what enters
function deposit(address token, uint amount) external onlyOwner { ... }

// (b) the token set is curated by a registry / whitelist
uint256[] memory types = IRegistry(registry).batchGetAssetTypes(assets);

If governance (or the owner) curates which tokens can ever enter, a fee-on-transfer token simply isn't on the list. It's an accepted design assumption, not an exploit. Verified this week on Arcadia (registry-gated) and Rubicon (onlyOwner + pool-curated assets).

The fix: suppress when the deposit is onlyOwner/role-gated or the repo curates tokens. Keep firing on permissionless deposit paths — that's where the real risk lives.

3. The "unchecked call" that's checked one line down

(bool success, ) = recipient.call{ value: amount }("");
require(success, "transfer failed");

A regex that only looks at the call line flags this as "unchecked return value." Look one line down — the require(success) is right there. .transfer() gets flagged too, even though it auto-reverts.

The fix: read the next few lines for a require/revert, and know the difference between .call (returns a bool) and .transfer (reverts on failure). Two lines of context kill the whole class.

4. Read-only reentrancy... into an address the attacker doesn't control

Read-only reentrancy is real and nasty — but only when an attacker can reenter through a manipulable path. On Cap's distributeRewards, a tool flagged it, but:

address network = $.agentData[_agent].network;  // governance-set, not attacker input
IERC20(_asset).safeTransfer(network, _amount);
ISymbioticNetworkMiddleware(network).distributeRewards(_agent, _asset);

The external callee is a governance-configured address, and there's no price-view being read mid-call. No attacker entry point, no manipulable value. Not exploitable.

The fix: check where the callee address comes from. If it's immutable or governance-set (not user input), and there's no manipulable view during the call, suppress.

5. Flagging a bug in code the client didn't write

The last one is subtle: my scanner flagged an unchecked send in LzApp.sol — LayerZero's base contract, vendored into the repo. It's not the client's code. Reporting it is noise (and slightly embarrassing — you're telling a founder to go fix LayerZero).

The fix: skip vendored / third-party code (node_modules, @openzeppelin, LayerZero's LzApp / OApp / OFT bases). Audit the client's contracts, not their dependencies.

The point

None of these fixes are clever AI. They're the exact checks a human auditor does in their head: is it guarded? is the token curated? is success checked below? who controls the callee? is this even the client's code? Encode them deterministically and the false-positive flood drains away — permanently, on every future scan.

I keep my pipeline at zero false positives across the entire OpenZeppelin library, because a report that cries wolf trains you to ignore it. Silence, on my reports, means something.

If you're pre-mainnet and want a security first-pass that only surfaces real issues — hand-verified, no noise — I'm happy to take a look: juan23z.github.io.

My smart-contract scanner reports almost nothing — and that's the whole point

juan23z — Wed, 05 Aug 2026 19:09:48 +0000

Most Solidity security tools have the same failure mode: they cry wolf. You run them on an audited protocol and get 600 "findings," 98% of which are noise. The signal drowns. Worse — send a client a report full of false positives once, and you've burned your credibility.

I've been building a scanner with the opposite goal: report almost nothing, but be right when it does. Zero false positives, verified across the entire OpenZeppelin library. Here's how that actually works, with three real examples from today's run against production protocols.

Example 1 — the "spec violation" that isn't

A naive detector reads a NatSpec comment or a spec doc that says "only the rate manager can update the rate", then flags the function as a violation if it "can't prove" the restriction. On Ember's vaults today, that produced six [real] findings — one of them a CRITICAL:

function pause() external onlyGuardian { ... }
function processWithdrawalRequests(uint256 n) external nonReentrant onlyOperator { ... }
function setMaxTVL(...) external onlyAdmin { ... }

Every one of these is a correctly access-controlled, intended feature. The "spec violation" was the tool listing the protocol's own role design and calling it a bug. All six were false positives.

The fix is deterministic, not AI-guesswork: before emitting, find the affected function and check whether the restriction is actually enforced (onlyX / onlyRole / msg.sender == / a require). If it is — it's the design, not a violation. Suppress it. If there's genuinely no enforcement, it still fires. Safe direction.

Example 2 — fee-on-transfer that's out of scope by design

Another classic: a vault does token.transferFrom(user, address(this), amount) and then uses amount for accounting. Fee-on-transfer tokens send less than amount, so the internal books inflate → the tool screams "insolvency."

Real? Only if the protocol lets users deposit arbitrary tokens. Most don't:

// deposit is gated by a curated registry / whitelist
uint256[] memory types = IRegistry(registry).batchGetAssetTypes(assets);
IRegistry(registry).batchProcessDeposit(creditor, assets, ids, amounts);

If governance curates which tokens can ever enter, a fee-on-transfer token simply isn't listed. It's an accepted design assumption, not an exploit. So the detector now checks for token curation (registry / isAllowedAsset / whitelist) and stays quiet when it's present — but still fires on genuinely permissionless deposit paths.

Example 3 — the unchecked call that's actually checked

(bool success, ) = recipient.call{ value: amount }("");
require(success, "transfer failed");

A regex that only looks at the call line flags this as "unchecked return value." Look one line down and the require(success) is right there. .transfer() gets flagged too — even though it auto-reverts. The fix: read the next few lines, and know the difference between .call and .transfer.

Why bother being this strict?

Because the number that matters isn't how many findings you produce — it's how many are real. A report a founder can trust is worth more than a wall of noise they have to triage themselves. I verified 13 flagged findings across audited protocols today; all 13 were false positives, and the pipeline now suppresses those classes automatically, forever. That's the moat: not more findings, fewer wrong ones.

If you're building something pre-mainnet and want a security first-pass that only tells you about real issues — no noise, hand-verified — I'm happy to take a look. You can find my work at juan23z.github.io.

Written after a long day of teaching a scanner to shut up when it should.

I ran my Solidity scanner on 6 top-audited DeFi protocols. Every 'critical' was a false positive — here's why.

juan23z — Thu, 30 Jul 2026 22:08:33 +0000

Most Solidity scanners are high-recall, low-precision. They flag 40 things, 38 are noise, and after the third report you stop reading them — so the one real bug ships. Precision, not recall, is what makes a security tool actually get used.

I've been building OpenClaw, a heuristic Solidity scanner with the opposite bar: silence on sound code. To pressure-test it, I pointed it at six codebases that top firms have already audited — Yearn, Sablier, Ajna, Liquity, and a couple of smaller protocols — and hand-verified every single flag.

The result: 14 HIGH/CRITICAL candidates across the six. Every one was a false positive.

That sounds like a failure. It's the whole point — and each FP is a lesson in the exact traps that fool most scanners. Here they are.

1. The "donation attack" that isn't (a PaymentSplitter)

The scanner flagged balanceOf(address(this)) used in accounting as a donation / share-inflation attack. But the contract was a fork of OpenZeppelin's PaymentSplitter: shares are fixed at deployment, and a "donation" is exactly the input that gets split proportionally among those fixed shares. There's no share to mint, no share price to manipulate, no first-depositor. balance + totalReleased is the canonical, correct accounting.

Lesson: balanceOf(this) in accounting is only a donation risk when shares are minted against it. In a fixed-share pull-payment splitter, it's intended behavior.

2. The "unprotected initialize" with a guard the scanner didn't recognize (Ajna)

Ajna's pools were flagged as "unprotected initialize()". But there it was, first line:

if (isPoolInitialized) revert AlreadyInitialized();

A one-time-init guard. Plenty of non-OpenZeppelin protocols protect initialize with a boolean flag + revert instead of the initializer modifier. A detector that only knows the OZ modifier misses it and screams.

Lesson: an initializer is protected if it has any one-time guard — the OZ modifier, a boolean flag that reverts, factory/clone init, or _disableInitializers().

3. "Read-only reentrancy" in functions nobody uses as an oracle (Ajna, Liquity)

poolBalanceDetails(), flashLoan(), simulateRedemption() — all flagged for reading a balance after an external call. Read-only reentrancy (the Curve/Balancer class that paid $100k+ bounties) is only exploitable if an external protocol consumes the function as a price oracle. A view utility in a Multicall helper, a flash loan's repayment check, a simulate* function — none of those are oracles.

Lesson: read-only reentrancy needs an oracle consumer. simulate / preview / *Details / multicall / flashLoan aren't oracles → not exploitable.

4. The "manipulable rate" that's bounded and role-gated (Ember)

Flagged CRITICAL: "rate can be updated." But the rate was managed and bounded — a rateManager role, a maxRateChangePerUpdate cap, a rateUpdateInterval, and events on every change. A trusted, bounded, time-gated exchange rate is intended design, not an exploit. Even a malicious manager can only nudge it by the cap per interval.

Lesson: a role-updatable value bounded by max-change + interval is a managed parameter, not a vulnerability (at most a centralization note).

5. "Fee-on-transfer not supported" — by design (Liquity)

Flagged for not handling fee-on-transfer tokens. But Liquity's BOLD uses a vetted, fixed set of collateral (WETH/wstETH-class), not arbitrary ERC-20s. "Doesn't support FoT" is a deliberate decision for a protocol with curated collateral.

Lesson: FoT-not-supported is only a bug if the protocol accepts arbitrary tokens. With vetted collateral, it's intended.

Why this matters

Every one of these is a place a naive scanner shouts "CRITICAL" and a good auditor quietly says "no." The value of a low false-positive rate isn't that the tool finds less — it's that when it (or I) stay silent, the silence means something. A tool that cries wolf 38 times out of 40 trains you to ignore the 39th. The 39th is the real one.

Each of these five FP classes is now a permanent fix in the detector, not a patch — so the next PaymentSplitter, the next flag-guarded initialize, the next view utility, doesn't fire. That's how you drive false positives toward zero without going blind to the real thing.

The scanner

OpenClaw is calibrated against the codebases everyone treats as a gold standard — OpenZeppelin, Solady, Solmate, Uniswap v2/v3/v4, Permit2, Morpho Blue, PRBMath. 608 source files, 14 total flags, 0 across the entire OpenZeppelin library. MIT, pure Python, runs as a GitHub Action that comments on every PR:

pipx run --spec git+https://github.com/juan23z/openclaw-audit openclaw-audit <repo> --out ./report

Honest about what it is not: it's heuristic, not formal verification. It catches classes of bugs (access control, vault math, reentrancy shape, oracle staleness, upgradeability) — not your protocol's bespoke economic logic bug, the one where two functions interact in a way nobody drew on the whiteboard. That still needs a human. But the silence is honest.

If you're shipping to mainnet and want a second set of eyes — hand-verified findings, zero false-positive spam, a plain-English report in 48h — I do fast pre-mainnet reviews. Or just run the free scanner and keep the signal.

I'd genuinely like feedback on the false-positive classes above — which ones have bitten you with Slither/others?

What does a smart-contract audit actually cost? An honest breakdown for small protocols

juan23z — Fri, 24 Jul 2026 09:15:57 +0000

You've built a protocol. You know you should get the contracts reviewed before mainnet. So you ask around — and the answers range from "a friend will glance at it for free" to "$80k and a two-month waitlist." That spread is real, and it's paralyzing when you're a small team trying to ship.

Here's an honest breakdown of what actually drives the number, and how to spend a small budget well.

The honest ranges (2026)

Rough, real-world bands for EVM smart-contract security work:

Community / friend review — free to a few hundred. Better than nothing, wildly variable, no accountability.
Independent auditor, small scope — ~$1k–8k. A single experienced reviewer on a tight, well-defined scope (a token, a vault, a staking module). This is where most small protocols get the best value-per-dollar.
Boutique firm — ~$10k–40k. A team, a formal report, a brand you can show investors.
Top-tier firm / competitive audit — $50k+. Big scope, big name, big timeline.

If someone quotes you a flat number without asking about your scope first, be skeptical — the scope is the price.

Why the spread is so wide

Four things move the number:

Lines of code in scope. Someone has to read the money-moving paths line by line. Cost scales with that, not with your repo size — a 20k-line repo with a 600-line core is a small job if you scope it right.
Complexity. Novel math, cross-contract interactions, upgradeability, oracle dependencies, anything that "nobody drew on the whiteboard" — that's where time (and risk) lives.
Brand. You pay a premium for a well-known name on the report. Sometimes worth it for fundraising optics; often not, if you just want the code to be safe.
Timeline. Rush = premium.

What you're actually paying for

Not a list of findings. You're paying for judgment.

A scanner will flag 40 things. Usually 1–2 are real. The entire value of a good reviewer is telling you which — and staying silent on the 38 that aren't. A cheap review that cries wolf 40 times is worse than no review: it trains you to ignore the report, and the one finding that mattered goes out with the noise.

So when you compare quotes, don't compare "number of findings." Compare signal. Ask for a sample report. If it's 40 low-severity "consider using a constant here" items padding out two real issues, you're paying for noise.

How to spend a small budget well

Clean the obvious stuff first. Before you pay anyone, run a self-check: who can call what, is the initializer locked, is there a first-depositor guard on your vault, do rescue funds go to a fixed address. Fixing the boring bugs yourself means the reviewer's time goes to the hard ones.
Scope tightly. Get your core — the contracts that hold or move funds — reviewed deeply. Don't spread a small budget thin across peripheral code.
Prefer someone who'll tell you plainly when your code is solid. An honest "this part is fine, spend your money on that part instead" is worth paying for. Overselling is the tell.
Get a free first-pass before you commit. It shows you the reviewer's signal-to-noise before any money changes hands.

The uncomfortable truth

An audit is a snapshot. It expires the moment you change a line of code. And it catches classes of bugs — access control, vault math, reentrancy, oracle staleness — not your protocol's bespoke economic logic, the one where two functions interact in a way nobody modeled.

So budget for two things, not one: a deep review of the novel parts (where the real risk is), and ongoing monitoring so a later change doesn't quietly reopen a hole. A one-time stamp on code that keeps changing is a false sense of safety.

I run security reviews for small and new protocols — fast, honest, and I'll tell you plainly when your code is solid. I keep my open-source scanner at zero false positives across the entire OpenZeppelin library, because a tool (or a person) that cries wolf isn't worth listening to.

If you want a free first-pass before you ship, it's open source and runs in one command: https://github.com/juan23z/openclaw-audit

Good luck on mainnet. 🚀

Shipping a Solidity contract to mainnet? Do this 20-minute self-check first

juan23z — Thu, 23 Jul 2026 21:34:30 +0000

You built something. Tests pass. You're days from mainnet. Before you either skip security entirely (please don't) or spend weeks lining up a full audit, here's a self-check you can run in 20 minutes that catches the mistakes I see most often in first-time deployments.

I run security reviews for small and new protocols, and the same handful of issues come up again and again. None of these need a tool — just your eyes and this list.

1. Who can call what?

Open every external/public function that moves funds, mints, pauses, or upgrades. For each, ask: should a random address be able to call this? If not — is there an onlyOwner / onlyRole / require(msg.sender == ...) guarding it, in the function itself or in every internal function it calls?

The classic bug isn't a missing modifier. It's a function that looks unguarded but delegates to a guarded internal one (fine), or one that looks guarded but the guard is in a branch a caller can skip (not fine). Trace the call, don't trust the signature.

2. The first-depositor trap (if you have a vault)

If you mint shares from deposits (ERC-4626 or anything share-based), the first depositor can sometimes donate assets directly to the contract to inflate the share price, so the second depositor rounds down to zero shares and loses funds. Fix: virtual shares, a dead-shares mint at deploy, or a minimum-liquidity lock. OpenZeppelin's ERC-4626 handles this out of the box — a hand-rolled vault usually doesn't.

3. Reentrancy — but only the real kind

Not every external call is reentrancy. It's a bug when an attacker-controlled call can re-enter and corrupt shared storage before you've updated it. Quick checks:

Do you update state before the external transfer (checks-effects-interactions)?
Is there a nonReentrant on functions that move value?
Is the call target a trusted, immutable contract, or an arbitrary address the attacker supplies?

A call to a protocol-owned contract, or a memory/local variable written after the call, is usually not exploitable. Don't flag it just because Slither did.

4. Where do "rescue" funds go?

Got a sweep / rescue / emergencyWithdraw? Check the destination. If funds can only go to a fixed, stored address (treasury/owner), permissionless is fine — the caller can't redirect them. If the caller picks the destination, that's a drain waiting to happen. This one is a coin-flip in the reviews I do.

5. Oracle freshness (if you read a price)

Reading Chainlink? You need an updatedAt staleness check, not just answer > 0. But — and this is where half the "findings" you'll read online are wrong — plenty of protocols check it one layer up or rely on a heartbeat. Look at the whole path before you panic.

6. Upgradeable? Check the initializer.

Proxy pattern? Make sure initialize() has the initializer modifier, can't be called twice, and that the implementation contract itself can't be initialized-then-selfdestructed. A left-open initializer is one of the most common takeover bugs.

That's the 20-minute pass. It catches the obvious stuff — and honestly, most exploits of small protocols are the obvious stuff shipped in a hurry.

What it doesn't catch is the protocol-specific logic bug: the one where your staking math rounds the wrong way, or two functions interact in a way nobody drew on the whiteboard. That's what a human review is for.

My rule when I do those reviews: I only flag what's actually exploitable. I keep my scanner at zero false positives across the entire OpenZeppelin library — so when it (or I) stay silent on your code, that silence means something. A report that cries wolf 40 times trains you to ignore the one that matters.

If you want a free first pass before you ship, the scanner is open-source and runs in one command: https://github.com/juan23z/openclaw-audit. And if you'd rather have a person read the tricky parts — fast, honest, and I'll tell you plainly when your code is solid — that's what I do.

Good luck on mainnet. 🚀

I ran my Solidity scanner across the 10 most-audited codebases in web3. Here's every flag.

juan23z — Tue, 21 Jul 2026 16:36:35 +0000

The dirty secret of automated smart-contract security tools isn't that they miss bugs. It's that they cry wolf. Point a typical static analyzer at a clean codebase and you'll get forty "criticals" — and after the third false alarm, your team stops reading the output entirely. A tool nobody trusts is worse than no tool at all.

So when I built OpenClaw Audit — a free, open-source heuristic scanner for Solidity — I held it to a different bar. Not "how many things can it flag?" but the opposite: can it stay silent on code that's already sound?

There's a clean way to test that. Run it across the most-reviewed Solidity codebases on earth — the libraries that thousands of protocols depend on, audited many times over — and see how much noise it makes. A calibrated tool should be quiet here.

Here's what it found. Every number is reproducible in one command; every flag I checked by hand.

The results

Codebase	Source files	Candidates
OpenZeppelin Contracts	247	0
forge-std	31	0
Uniswap Permit2	16	0
PRBMath	40	0
Uniswap v2-core	11	1
Uniswap v3-core	40	1
Uniswap v4-core	46	1
Solmate	20	2
Morpho Blue	17	2
Solady	140	7
Total	608	14

Fourteen candidate observations across 608 source files. Four of the ten codebases came back completely clean. That's the headline: on the most-audited Solidity in existence, the scanner is nearly silent.

But the more interesting part is what it flagged — because the flags aren't random noise. They cluster on genuinely notable spots.

The flags, one by one

Uniswap v3 & v4 — initialize() flagged as "unprotected." False positive, and an instructive one. A Uniswap pool's initialize() sets its starting price, and it's permissionless by design — anyone can call it once on a fresh pool. A heuristic sees "an initialize function with no access control" and raises a hand. A human sees the design and clears it in five seconds. That's the model: the tool surfaces, the human decides.

Solmate — a real, known design gap. Solmate's minimal ERC-4626 deliberately omits the virtual-share protection against the first-depositor inflation attack, leaving it to the integrator. OpenZeppelin's ERC-4626 adds that defense; Solmate's doesn't. The scanner flags the difference — and it's right to. This is signal, not noise.

Morpho Blue — reentrancy candidates. False positives. Morpho Blue is formally verified with the Certora Prover, and the external calls the heuristic latched onto are safeTransfers with correct effects-before-interactions accounting. A pattern-matcher can't see a formal proof; a reviewer can.

Solady — seven flags, all false positives. A documented tx.origin rescue default in Lifebuoy (with explicit warnings in the code), UUPS/ERC-1967 upgrade authorization the regex doesn't parse, and one intentional math ordering. Solady is some of the most carefully-optimized Solidity written; the "issues" are the tool not understanding assembly-level auth, not real holes.

Why this matters more than a big number

I could have tuned the detectors until they screamed on everything and called it "thorough." That's easy, and useless. The skill in this job isn't generating findings — it's not drowning the two that matter under thirty-eight that don't.

A clean run on OpenZeppelin, forge-std, Permit2 and PRBMath means that when this tool does flag something in your code, it's worth a look. And when a human (me) reviews the output, I'm clearing a handful of explainable candidates — not wading through a wall of red.

The goal was never a tool that says "zero bugs." Nothing can promise that. The goal is signal over noise — and a claim you can check yourself rather than one you have to trust.

Check it yourself

git clone --depth 1 https://github.com/OpenZeppelin/openzeppelin-contracts /tmp/oz
pipx run --spec git+https://github.com/juan23z/openclaw-audit openclaw-audit /tmp/oz
# → 0 candidate observations across 247 client .sol contracts

Swap in any repo above — or your own. The full Calibration Report and the scanner (MIT-licensed, no API keys, GitHub Action included) are on GitHub.

I do fast, honest Solidity security reviews — heuristics to surface, manual verification to confirm, and a straight answer when your code is solid. Free scanner: github.com/juan23z/openclaw-audit · human review + continuous monitoring: juan23z.github.io

How to tell if a smart-contract audit is worth paying for — a founder's checklist

juan23z — Mon, 20 Jul 2026 14:19:52 +0000

You're about to put real money on-chain, and you know you need a security review. So you go looking — and the market is bewildering. A firm quotes you $30,000 and a six-week wait. A Fiverr gig offers "full audit, 24h delivery" for $60. How are you supposed to tell what's real?

I do these reviews for a living, so let me hand you the checklist I'd use if I were the one buying. Five questions. Ask every auditor.

1. "Can I see a sample report — and does it include things that were fine?"

A report that's all red flags is a red flag. A real review says "the access control is correct, here's why; the staking math is sound, here's the invariant I checked." A clean bill on what checks out is a finding — it's the auditor telling you where they looked and found nothing, which is exactly what you need to know before you ship.

If every sample report is a wall of "criticals," you're looking at a scanner's raw output, not an audit.

2. "What's your false-positive rate — and can you prove it?"

This is the whole game. Anyone can run a static analyzer and paste 40 findings. The skill is in not drowning the two real bugs in thirty-eight non-issues that waste your engineers' week.

Ask for a concrete, checkable claim. Mine, for example: my detectors run clean — zero findings — across the entire OpenZeppelin library (all 247 source files). That's verifiable in one command; you can clone OZ and run it yourself. If a tool can't stay silent on the most-reviewed Solidity code on earth, it has no business flagging yours.

Vague answers here ("very low", "we're very accurate") mean they've never measured it.

3. "Every finding — is there a proof of concept?"

A "High: reentrancy possible" with no PoC is a hypothesis, not a finding. The auditor should be able to show you the exact call sequence that triggers the bug, ideally as a runnable test.

The corollary matters just as much: a good auditor will retract things that don't hold up. I recently spent an hour building the case for a fund-locking overflow — then checked one constant, realized it would take 10¹⁵ years to trigger, and deleted it. That deletion is the product. You're paying for the judgment to know the difference between "looks scary" and "is exploitable."

4. "What happens after I fix the bugs?"

Two things separate a one-off from a real engagement:

A free re-review after remediation. Fixing a bug can open a new one. If "we found it, good luck" is the whole deal, that's half a service.
Continuous coverage. Your code doesn't freeze at launch — every push can introduce a vulnerability. The best security posture isn't a one-time PDF; it's a re-scan on every commit plus a monthly report. Ask whether they offer ongoing monitoring, not just a snapshot.

5. "Will you tell me plainly when my code is good?"

This sounds soft. It's the most important one. An auditor with incentives to find problems will find "problems." You want the person who, when your contract is genuinely well-built, says so — and tells you the one area that would actually benefit from a deeper look.

Honesty is the only thing you can't verify from the outside until it's too late. So probe for it in the conversation. Do they hedge everything to cover themselves, or do they commit to clear judgments and explain their reasoning?

The uncomfortable middle

Here's what the checklist reveals: the $60 gig usually fails #2 and #3 (it's scanner output, no PoCs, no measured FP rate). The $30k firm passes everything — but for a small protocol pre-mainnet, the price and timeline can be out of reach.

There's a real middle: independent reviewers who are fast, affordable, and rigorous — who measure their false-positive rate, ship PoCs, give you a clean bill when it's warranted, and offer ongoing monitoring. That's the segment I work in, and it's the right fit for most teams launching their first serious contract.

Whoever you hire, run the five questions. The good ones will welcome them.

I do fast, honest Solidity security reviews — custom detectors plus manual verification, zero false-positive noise, PoCs for anything real, and a straight answer when your code is solid. Details in my profile.

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

juan23z — Sun, 19 Jul 2026 21:56:07 +0000

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

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 247 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.

5 false positives that fool naive Solidity scanners (and how to kill them at the root)

juan23z — Fri, 17 Jul 2026 16:01:47 +0000

In a paid audit, a false positive is not just noise — it's a credibility killer. Hand a founder a "CRITICAL: unprotected fund sweep" that turns out to be safe-by-design, and you've spent your only currency: trust.

We run a heuristic scanner over Solidity before a human ever looks at the code. The scanner's job is recall (surface everything suspicious); the human's job is precision (confirm what's real). But every false positive the scanner emits is time the human burns — and if one ever leaks into a report, it's reputation burned.

Here are five patterns that fool naive static heuristics, why each is a false positive, and how we fixed them at the root — not by muting the rule, but by teaching it what it was missing.

1. The donation "vuln" that is actually the defense

The classic donation/inflation check flags any balanceOf(address(this)) used in accounting. But look at this:

uint256 balanceBefore = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amount);
uint256 balanceAfter  = token.balanceOf(address(this));
uint256 received = balanceAfter - balanceBefore;   // credited to the user

This is the fee-on-transfer-safe pattern. A donation before the call inflates balanceBefore and balanceAfter equally, so received is unchanged. The balanceOf here is the mitigation, not the bug. A scanner that greps for balanceOf(this) without recognizing the before/after delta flags the exact code that defends against the attack it's warning about.

Root fix: recognize the balanceBefore/balanceAfter delta idiom as safe; only flag when the raw balance feeds a share-price or ratio directly.

2. `corruptedReserve =` is not "reserve accounting"

A subtler version of the same detector matched a share-accounting pattern via a loose regex like reserve\s*=. It fired on:

corruptedReserve = toSweep;   // matched "Reserve =" as a substring

That's a variable name, not accounting. The lesson: word-boundary your patterns. \breserve\s*= doesn't match inside corruptedReserve, sharePrice, or collateralRatio. A single missing \b manufactures false criticals.

3. Permissionless ≠ unprotected, when the destination is fixed

Access-control detectors love to flag sweep/rescue/withdrawAll functions with no onlyOwner. But callable-by-anyone is only dangerous if the caller can redirect the funds:

function sweepUnclaimed() external {          // no modifier — flagged CRITICAL
    uint256 amount = token.balanceOf(address(this));
    token.safeTransfer(recoveryAddress, amount);   // fixed, set at init
}

Whoever calls it, the money goes to a predetermined recoveryAddress. This is a keeper pattern — permissionless on purpose, safe by construction. It's a false positive.

Root fix: for a sweep, only flag when the transfer destination is msg.sender, tx.origin, or a function parameter (something the caller controls). A fixed state variable → safe. (And watch the error direction: when in doubt, keep the finding — better a reviewed false positive than a blinded real one.)

4. Reentrancy on a local variable is not reentrancy

"External call before state update" is a great heuristic — until it counts a local as state:

token.transfer(to, amount);
uint256 len = holders.length;   // "state written after external call" — but it's a local!
for (uint256 i; i < len; ++i) { ... }

len is a stack variable. So is uint256 gasUsed = .... So is a write to a memory array (returnData[i] = ...). None of them is shared storage; none can be corrupted by re-entry. The detector was reading the assignment's variable name but not the type keyword in front of it, so uint256 len = looked like a storage write.

Root fix: classify the write target — declarations with a primitive/memory type, and names declared memory/calldata/new in the same function, are locals. Only a genuine storage write after an attacker-controllable call is reentrancy.

5. Interface declarations are not unprotected functions

Flattened files bundle interfaces and implementations together. A function declaration has no body:

function setDepositLimit(uint256 x) external;   // interface — no body, no modifier possible

Naive brace-matching grabbed the { of some later function and reported this declaration as an "unprotected config function." Root fix: if the ; comes before the {, it's a declaration — skip it. And skip flatten files entirely; they duplicate code you'll analyze in its real location.

The meta-lesson

Every one of these was fixed with a control test that proves two things at once: the false positive is gone and the real bug still fires. That second half is the discipline that matters — it's easy to silence a noisy rule and go blind. Suppress in the safe direction: when the classifier is unsure, keep the finding for a human.

Because that's the real architecture: the scanner surfaces, the human confirms. The tooling exists to make a careful auditor faster, not to replace their judgment. A zero-false-positive report isn't a model output — it's a heuristic that casts a wide net plus a human who verifies every survivor before their name goes on it.

That's the standard we hold. If you're shipping a Solidity protocol and want a review that reads the code the way an attacker would — fast, honest, and without a wall of false positives — let's talk.

Fiverr: https://fiverr.com/s/P2kNDP0
Portfolio + sample report: https://juan23z.github.io
DM me on X: @NawelJuan

Your audit expired the day you made the next commit

juan23z — Tue, 14 Jul 2026 10:45:44 +0000

Mirror/dev.to. Positions continuous monitoring (our wedge).*

You paid for an audit. The firm reviewed a commit hash, handed you a PDF, and moved on. You shipped. Then, like
every real project, you kept building: a new feature here, a parameter tweak there, a "quick fix" before a
weekend deploy.

Here's the uncomfortable truth: that audit covered a snapshot that no longer exists. The moment your first
post-audit commit landed, you were running unaudited code again — often the exact kind of rushed change where
bugs are born.

Where the money actually leaks

Look at the post-mortems. A huge share of DeFi losses aren't in the audited launch code — they're in what came
after:

An "innocent" refactor that flips a Floor to a Ceil in a share-conversion path.
A new integration that reads a manipulable totalAssets.
An upgrade whose access control wasn't gated as tightly as the original.
A hotfix deployed on a Friday with no time for a fresh review.

The audit didn't miss these. They didn't exist yet when the audit happened.

The gap is structural, not a failure of the auditor

One-time audits are priced and scoped as snapshots. That's fine for a launch gate. But your risk surface is a
moving target, and a snapshot can't cover a moving target. For a small or fast-moving protocol, the window
between "audited" and "materially different code in production" can be days.

What actually closes the gap: continuous review

The fix isn't "audit more often" (expensive, and you'd still have gaps). It's to make review continuous:
watch the contracts, and re-review automatically on every change/deploy — so the delta between your live code and
your last review is always small enough to reason about.

That's exactly what we do. An autonomous engine watches your repo 24/7; every new commit or deploy triggers a
fresh pass over the changed surface, and you get an alert plus a monthly report. It costs a fraction of an audit
per year, because the marginal cost of another scan is near zero.

A one-time audit tells you your code was safe on a Tuesday in March. Continuous monitoring tells you it's still
safe today.

We do fast, affordable security reviews for small protocols — then keep watching. Sample report:
https://juan23z.github.io/sample-audit-report.html · First month of monitoring free with any review.

I offer continuous smart-contract monitoring — I re-audit your contracts on every change and send a monthly report, so security keeps up as your code evolves. Custom detectors + manual verification, 0 false positives on all of OpenZeppelin. Sample report · Get in touch

7 ways to drain an ERC-4626 vault (and how a good protocol closes each one)

juan23z — Tue, 14 Jul 2026 09:28:01 +0000

Based on real audits of production vaults and AMMs.

A tokenized vault (ERC-4626) looks simple: deposit assets, get shares; burn shares, get assets back. Yet the
4626 is one of the contract types where the most funds have been lost. These are the 7 cracks I check in
every vault, and how each is properly closed:

1. First-depositor inflation. The classic: the first depositor mints 1 wei of shares, donates assets to
the vault, and rounding makes the second depositor receive 0 shares — losing their deposit. Closed with
virtual shares/assets (OpenZeppelin's +1 and 10**offset pattern) or a minimum initial deposit.

2. Rounding in the user's favor. On every asset↔share conversion, if rounding favors the withdrawer, the
vault is drained penny by penny. Golden rule: deposit/mint round against the user; withdraw/redeem too. A
single Floor where a Ceil belonged = a leak.

3. Manipulable totalAssets. If the vault reads its assets from an external protocol (a "connector") and
that balance can be inflated (donation, oracle), the share price is manipulated. Closed by reading from
sources that can't be inflated and using trusted connectors, immutable per pool.

4. Reentrancy in hooks. Modern vaults call extensions/callbacks during deposits and swaps. If a hook runs
via delegatecall, a malicious extension is the vault. Closed by using call (not delegatecall),
checking the return value, and isolating extensions per pool.

5. Fee accounting as shares. Charging the fee by minting shares to the protocol is correct — but an
ordering bug (accruing without updating the "last total") means double-charging or misallocated dilution.
Closed by updating lastTotalAssets on every operation that touches the fee (deposit, withdraw, collect).

6. Access control on upgrades. Many vaults are upgradeable via beacon/proxy. If the upgrade path isn't
gated well, an attacker deploys malicious code into the vault. Closed with strict roles and, where
applicable, a timelock.

7. Bad debt not socialized correctly. When a position ends up with uncollectable debt, the loss must be
shared across LPs via a lossFactor — and beware dividing by totalUnits when it can be zero.

The difference between a vault that holds and one that gets drained isn't a big idea: it's discipline in
rounding, access control, and accounting. When we audit, we check all 7, one by one, with the real code in
front of us — not with assumptions.

Got a vault, an AMM, or any contract that moves funds and want a fast, honest review? See a sample report:
https://juan23z.github.io/sample-audit-report.html — or reach out: naweljuan@gmail.com

I run fast, honest Solidity security reviews (custom detectors + manual verification, 0 false positives on all of OpenZeppelin) plus continuous monitoring. Sample report · Order an audit

I open-sourced a Solidity security scanner with 0 false positives on all of OpenZeppelin

juan23z — Mon, 13 Jul 2026 14:37:17 +0000

I've spent months building an autonomous Web3 security system — it watches fresh protocols, pre-scans them, and re-audits client contracts on every change. I open-sourced its scanning core. MIT, needs only Python 3.9+ and git, zero API keys.

What it does

Point it at a repo, get a professional report (Markdown + HTML) in seconds:

python scan.py https://github.com/org/protocol --out ./report

Or run it in CI on every PR with a GitHub Action:

- uses: juan23z/openclaw-audit@v1
  with:
    path: contracts

It ships 12 heuristic detectors aimed at the bugs that actually drain vaults:

ERC-4626 rounding & first-depositor inflation
Donation / totalAssets manipulation
Oracle staleness (Chainlink latestRoundData)
Cross-function & read-only reentrancy
Access control on privileged functions
tx.origin auth, unchecked low-level calls
ERC-20 / ERC-4626 compliance
NatSpec-vs-code mismatches

The hard part: not crying wolf

Heuristic scanners have a reputation problem — they flag everything, so people stop trusting them. Reputation IS the product, so I obsessed over precision.

The bar I set: 0 false positives across the entire OpenZeppelin library. It's verifiable — clone OZ, run the scanner, get zero findings. Getting there meant fixing real bugs in my own detectors, e.g.:

A cast like uint48(bytes32(x).extract(...)) was being read as an interface call (a case-insensitive regex matched int48(...) as if it were IFoo(...)).
The reentrancy detector didn't recognize Uniswap V2's classic lock/unlocked guard, so it flagged swap/burn — 13 findings on V2 dropped to 1, and that 1 is a genuine CEI-order candidate on createPair.
The ERC-compliance check flagged every token that inherits its implementation from a parent as "missing transfer()" — the most common real-world pattern.

Result across libraries: OpenZeppelin 0, forge-std 0, solady low single digits, Uniswap V2 down to 1 defensible candidate.

It's honest about being heuristic

Everything it reports is a candidate — verify before acting. It's a fast first pass and a CI safety net, not a replacement for a real audit. The report says so explicitly.

Try it

Repo → https://github.com/juan23z/openclaw-audit

I'd genuinely love feedback — which detectors you'd want, false positives you hit, edge cases I'm missing.

(Disclosure: I also do human-verified audits + continuous monitoring as a paid service for small/new DeFi teams — details here — but the scanner is free and standalone, so use it however you like.)