DEV Community: juan23z

I made "zero false positives" clickable — verify it on Morpho, Uniswap V4 & Solady

juan23z — Fri, 14 Aug 2026 18:09:41 +0000

"Zero false positives" is the easiest claim in smart-contract security to make — and the hardest to trust. So instead of asking you to take my word, I made it clickable.

I ran my Solidity security scanner against three of the most heavily-audited codebases in DeFi — Morpho Blue, Uniswap V4, and Solady — and hand-verified every single flag it raised. The whole thing is behind one interactive page you can click through yourself:

👉 https://juan23z.github.io/proof.html

For each flag it shows:

the finding the scanner raised
the exact code it pointed at
why, after manual review, it is a false positive — not a real bug

The result across all three codebases: every flag verified, zero shipped as a "finding." That is the whole point. A scanner that dumps 200 lines of maybes is worse than useless — it trains you to ignore it. Mine is tuned so that when it does flag something, it is worth your time.

Why this works: the same detectors run clean across the entire OpenZeppelin library. That is the calibration bar — if a check fires on OZ, it is noise, and it gets fixed. What survives that bar catches what actually drains vaults: first-depositor inflation, ERC-4626 rounding, oracle staleness, missing access-control modifiers.

If you are shipping a protocol to mainnet and want a review where every finding is manually verified — no false-positive spam — the proof of how I work is right there to click through. No sign-up, no pitch. Just the receipts.

