Five hundred wallets. Twenty-five minutes. 594 Bitcoin — roughly $38 million at current prices — drained in a single automated sweep. These numbers do not describe a phishing campaign, a supply-chain interception, or a zero-day exploit against the Bitcoin protocol. They describe a miswritten compile-time preprocessor check embedded in the firmware of a Coldcard hardware wallet, the device that Bitcoin's most security-conscious users treat as their final line of defense.
The speed is the tell. Twenty-five minutes for 500 wallets means the attacker was not searching in real time. They held pre-computed private keys, or at least a seed space small enough to enumerate, before the first transaction reached the mempool. The sweep was execution, not discovery. By the time Coinkite confirmed the vulnerability, the funds had already moved. The open question — the one that will define this incident's legacy — is whether the damage stops at 500 addresses or whether this was merely the first pass over a much larger pool of silently compromised cold storage.
Coldcard occupies a niche no other hardware wallet can claim. It is not the consumer-friendly Ledger, with its secure-element chip and regulated compliance posture. Coldcard is the device of choice for the technocratic wing of Bitcoin self-custody: users who value open-source firmware, reproducible builds, and the ability to verify every line of code themselves. It is the wallet found in the hands of Bitcoin Core developers, protocol engineers, and high-conviction HODLers who consider third-party custody unacceptable. When Coinkite markets this device as the safest way to store Bitcoin, that is not mass-market advertising; it is a positioning statement aimed at people who would be insulted by advertising.
That positioning is precisely why this incident cuts so deep. The failure mechanism is straightforward: Coldcard firmware draws entropy from the STM32 microcontroller's built-in hardware true random number generator (TRNG). A compile-time check is supposed to verify that the RNG functionality is actually available before key generation proceeds. The check was wrong. Instead of evaluating a macro's value, the code tested the macro's existence — an #ifdef versus #if mistake that would be embarrassing in a weekend script and is disqualifying in a security-critical device.
With the check passing falsely, the firmware continued into what it believed was a secure key-generation flow. In reality, it silently fell back to MicroPython's built-in Yasmarang pseudo-random number generator — a non-cryptographic PRNG with a minuscule internal state and dangerously low seed entropy. On a device advertised as cold storage for high-value assets, the private keys being generated were constrained to a search space that an attacker, equipped with the right seed inputs, could enumerate exhaustively.
The timeline compounds the severity. On-chain analysis places the compromised UTXOs between 2021 and 2026. The defect persisted across multiple firmware generations and hardware revisions, spanning Mk2 through Mk5. For roughly five years, code that the community was invited to audit contained a flaw that should have been flagged by even basic static analysis. Nobody caught it.
Let me walk through the root cause as a sequence of assumptions, each individually defensible and jointly catastrophic.
First, the firmware team assumed the STM32's hardware TRNG would be available during key generation. That is a fair assumption on most STM32 variants; the peripheral is standard. But its availability can depend on clock configuration, power state, silicon errata, and other conditions that embedded developers routinely handle with conditional compilation.
Second, a developer wrote the conditional compilation check. Here is where the architecture cracked. In the C preprocessor, #ifdef MACRO tests whether a macro is defined, not what it equals. A definition like #define MICROPY_HW_ENABLE_RNG 0 passes an #ifdef check because the macro exists — even though its value explicitly disables the feature. The correct construct is #if MICROPY_HW_ENABLE_RNG, which evaluates the value and treats zero as false. This is not an obscure corner of the language. It is a textbook preprocessor trap, one every C developer encounters early in their career, and one that produces zero compiler warnings and zero runtime errors.
Third, the runtime firmware, believing the RNG was functional, proceeded to generate keys. When the hardware TRNG did not deliver the expected entropy, control slid into a fallback path: MicroPython's Yasmarang generator, seeded by a combination of timing measurements and user interaction — most notably, the number of times the user pressed the setup button. Gregory Sanders, a Bitcoin Core developer, reproduced the attack by replaying those button-press counts. The seed space was effectively enumerable.
Fourth, Yasmarang's internal state is tiny. A PRNG designed for memory-constrained embedded systems, its entire state fits in a handful of 32-bit words. It was never designed for cryptographic key generation, and no amount of clever seeding can make it cryptographically secure. The private keys derived from this path were predictable from the moment they were created. The attacker did not crack a private key; they knew it before the owner's first transaction was ever broadcast.
This distinction matters because it points to where the actual failure lives. Bitcoin's cryptography remains intact. The vulnerability is in the connective tissue between hardware and key generation — and, more importantly, in the absence of architecture-level verification that a security fallback could never silently degrade cryptography.
Now the uncomfortable question: why did five years of open-source scrutiny miss this?
The honest answer is that open-source community auditing is not an audit process. It is a loosely organized group of unpaid reviewers with no contractual obligation, no liability, and no accountability mechanism. For every researcher who reads firmware line-by-line, there are a thousand users who assume someone else is doing that work. The assumption is mutual — and the work goes undone. This is why I keep returning to a blunt conclusion: open source is a transparency mechanism, not a security model. Transparency is a necessary condition for security, but it is not sufficient. The code was open. The community was invited. The vulnerability sat there for half a decade.
Here, my own history colors my read. In 2017, I built my early reputation by manually auditing ICO whitepapers and small-cap smart contracts in Shanghai. I flagged a reentrancy vulnerability in a popular lending protocol just before mainnet. What I learned quickly is that the bugs that actually destroy capital are rarely in the complex business logic. They live in assumed-away infrastructure: an unchecked return value, a fallback path nobody exercised, a compile-time directive nobody read closely. Audits don't catch what compilers silently accept. The Coldcard vulnerability is exactly that family of bug, translated into C. If Coinkite's CI/CD pipeline had included even a basic gating check — static analysis of conditional compilation symbols, a unit test that forced MICROPY_HW_ENABLE_RNG to zero, a symbolic evaluation of the RNG init path — this bug dies at the commit stage. It did not. That absence, more than the bug itself, is the systemic failure.
The disclosure timeline deserves equal scrutiny, because it defines how the market should interpret future incidents. Coinkite acknowledged the issue within hours — genuinely fast, and the right call. But their initial scope assessment said only Mk3 devices were affected, explicitly stating Mk4, MkQ, and Mk5 were not. Then Max Guise at Block, conducting independent analysis, found the same defect class across Mk2 through Mk5. Newer devices carried the flaw too, at smaller scale, but real. Sanders confirmed the issue on Mk2 and Mk3, then extended his assessment to Mk4 as likely vulnerable.
The pattern is a classic manufacturer-underestimates-scope curve. The response was transparent, but the accuracy of the vendor's initial assessment was worse than the external analysis. That is a trust-relevant fact. In high-security products, the entity that writes the code is not necessarily the entity best positioned to find its flaws. Incentives differ: the vendor wants to contain user panic, preserve brand equity, and stabilize the narrative. External researchers have no such constraints. The lesson is structural: treat any single vendor's incident statement as a hypothesis, not a finding. In this case, independent analysis by Block and Sanders did more to establish the true scope than the formal disclosure did.
What about AI? Coinkite speculated that the attacker "may have used AI." The word "may" is carrying a heavy load. There is no direct evidence of AI use in the actual attack. What we have is DeLorme claiming he discovered the vulnerability using Claude Opus 5 on a cloned codebase — a claim with no third-party verification — and Coinkite's own statement that even the best AI models could not have found this a few weeks prior. Both claims cannot be comfortably true, and neither is independently confirmed.
But the AI question is a distraction if framed as "did AI do it?" The real issue is structural. A vulnerability like this is not complex; it is a pattern-matching problem. A model trained on millions of lines of embedded C code can be prompted to search specifically for preprocessor misuses. The barrier that previously required deep embedded experience has been lowered to a well-formed prompt. That changes the cost curve of offensive security, and the defensive side has not yet internalized it. Few hardware wallet manufacturers have implemented mandatory AI-assisted audit workflows. After this incident, that must change — not because AI definitively executed this attack, but because the capability is now public knowledge and cannot be unlearned.
I built a settlement layer for AI-agent microtransactions in 2026. One lesson from that work applies directly here: if you cannot afford to be wrong about a security assumption, you architect the system so that no single fallback can silently downgrade cryptography. Coldcard's firmware violated that rule. The AI narrative, true or not, does not change the architecture lesson.
Let me turn to the money, because the numbers tell a strange story. 594 BTC stolen, roughly $38 million. At the time of reporting, 562 of those 594 remained unmoved. That is the first signal this attacker is no panicked opportunist. Theft is easy; monetization is hard. Moving that much Bitcoin through regulated exchanges triggers compliance flags, and laundering through mixers is slow and imperfectly private. The attacker may be waiting for a better channel, or they may value control over conversion. Either way, these funds are not "gone" in a supply sense; they are immobilized in addresses that every blockchain analytics firm is now monitoring.
Relative to Bitcoin's circulating supply of nearly 20 million, 594 BTC is 0.0003%. Relative to daily spot volume, it is noise. There is no reason to expect a price event from this theft. When the 562 BTC eventually moves, it will not move the market either. But the structural damage is real, and it is not priced in any chart. The market never prices in the failure mode it hasn't seen yet — until it occurs, at which point it overprices the risk for years.
The victim profile makes this worse. The affected addresses are mostly dormant, single-signature cold-storage wallets created between 2021 and 2026. These are long-term HODLers — the demographic least likely to read security advisories, least likely to monitor their addresses, and most likely to discover the loss months from now. The 500 confirmed victims may be the first wave, not the complete set. If the Yasmarang seed space is as constrained as the reproduction suggests, there may be thousands of additional addresses whose private keys are within enumeration range. That is not speculation; it is the arithmetic of low-entropy key generation.
Three narratives have already congealed around this event, and all three are partially wrong.
First: "This is about Coldcard." It is not. The vulnerability lived in a firmware compatibility layer built on MicroPython. That same stack appears across the hardware wallet industry in various forms. I am not alleging that other vendors have the same bug — there is no evidence of that — but the industry has never required a standardized audit of RNG fallback paths. Every hardware wallet is only as secure as its weakest fallback, and those fallbacks are rarely the first thing external auditors examine. The rational response is not blind migration to a new brand; it is asking your current vendor for the audit trail of their RNG initialization path.
Second: "The attacker used AI." Maybe. But that is not the critical fact. The vulnerability was discoverable with static analysis and ordinary code review. Framing this as a novel AI-enabled attack conveniently shifts accountability away from a vendor process failure. We do not need AI to explain five years of unexamined code. We need to explain why a security-critical product shipped with a fallback that silently downgraded randomness, and why no verification layer proved that fallback could never engage.
Third: "Migrate your funds and you are safe." Migration is necessary for every affected Coldcard user. It is not sufficient. Moving assets to a different brand does not prove that the new device's random number generation is sound — it merely changes which set of assumptions you are trusting. And the mismatch between vulnerability and knowledge remains unsolved: the dormant HODLer, the exact demographic most exposed, is the least likely to read this analysis. That mismatch is itself a systemic failure that no wallet migration can fix.
The 25-minute heist did not attack Bitcoin. It attacked the assumption that open code plus good intentions equals secure hardware. That assumption no longer survives contact with the evidence. Every user holding funds generated on affected Coldcard firmware should treat those keys as compromised — now, not after reading one more advisory. The 562 BTC still in the attacker's address is not a market event; it is a tombstone for the era of unaudited RNG fallbacks.
The industry's next battle is not against the next attacker. It is against the internal confidence that says "our check works" without proving the check's inverse. Mandatory external security audits, AI-assisted defensive code review, and a hard architectural rule — every fallback path in a security-critical device must be proven inert, not merely assumed — are the minimal response. Because the most expensive sentence in this industry has always been the same: it should have been fine.