Twenty-five minutes. Five hundred wallets. Five hundred ninety-four bitcoin. On the surface, the Coldcard incident reads like a scripted heist film, but the most disturbing detail is how ordinary the execution actually was. The attacker did not need quantum decryption, a corrupt employee, or physical access to a vault. They simply had the private keys. Most of the victim addresses had been generated between 2021 and 2026, quietly sleeping in cold storage. The narrative isn’t about a brilliant exploit; it’s about a failed compile-time check, a single wrong preprocessor directive that turned a hardware random number generator into a deterministic dice roll.
Based on my audit experience, I have spent the last decade watching infrastructure failures masquerade as black-swan events. In 2017, I spent weeks auditing an ICO’s Solidity code and found a distribution bug that only existed because the team had never tested a zero-balance edge case. This Coldcard bug feels disturbingly familiar. It is not the product of a novel cryptographic breakthrough. It is the result of a security check that was never actually checking.
For years, Coldcard has occupied a special niche in the bitcoin ecosystem. It is the device of choice for users who treat self-custody as a moral position rather than a convenience. The hardware is open source. The firmware is open source. The brand promise is that security can be verified by anyone with enough patience and discipline. That promise attracted a community of true believers: Bitcoin Core developers, high-net-worth hodlers, and technically sophisticated users who would never trust a closed black box. It also attracted something else: a false sense that public code means public verification.
The technical root cause, pieced together from Coinkite’s disclosures, Block’s independent analysis, and Bitcoin Core developer Gregory Sanders’ reproduction, is almost embarrassingly simple. The firmware should have drawn entropy from STM32’s hardware TRNG, a genuine source of random bits. Somewhere in the MicroPython compatibility layer, a compile-time check was supposed to confirm that the TRNG path was active. But the check used #ifdef instead of #if. In C, #ifdef only tests whether a macro is defined, not what its value is. If MICROPY_HW_ENABLE_RNG was set to zero, the check passed as long as the macro existed. The code then fell through to MicroPython’s built-in Yasmarang algorithm, which is not a cryptographically secure PRNG. Yasmarang is a compact, fast generator designed for small embedded systems, not for key generation. Its internal state is tiny, and its seed may be derived from observable events such as the timing or number of button presses. That means the produced private key space can be far smaller than the 2^256 space we expect. In the worst case, an attacker can precompute the likely keys for a large batch of Coldcard-generated addresses, scan the blockchain for balances, and then execute the transfer in one automated sweep.
This is not sophisticated espionage. This is a compilation-era typo in a security-critical control flow that survived for years and shipped in multiple product generations.
What happened after the bug became visible is arguably more important than the bug itself. From the timeline: roughly 500 wallets were drained in 25 minutes, nearly 594 BTC in total. At the time of reporting, 562 of those coins remained in a single attacker-controlled address, unmoved and unspent. That suggests a highly automated operation: precomputed private keys, batch-signed transactions, and no need to pause between targets. The attacker was not scanning the live network in real time. They had already prepared the keys and simply executed the cleanup.
The affected models turned into a moving target in real time. Coinkite initially confirmed only Mk3. Then Block’s Max Guise found the same defect across Mk2, Mk3, Mk4, and Mk5. Sanders initially confirmed Mk2 and Mk3, then noted Mk4 may also be vulnerable. This divergence is the real signal. A vendor that claims to know its own security posture should not require an outside company to identify the blast radius of its own firmware. It tells us that the internal validation culture, not just the compiler directive, was broken.
I have seen this pattern before. During my DeFi work in 2020, I spent months analyzing MakerDAO positions while the Dai peg dethroned. The protocols that recovered best shared a quality: they invited external scrutiny and adjusted quickly. Coldcard’s response was rapid, which is credit to the team, but the early “only Mk3” claim created a trust gap. Users had to piece together information from Coinkite, Block, and Sanders to understand whether their own device was at risk. In security incidents, information ambiguity is not neutral—it is a second-order harm. For 25 minutes, the attacker moved funds. For many hours afterward, the community argued about which devices were affected while the remaining balance sat under attacker control. That period of uncertainty is exactly where anxiety mutates into panic.
The AI subplot deserves measured skepticism. Coinkite has suggested that attackers may have used AI, but that is a hypothesis, not a finding. Separately, a researcher named DeLorme claimed to have used Claude Opus 5 to identify the vulnerability after cloning the repository; the claim has not been independently verified. I am not surprised by either claim. The code was public. The flaw is detectable by static analysis. A well-prompted AI model can find a pattern like #ifdef MICROPY_HW_ENABLE_RNG quickly, especially if it is told to look for places where a zero value might still be treated as enabled. The narrative isn’t “AI solved the Coldcard problem”; it’s “AI may have lowered the cost of finding a vulnerability that should have been caught by a simple grep.” If DeLorme’s claim is true, it is not proof that AI is magical. It is proof that the vulnerability was so obvious that a model with the right prompt could trip over it.
For defenders, the implications are uncomfortable. The code has been public for years. The vulnerability is a preprocessor directive. If human auditors did not catch it, and an AI assistant could flag it with guidance, the cost asymmetry in self-custody security is shifting. Attackers do not need to win repeatedly. They only need to find one silent failure in a firmware path, then wait patiently while the rest of the ecosystem continues to trust the product.
Let us also be clear about what this event does not do. A theft of 594 BTC is non-trivial for the victims, but it is a rounding error in bitcoin’s global liquidity. The 562 BTC that remain unmoved do pose a theoretical overhang, but even if dumped tomorrow, they would be absorbed by the market’s daily volume. The real damage is structural, not quantitative. It hits the asset class most people use to avoid structural damage: self-custody. The narrative was never about hardware; it was about verification. Every hardware wallet vendor now faces a version of the same question: can your firmware prove that its entropy source is alive? If the answer requires a manual inspection, the next AI-assisted attacker already has a checklist.
The fact that Block’s Max Guise and Bitcoin Core developer Gregory Sanders both contributed to the public investigation is a hopeful signal. It shows that competitive and academic scrutiny can fill gaps left by vendor self-assessment. But it also shows how fragile that safety net has been. The vulnerability existed in public source code for years. No mandatory third-party audit caught it. No clearly defined responsible-disclosure pipeline flagged it. The ecosystem was saved, at least in part, by coincidence and by an attacker who was careless enough to leave most of the stolen value behind.
The natural conclusion is that Coldcard failed because it was open source. But that is backwards. Open source did not cause the deficiency. The deficiency existed in the code; open source simply made it discoverable. The real problem is the myth that open source equals audited. Code being readable is not the same as code being read. Code being published is not the same as code being reviewed by people who understand C preprocessor macros, MicroPython internals, and hardware RNG paths. The value wasn’t in the source repository; it was in the verification pipeline around it, and that pipeline was not as robust as the brand suggested.
There is a second contrarian layer that deserves attention: panic migration may be more dangerous than the vulnerability itself. When users hear “your hardware wallet is broken,” many will buy a new device and immediately transfer funds. If they do so while the original device is still compromised, or if they move funds to a less secure hot wallet in the process, they can lose more than the attacker originally took. The value wasn’t in the plastic casing or the USB port. The value was in the cold discipline of not reusing seeds, verifying receive addresses, and understanding that emergency migration under stress is where most operational losses occur.
The incident also exposes a flawed mental model. We treat “hardware wallet” as a monolith, but the security boundary is really a chain: silicon TRNG, firmware bootloader, key generation logic, signing code, display driver, user verification process. Each link has its own failure modes. Coldcard’s failure happened at the link where a compile-time assertion silently became a no-op. That is not a reason to abandon hardware wallets. It is a reason to demand cryptographic proof that the entropy source is alive at runtime, not just at compile time.
If there is a single line to remember, it is this: trust is the only algorithm, but trust must be backed by reproducible evidence. The Coldcard event is not the end of self-custody. It is the beginning of a more honest conversation about what we mean by the word security.
The next narrative will not be about which wallet has the best-looking screen or the most aluminum. It will be about which vendor can prove that its random number generator actually ran, with runtime attestations and third-party audits that are not glossy PDFs but re-runnable tests. It will be about AI-assisted auditing on the defense side, not just AI-assisted exploitation on the attack side.
I want users to stop asking “is my wallet brand safe?” and start asking “can you show me the entropy verification test that runs on every boot?” If I had been auditing Coldcard’s firmware four years ago, the first thing I would have checked is whether the macro that disables the TRNG can ever be silently ignored. The answer, it turns out, was yes. The next question is more important: which other devices have the same silent #ifdef in their own biographies?