16 new detectors, and an accuracy floor we cannot regress past

Most product updates are changelogs. We try not to write those. The only question that matters is whether your protocol is safer today than it was 90 days ago. Here is the answer for Q2 2026.

We hardened the platform before we shipped new capability

If our own scanner is exploitable, none of the detection work matters. So that came first.

This quarter we closed a remote code execution in the platform, a report path-traversal write, and an unauthenticated request that could crash the API. The platform now fails safe and self-heals after a crash. Scans run isolated, so one cannot corrupt another’s results or leak memory. The API stays reliable under concurrent load on a persistent server.

You should expect this from any security tool you point at production code. Most do not work this way. That is fixable, and we fixed it.

Detection caught up to the real attacker playbook

16 new detector classes shipped this quarter. The headline ones cover vulnerability shapes the tool previously missed entirely:

• DEX spot price used as oracle. The canonical root cause behind flash loan price manipulation attacks. Detected directly.
• Transaction ordering and front-running. A class of issues every MEV-aware auditor knows by hand. The tool now flags them.
• selfdestruct patterns. The vector behind a long tail of bricked-contract and trapped-funds incidents.
• Uninitialized storage pointers. A Solidity foot-gun that still ships in production.

These are not academic categories. They map directly to what shows up in post-mortems.

We pinned the benchmark numbers as CI floors

This is the part most accuracy claims do not survive. Vendors run a benchmark once, publish the number, and never check again. We pinned ours.

On the public SmartBugs benchmark, Q2 2026 numbers:

• True positives detected: 308 markers, up from 277
• False positives: 1,286, down from 1,317

Both are now CI floors. Accuracy cannot regress past them without a build failure. If we ever drop the true-positive count or raise the false-positive count, the change does not merge.

That is the difference between a benchmark used for marketing and a benchmark used as a contract with the user.

Cross-contract analysis caught up to real codebases

The other meaningful accuracy work this quarter happened in inter-procedural and reachability analysis.

Vulnerabilities are now reported at the entry point an attacker actually calls, not somewhere downstream in a private helper. If nothing on the contract surface can reach the buggy code, the finding is suppressed instead of paged to your engineer at 2am.

Solidity inheritance is now modeled with correct C3 linearization, which closed a class of cross-contract misses earlier passes missed silently. Modern Solidity syntax, including call{value: …} option calls, is now fully recognized by the analyzer. Plus a batch of targeted false-positive reductions in the existing detector set.

Dependency separation across the stack

Third-party and vendored code is now cleanly split from the project’s own code, end to end across the engine, the API, and the UI. Findings in dependencies do not get mixed into the developer’s queue. The team sees what they own, separately from what they imported.

This sounds obvious. It is not done by most tools we have looked at.

The discipline that lets this stick

None of the above matters at the end of Q2 if the velocity drops by the end of Q4. So a meaningful chunk of the quarter went into the engineering systems that keep the bar from drifting.

• Test suite roughly doubled, from ~2,800 to ~5,800 tests, and made order-deterministic. Latent bugs surface before release, not in customer reports.
• Every accepted limitation is now a CI tripwire. Known false negatives and false positives are explicitly categorized into xfail tests, so any silent regression breaks the build.
• Strict typing and linting are hard CI gates. Untyped escapes are banned from production code.
• An automated review suite enforces engineering standards on every change.
• The shared-helper library roughly doubled, from ~350 to ~710 catalogued helpers. New detector classes ship faster because the underlying primitives are shared instead of re-implemented.
• A new consolidated guard and authorization library underpins the access-control and reentrancy detectors.
• The frontend toolchain is unified onto a single test runner with a raised coverage floor.

The point of all of this: the accuracy gains reported above are gains the next quarter cannot accidentally erase.

Client experience

Faster page loads. Mobile layouts that actually work. Graceful handling of errors and interrupted logins. Database-level pagination and indexing keep large scan histories responsive. Finding de-duplication means you get one precise result per bug, not a generic finding and a specific copy of the same issue.

The tool is faster to use, in addition to being more accurate.

What this means for you

If you are pointing Fidesium at your codebase today, three things have changed from 90 days ago that affect your security posture directly:

1. The classes of bugs the scanner can identify expanded to include flash loan oracle manipulation, transaction ordering, selfdestruct, and uninitialized storage. If your code has any of these, the tool now sees them.
2. The accuracy of the existing detection improved on a public benchmark, and that improvement is locked in by CI, not by marketing copy.
3. The platform itself is hardened against the kinds of attacks a security tool is most often blamed for missing in its own code.

Shortest version: you are getting more real findings, fewer false ones, on a scanner that no longer carries its own security debt.

Q3 will push further on cross-contract reasoning and Solidity coverage. We will write that one in 90 days.