Sixteen volunteers. Twenty-seven and a half hours. Three hundred and ninety open-source Bitcoin projects. Four thousand nine hundred and sixty-two security findings, of which eighty-five were rated critical and six hundred and thirty-five high severity.
That is the Bitcoin Red Team’s first sprint, and whatever you conclude about the methodology, the raw fact is worth sitting with: a volunteer group did in a little over a day what professional audit firms bill months for. The obvious question is why this did not exist already.
Bitcoin Is a Honeypot and Always Was
Bitcoin is roughly two trillion dollars of bearer instrument, defended by software, with no reversal mechanism and no insurer of last resort. It is the purest target in computing history: fully cyber-native, permanently final, and permanently online. Every incentive that has ever produced a security researcher points at it, and so does every incentive that has ever produced a thief.
The protocol has held up remarkably well under that pressure. The software around it — wallets, payment servers, swap services, libraries, the enormous surface area of tooling that people actually touch — has a more mixed record, and the two are constantly confused in public discussion. Bitcoin has never been broken. Things that talk to Bitcoin get broken regularly.
This is not a new observation, and the Red Team is not the first serious defensive effort in this space. Bitcoin Core has run a disciplined security disclosure process for well over a decade, and its review culture — multiple independent reviewers on consensus-critical changes, an aversion to unnecessary complexity — is the reason the base layer’s incident list is as short as it is. Organisations like Brink, Chaincode Labs, HRF and OpenSats have quietly funded the developers who do that unglamorous review work for years. The history is instructive: the 2010 value overflow bug that printed 184 billion BTC, and the 2018 inflation bug in Core that sat undiscovered for two years, were both caught by humans reading code carefully. That tradition is the foundation everything below is built on, and the Red Team’s own funding comes from exactly that lineage.
What has been missing is not diligence. It is coverage. Careful review has always been concentrated where the value and the reviewers are: Core, a handful of major libraries, the big wallets. The long tail — the hundreds of repositories that a real user’s real setup actually depends on — has never had anything like proportionate attention, because there was never enough skilled human time to give it. That is precisely the constraint that changed this year.
What They Actually Did
The Bitcoin Red Team was organised in late July and early August 2026 by Calle — the developer behind the Cashu ecash protocol — and Rob Hamilton, CEO of the Bitcoin self-custody insurance company AnchorWatch. It was a direct response to the Coldcard seed-generation disaster, which by then had already cost users well over $100 million. The reasoning was straightforward: if a four-year-old build-configuration defect could sit undetected in one of the most scrutinised hardware wallets in the industry, what else was sitting undetected everywhere else?
The group grew to sixteen researchers working around the clock across time zones. Their headline numbers, published by Calle after 27.5 hours:
- 4,962 findings filed across 390 projects
- 85 critical and 635 high severity issues
- An average of 2.31 high-or-critical findings per person per hour
- A reported 21% verification rate on findings
- Over $40,000 in AI inference costs, funded by OpenSats, burning around $10,000 per day
The engine underneath was a purpose-built harness of roughly 171,599 lines of code, designed not merely to flag suspicious code but to carry a finding through its whole lifecycle: identify, test, reproduce, and document. That last part is what separates a useful security report from noise. The team has said it intends to open-source the harness, including for companies that need to test closed-source code — which would make the tooling, not just the findings, the durable contribution.
Findings were disclosed directly to affected projects rather than published. That is the correct call and worth noting explicitly, given how much of the reporting focused on the headline count.
The Part Everyone Skips: Humans Were Still Required
Hamilton made a point in the coverage that deserves more attention than it got. The best results came from pairing subject-matter expert engineers with the models — because the AI could, in his framing, “smell out that something is wrong” while missing the specialised context needed to know whether it actually mattered.
That matches our own experience building and shipping firmware and hardware tooling. A model reading unfamiliar code is extraordinarily good at noticing that a pattern is anomalous. It is much weaker at knowing whether the anomaly is load-bearing — whether this particular unchecked value is reachable from an attacker-controlled path in this particular deployment, or whether it is dead code behind a compile-time flag that has been off since 2019. Domain experts supply that judgment. The pairing is the product; neither half is.
The Honest Criticism
This is a genuinely good development and we want to see it continue. It also has two real problems, and the effort is better served by naming them than by cheering.
The verification rate. A 21% verification rate means roughly four out of five filed findings had not been confirmed at publication time. That is not a scandal — early-stage triage always looks like this, and the team was explicit about the number rather than hiding it, which is to their credit. But headline counts of “4,962 findings” and “85 critical” travel much further and faster than the verification caveat attached to them, and the gap between those two numbers is where a good initiative’s reputation gets spent.
Maintainer burden. Open-source maintainers have been vocal for years about the cost of low-quality automated vulnerability reports. A plausible-sounding but wrong report is not free — it consumes the scarcest resource in open source, which is the attention of the one or two people who actually understand the codebase. Filing thousands of findings across hundreds of projects in a day is an enormous gift if the signal-to-noise ratio is high, and an enormous tax if it is not. The 79% of findings that were not yet verified are landing on volunteers.
Neither of these argues against the project. They argue for exactly the thing the third article in this series is about: if you are going to run models at this scale against real code, you should be running the models that can prove a finding is real, not merely suspect it. The difference between “this looks wrong” and “here is a working proof of exploitability” is the difference between a maintainer’s wasted evening and a patched vulnerability — and it is measurable, on published benchmarks, with results that should change how the next sprint is configured.
Why Boltz Matters Here
Four days before the Red Team’s sprint numbers were published, the swap service Boltz shut down indefinitely, citing automated AI-assisted attacks that outpaced its team’s ability to patch. We covered that in the first article in this series.
Put the two events side by side and you have the entire strategic picture of Bitcoin security in 2026. The same capability that let sixteen volunteers audit 390 repositories in a day is available to anyone who wants to attack those repositories, at the same price, without the ethics, the disclosure process, or the need to sleep. Boltz lost that race. The Red Team is an attempt to make sure the rest of the ecosystem does not.
This is why the “should this exist?” question is settled. Offence is already automated. A defensive effort of equal sophistication is not an escalation — it is the minimum viable response to a change that already happened. The honest critique of the Bitcoin Red Team is not that it went too far. It is that it should have started years ago, and that it is currently fighting with one hand tied behind its back for reasons that have nothing to do with Bitcoin.
That constraint — which models the defenders were allowed to use, and what the published capability data says about that choice — is the subject of the final article in this series. It is the part of this story we think has been reported least accurately, and it is the part D-Central has direct experience with.
