ReinforcedAI
PROOF — CASE STUDY

8 scans, 46 High or Critical bugs

Between February and September 2026 we ran eight independent security scans against Subtensor — the blockchain that runs Bittensor, the largest decentralized AI network. This is the full record: what we reviewed, what we found, and where you can check it yourself.

What is Bittensor, and why this codebase matters

Bittensor is a decentralized network made up of over 128 independent "subnets" — specialized markets where competing teams (miners) produce AI work and validators reward the best of it in TAO, the network's native token. Two subnets make the case for why this matters beyond speculation: Templar (SN3) coordinated more than 70 independent, permissionless contributors to train Covenant-72B, a 72-billion-parameter language model — real enough to draw public comment from NVIDIA's Jensen Huang. Chutes (SN64) runs a decentralized AI inference marketplace and was the first subnet to cross $100M in its own token's market cap. Neither is a demo; both are infrastructure other people build on.

Subtensor is the blockchain underneath all of it — the chain that settles which validator owns which key, how stake moves between them, and who gets paid. It has no room for a rounding error, because a mistake here doesn't stay contained to one subnet's leaderboard; it touches ownership and stake movement network-wide. TAO itself has traded above a $2 billion market capitalization through 2026. That figure isn't ours — it's the rough scale of what a consensus bug in this codebase can put at risk.

Scope: eight scans across four workstreams

One full-runtime scan repeated twice, two mainnet release reviews, two in-progress branches, and two focused features — chosen for risk, not convenience.

2 scans Full runtime

2026-02-21 · 2026-09-06

Report available. The 2026-09-06 report is publishing soon.

2 scans Mainnet releases

PR #2643 (report) · PR #2769 (report)

Public on GitHub, plus a report.

2 scans Branches

Balancer + limit orders · Dynamic tempo

Report available.

2 scans Features

Staking + precompiles · Key swaps

Report available.

What we did

Reviewed

High-risk runtime and release changes.

Proved

Findings with runnable PoCs.

Triaged

Issues with the engineering team.

Validated

Fixes and regression targets.

The work covered the full delivery loop: review the exact change, prove the issue, help triage it, and support fix validation.

The work in numbers

8
Security scans
115
Submitted Medium+ bugs
46
High / Critical bugs
20.5%
Submitted findings rejected, vs. 80% typical AI benchmark
Note

Low-severity findings and five internal, non-submitted baseline candidates are excluded. Benchmark band: Ami et al., IEEE S&P 2024.

PRECISION, MEASURED AGAINST A NAMED BENCHMARK

7 unique High-or-above findings beyond what Trail of Bits' own open-source solution caught on the same scopes.

Trail of Bits publishes its security tooling as open source. We ran it ourselves against two of the same review scopes and compared its output to ours — it missed seven High-or-above findings we caught. We're not naming this to take a shot at a firm we respect — we picked Trail of Bits as our own design reference precisely because their audit reports set the bar for how this kind of work should be published, and their tooling is good enough that beating it on the same code, using their own solution rather than a strawman, is the clearest evidence we have that independent, intent-based verification catches more than automated pattern-matching does.

Method

Comparison methodology and scope list: publishing as a Library article.

Two severe examples

Reported through the same triage-and-fix-validation loop as every other finding in this scan.

Economic loss

Root dividend drain

When a validator's hotkey was swapped, the stake moved to the new key — but the marker tracking whether root dividends had already been paid on that stake did not move with it. The chain believed a payment hadn't happened yet, on stake that had already been credited. Full report — Staking + Precompiles (H-01) →

Ownership takeover

Validator hotkey takeover

The key-swap process checked that the account initiating the swap was a legitimate validator — but never checked that the destination hotkey actually belonged to that same validator. Stake and validator identity could end up pointed at a key its rightful owner didn't control. Full report — Key Swaps (C-01) →

Want this level of scrutiny on your own system?

If you want an independent, no-cost read on what your review process might be missing, we'd like to talk.

Claim a free review