There’s a specific kind of week that changes how an entire industry thinks about itself. Bitcoin just had one, and it’s still unfolding.
It started with a number that kept climbing. It moved through a volunteer effort unlike anything Bitcoin’s open-source ecosystem has attempted before. And it included, almost as if to prove the point in real time, a live exploit against Lightning-connected merchant infrastructure while the audit was still running. This is the full sequence, and what it means if you hold Bitcoin, run a node, or trust any piece of open-source software with your funds.
Where It Started
I’ve covered the Coldcard vulnerability on this Substack as it developed, so I’ll keep this part brief. A firmware bug on certain Coldcard Mk2, Mk3, Mk4, Mk5, and Q devices disabled the hardware random number generator during seed creation. The safety check meant to catch this only confirmed the RNG setting existed, not that it was actually running. Seeds generated during the vulnerable window ended up with dramatically weaker entropy than intended.
What’s changed since I last wrote about it is the scale. Galaxy Research confirmed 1,719 BTC stolen, roughly $111 million, as of August 8, with investigators warning the true total could reach 2,055 BTC, close to $130 million, as more compromised addresses get identified. Coinkite has released a firmware patch and published a full remediation disclosure, and has stated the issue is isolated to firmware-level randomness generation, not a hardware design flaw. If you own a Coldcard and haven’t checked whether your seed was generated on affected firmware, that’s still the single most urgent thing to go verify. Migrating to new firmware alone does not fix a seed that was already generated weak.
That number, and the fact that it came from a device marketed for years as the gold standard of self-custody, is what triggered everything that came next.
The Sprint
In late July and early August, two people, a developer known as Calle, associated with the Cashu ecash protocol, and Rob Hamilton, CEO of custody insurer AnchorWatch, organized something they called the Bitcoin Red Team. The idea was straightforward and, as far as I can tell, without real precedent in this ecosystem: assemble volunteers, point frontier AI models at as much of Bitcoin’s open-source codebase as possible, as fast as possible, and see what surfaces before someone else finds it first.
Sixteen security researchers, distributed globally, worked around the clock for 27.5 hours starting August 4. The nonprofit OpenSats covered the compute bill, reported at roughly $10,000 per day, with AI developer Moonshot providing model access including its Kimi K3 system. No corporate sponsor. No VC funding. Just volunteers and a grant.
The results, by the numbers: 4,962 total findings filed across 390 open-source Bitcoin projects. Of those, 85 were classified critical severity and 635 high severity, meaning 720 findings, about 14.5% of everything filed, were rated serious enough to warrant urgent attention.
Calle’s own assessment, in a public update: “There’s a lot of chaos right now in the ecosystem.” Asked to characterize the overall state of things, the word used was blunter still: “extremely bad.”
Why This Number Is Actually Meaningful, Not Just Alarming
It’s easy to read “4,962 findings” and assume most of it is noise, and that instinct isn’t entirely wrong. Project owners confirmed the majority of the critical reports specifically, and researchers went further than most bug bounty submissions typically do, rebuilding working proofs of concept in local test environments before alerting maintainers. That’s meaningfully more rigorous than “an AI flagged something that looks suspicious.”
But the team was also transparent about where the real bottleneck now sits, and it’s not where you’d expect. Developers involved said finding flaws is no longer the hard part. AI has compressed that step dramatically. What hasn’t scaled at the same rate is verification and routing, getting each confirmed finding in front of the specific maintainer who can actually fix it, fast enough to matter. At roughly the 30-hour mark, only about 21% of findings had been independently reproduced by a second party, and fewer than 5% of the affected projects had received a formal upstream disclosure. Hamilton has been building automated tooling to move confirmed issues to the right teams faster, describing his current setup honestly as “only version one.”
His framing of the actual race underway is the sentence I keep coming back to: “The hardest part is coordinating to get things to the right people.” Not finding the bugs. Getting them fixed before someone else, with less generous intentions, finds the same thing independently.
The Exploit That Happened While This Was Running
Here’s the part of this story that turns an abstract statistic into something concrete, and it happened almost as if timed for maximum illustration.
Late on a Friday during this same window, attackers exploited a critical vulnerability in BTCPay Server, the open-source payment processor widely used by merchants accepting Bitcoin, specifically targeting Lightning nodes running behind it. The flaw let an unauthenticated remote attacker obtain “.macaroon” files, the credential files that grant software permission to control an LND Lightning node directly. With those credentials in hand, attackers drained nodes, closing channels and sweeping the funds out.
BTCPay confirmed the theft and told every operator running LND behind their software to update immediately to version 2.4.2 or take their server offline entirely. The project hasn’t disclosed exact figures on how many users were affected or the total amount taken.
Two of the confirmed victims put faces on the abstraction. Foundation, the hardware wallet manufacturer, had its own BTCPay Lightning node drained overnight, its CEO Zach Herbert confirming attackers closed its channels and swept the funds, though the company’s separate on-chain hot wallet was untouched. Citadel21, the Bitcoin publication run by the pseudonymous commentator hodlonaut, reported its own Lightning node swept as well, though it noted the amount held there was small.
The detail that ties this directly back to everything above: this specific vulnerability had already been identified and reported to BTCPay by members of the Bitcoin Red Team, as part of the same sprint. It got found. It got reported. And it still got exploited before the fix was fully in place everywhere it needed to be. That’s not a failure of the audit, it’s the clearest possible demonstration of exactly the bottleneck Hamilton described. Finding a flaw and getting it patched everywhere it matters, before someone hostile acts on it, are two very different races, and right now the gap between them is where real losses are still happening.
The Pattern This Confirms
I’ve been building toward this synthesis across several pieces now, and this week is the clearest evidence yet for the underlying claim. AI has changed the speed of both offense and defense in Bitcoin’s security landscape, and right now those two speeds are not evenly matched.
Attackers don’t need sixteen volunteers and a nonprofit grant to point AI models at open-source code. They can do it alone, quietly, without publishing anything. Defenders, by contrast, need coordination, funding, trusted maintainer relationships, and a responsible disclosure process, all of which take time that attackers simply don’t have to spend. The Bitcoin Red Team’s own findings prove the discovery side of that asymmetry can be closed, 390 repositories in 27.5 hours is a genuinely remarkable feat of coordinated effort. The BTCPay exploit, happening in the same window, proves the coordination and patching side of that asymmetry is still very much open.
Neither side of that story cancels the other out. Both are true at once, and I think that’s the honest state of things right now rather than a reason for either panic or complacency.
What This Actually Means For You
If you’re running self-hosted infrastructure, LND, Bitcoin Core, BTCPay, or any other open-source Bitcoin software, treat “check for updates” as a standing weekly habit right now, not a someday task. This specific week demonstrated concretely what the gap between disclosure and patching costs when you’re not on top of it.
If you hold funds on a Coldcard, this bears repeating because it’s the single highest-leverage action available, verify whether your seed was generated on affected firmware, and if so, migrate to a newly generated seed rather than assuming an update alone resolves it.
If you’re evaluating any piece of Bitcoin infrastructure going forward, hardware or software, a reasonable new question to ask is whether the maintainers have engaged with efforts like the Red Team’s work, and how quickly they’ve historically moved from disclosure to shipped fix. That responsiveness is now a meaningfully different signal than it was a year ago.
And more broadly, this is exactly the kind of week that should reinforce, rather than undermine, the case for running your own infrastructure instead of trusting a black box you can’t inspect. Not because self-hosted software is immune to bugs, this week proves conclusively that it isn’t, but because understanding your own setup well enough to actually act on a security disclosure the day it drops is the difference between being protected by this kind of effort and being a statistic in next month’s version of this article.
Where This Goes Next
The Red Team has said it plans to open-source the security harness it built for this sprint, meaning other teams and future efforts can replicate this kind of coordinated audit without starting from zero. Given how effective the discovery side of this sprint proved to be, I’d expect this specific model, volunteer-coordinated, AI-assisted, nonprofit-funded auditing, to become a recurring feature of how Bitcoin’s open-source ecosystem defends itself going forward, not a one-time response to a single bad month.
Whether the coordination and patching bottleneck closes at anywhere near the same pace is the thing actually worth watching from here.
If a month like this one has you thinking harder about counterparty risk and where you actually transact, a non-custodial, no-KYC peer-to-peer option worth knowing about is MostroEuropa, a European coordinator for the Mostro protocol running entirely on Lightning and Nostr.
Related reading on this Substack:
$38 Million Gone in 25 Minutes: What the Coldcard Vulnerability Actually Means (free)
AI vs AI: How Boltz’s Shutdown Reveals Bitcoin’s New Threat Model (free)
⚡ Zap me: zap@shadowbip.com 🐙 GitHub: https://github.com/shadowbipnode