— Juan (https://juan23z.github.io)

I ran my zero-false-positive scanner on Morpho Blue — all 3 findings were false positives

juan23z — Wed, 12 Aug 2026 18:59:36 +0000

Public security note — Juan (juan23z). Solidity/DeFi security, calibrated to zero false positives across all of OpenZeppelin. Portfolio: https://juan23z.github.io · Open-source scanner: https://github.com/juan23z/openclaw-audit

TL;DR: I pointed my custom detector suite at Morpho Blue — one of the most respected, most-audited lending primitives in DeFi. It surfaced 3 candidates. After hand-verifying each against the source, all 3 are false positives. No real issues. Here's the interesting part: why they're safe is a small masterclass in secure Solidity design — and how I confirm they're safe is the whole point of a zero-FP process.

Most scanners would have reported these 3 as findings and handed you a scary PDF. I don't ship noise — I ship what I can prove.

The 3 candidates, verified by hand

1. "Cross-function reentrancy in `liquidate()`" → FALSE POSITIVE

My detector flagged an external call (token transfer + optional callback) in liquidate(). But Morpho Blue famously ships without a nonReentrant guard — on purpose. It's secure by strict Checks-Effects-Interactions:

All state mutations — position[id][borrower].borrowShares, market[id].totalBorrowShares/Assets, collateral, and the bad-debt realization — happen before any external interaction.
The token transfer and the opt-in onMorphoLiquidate callback come last, when the protocol's accounting is already fully consistent.

Re-entering during that callback buys an attacker nothing — the state they'd try to exploit is already settled. This is CEI done right, and it's why Morpho doesn't need a guard. Not a vulnerability.

2. "Cross-function reentrancy in `_accrueInterest()`" → FALSE POSITIVE

The flagged external call is IIrm(marketParams.irm).borrowRate(...). The key context a naive scanner misses: the IRM (interest-rate model) is fixed at market creation and is part of the immutable market parameters — it is not attacker-controlled. A reentrancy vector requires an attacker-controlled callee; this is a trusted, market-configured contract, and the accounting updates are safe regardless. Not a vulnerability.

3. "Fee-on-transfer token not supported" → FALSE POSITIVE (documented assumption)

True, but by design: Morpho Blue explicitly documents that it is not compatible with rebasing or fee-on-transfer tokens. Flagging a stated, intentional design assumption isn't a security finding — it's already in the spec. Not a vulnerability.

Why this matters if you're shipping a contract

A scanner that yells "HIGH: reentrancy!" at Morpho Blue — code audited by the best in the space — is exactly the false-positive spam that makes automated tooling useless. The value isn't in flagging; it's in verifying, and being honest when there's nothing to report.

That's what I do: custom detectors + line-by-line manual verification, calibrated to zero false positives across the entire OpenZeppelin library. When I hand you a report, every finding is real and proven — and if your code is clean, I'll tell you that (and show you why), instead of padding a document to look busy.

If you're pre-mainnet and want a review with no noise — just what's actually a risk — I'm around. A sample of the exact report format: https://juan23z.github.io/sample-audit-report.html

— Juan

Two access-control hacks drained $1.4M this month - the one-line bug, and the check that catches it

juan23z — Fri, 07 Aug 2026 20:08:19 +0000

In the last few weeks two protocols were drained through the same class of bug: an access-control exploit. RISEx lost ~$673k. WEMIX.FI Lend lost ~$730k. Different codebases, same shape of mistake - a state-changing function that should have been restricted to an owner or role, but wasn't.

This is, year after year, one of the most common ways money leaves a smart contract. And it's one of the few high-impact bug classes a static tool can actually catch before deploy - because it's a property of the code, not of an off-chain secret.

The bug, in one screen

The pattern looks like this - a critical function with no guard:

// A function that moves value or changes who's in control...
function setPriceOracle(address newOracle) external {
    oracle = newOracle;            // no onlyOwner, no role check
}

function withdraw(address to, uint256 amount) external {
    IERC20(token).transfer(to, amount);   // anyone can call this
}

There's no onlyOwner, no onlyRole(...), no require(msg.sender == ...). Whoever finds it first calls it. Point an attacker's script at setPriceOracle (repoint the oracle, then liquidate the protocol at a fake price) or straight at withdraw, and the funds are gone.

The fix is trivial once you see it:

function setPriceOracle(address newOracle) external onlyOwner {
    oracle = newOracle;
}

The hard part isn't the fix. It's spotting the missing modifier in a 2,000-line codebase, on a Friday, days before mainnet.

Why most scanners are useless here

Every static analyzer "checks access control." The problem is they cry wolf: they flag every function without a modifier - including view getters, internal helpers, functions guarded by an inline require(msg.sender == owner), functions with a custom checkAccess() modifier, base functions that a child overrides with auth, one-time initializers guarded by an if (initialized) revert, and so on. You get 40 "unprotected function" findings, 39 of them noise, and you learn to ignore the list - right before the one real one ships.

So the whole game is precision. A finding is only worth anything if, when it fires, it's real.

The deterministic check (calibrated to zero false positives on OpenZeppelin)

I run an open-source scanner and I calibrated its access-control detector against the most-audited code in web3 - all of OpenZeppelin, 237 production contracts - until it reported zero findings, then kept only the checks that survived. Concretely, it flags a critical function (setX, mint, upgrade, withdraw, sweep, initialize...) as unprotected only when none of these are present:

an access modifier (onlyOwner, onlyRole, requiresAuth, ifAdmin, custom only* / *Only / governance-combined modifiers),
an inline guard in the body (require(msg.sender == owner), _checkOwner(), _onlyGovernance(), if (HUB != msg.sender) revert...),
a one-time-init guard (if (_initialized) revert, require(factory == address(0)) - a set-once clone/init setter isn't "unprotected"),
an override of a base function that is guarded in the concrete contract.

It also skips view/pure, internal/private (not externally reachable), and interface/flattened declarations. Each of those exclusions came from a real false positive I hunted down by hand and turned into a permanent, deterministic rule. The result: when it fires, it's worth reading.

That's the whole philosophy - a report that's silent on OpenZeppelin but loud on a genuinely unguarded withdraw() is worth more than one that flags 600 things.

The honest limits

A scanner catches the code bug: the missing guard. It will not save you from a leaked deployer key, a compromised hot wallet, or a malicious upgrade pushed by a real admin - several of this month's other losses were exactly that, and no static tool catches those. Access control in code is the part that's checkable before you ship, and it's worth checking, because it's cheap to catch and expensive to miss.

If you're days from mainnet

Run the scanner yourself (MIT, one command, or a GitHub Action on every PR). Or send me your repo and I'll do a free first pass - I only flag what's real, and if a paid report later isn't useful to you, you don't pay.

The two protocols above didn't need a $50k audit to avoid this. They needed one person to notice one missing word.

Hack figures and classification from DefiLlama's public feed (api.llama.fi/hacks).

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