On August 14, 2026, an attacker drained 594 bitcoin from a cluster of single-signature addresses in 25 minutes. The first instinct is to call it a hack. It is not. A hack implies an intrusion, a breach, a path that should have been locked. What happened here is worse: the private keys themselves were generated inside a predictable randomness space by a device that was supposed to be the last line of defense. 562 bitcoin still sit in one address. The rest of the story is not about a stolen key. It is about an enumerable seed space, silently produced by firmware that thought it was using hardware randomness.
The affected devices are Coldcard hardware wallets, sold by Coinkite since 2015. In the bitcoin self-custody ecosystem, Coldcard occupies the position of maximum paranoia. Its users are the people who say not your keys, not your coins and then buy a dedicated device to hold those keys. The hardware is built around an STM32 microcontroller and runs open source MicroPython firmware. For years, the pitch was simple: private keys are generated on the device, from a hardware random number generator, and never leave it. That pitch has now collapsed.
Static analysis reveals what marketing hides. Marketing said trust the hardware. Static analysis says the firmware checked whether a macro was defined, not whether the hardware random number generator was actually enabled. The vulnerable firmware versions, starting with 4.0.1, use a compile-time check based on #ifdef MICROPY_HW_ENABLE_RNG. In the C preprocessor, #ifdef only asks whether a symbol exists. It does not ask whether the symbol has a non-zero value. The build system defined the macro as 0. The guard passed. The firmware believed it had hardware entropy. It did not.
This is the classic fail-open pattern. A secure system should fail closed: if a hardware random number generator is unavailable, the device should refuse to generate wallets. Instead, Coldcard silently fell back to Yasmarang, a lightweight pseudo-random number generator designed for speed, not for cryptography. Yasmarang was never built to resist an adversarial search. Its entire output is determined by a small amount of internal state. Given enough observations or a reasonable search space, an attacker can reconstruct the state and regenerate every private key produced under that condition.
The proof is in the logic, not the promise. The promise was cold storage. The logic produced a private key distribution that an attacker can scan. The addresses that were drained were dormant addresses, created between 2021 and 2026. They were not random victims. They were selected because their value justified the effort of enumerating the seed space. The fact that 500 addresses were emptied in 25 minutes tells me the attacker came with an automated pipeline: scan a candidate key space, derive public keys, match them against the bitcoin ledger, and sweep matches. That is not a single-key theft. It is a batch forgery process.
Coinkite's initial incident response said the problem was limited to Mk3 and devices updated after March 2021. It specifically claimed Mk4, Q, and Mk5 were unaffected. That claim did not survive independent review. Block's team found a similar, though smaller, flaw in Mk5. Developer Gregory Sanders, who was part of the independent validation effort, said that it was time to panic and that Mk4 was probably not much better. This is a familiar pattern in incident triage: the first assessment draws the blast radius by product marketing tier rather than by technical boundary. If the same random number generation infrastructure is shared across models, saying one model is clean is an act of hope, not analysis.
Based on my audit experience, this bug should have been caught in the most basic code review. A preprocessor directive that confuses defined with true is exactly the kind of error that compilers warn about, or that a two-line test would expose. It survived for years for two reasons. First, the internal test environment probably did not mirror the production build configuration. Local builds may have had the macro undefined, while release builds defined it as 0. Second, the security review culture around hardware wallets has been focused on physical tampering, side-channel attacks, and seed material. Too few reviewers spend time on the build-time environment. That is the real systemic weakness.
Now the scope question. This is not a single key leak. Anyone who generated a wallet on affected firmware could be in the attacker's search space. The attacker does not need to move the stolen coins immediately. The coins sitting in that one address are a trophy and a liquidity problem at the same time. The attacker also holds something more valuable: a reusable key-generation function that can be pointed at any dormant address without requiring user error, phishing, or malware. The attack surface is not the computer. It is the randomness source inside the hardware wallet.
The AI subplot has been noisy but unproven. One developer claims Claude Opus 5 was used to reproduce the vulnerability. Coinkite says its own AI models missed it for years. Many people in the ecosystem suspect that AI-assisted security research found the flaw first. I am skeptical. The evidence so far is an anecdote, not a forensic record. The AI story is a distraction from a far more uncomfortable fact: the bug was public in open source code for years, and no human auditor or automated tool found it. That is not an AI failure. It is an incentive failure. Security researchers chase new protocols with bug bounties, not old firmware with dormant user funds.
Complexity is the camouflage for incompetence. The root cause here is not cryptanalysis. It is a failed macro check. The camouflage is not the code; it is the story that Coldcard is too safe to question. In my incident-review process, I classify any hardware wallet that silently degrades randomness as already compromised. It does not matter whether an attacker has already exploited that particular device. The distribution of possible private keys has been compressed from something astronomically large to something a GPU cluster can search. That is the same as not having a private key.
The contrarian position, and I will take it seriously because the evidence demands it, is that open source is also the reason we know what happened. Coinkite published a security notice. Block independently audited the firmware and corrected the official scope. External developers reproduced the failure within hours. A closed firmware would have produced a theft and a vague statement. The transparency that gave the attacker a roadmap also gave the defenders a verification path. That is cold comfort, but it is not nothing. The open source model did not prevent the bug, but it did prevent a permanent cover-up.
What does this mean for the hardware wallet market? Directly, brands like Ledger and Trezor may pick up some migrating users, but they should not celebrate. The entire category is now under suspicion. Trust moved from single-device hardware wallets to multi-signature and MPC arrangements, not because those systems are inherently flawless, but because they add redundancy. A single device is a single point of failure. If that device's entropy source is wrong, no PIN, no passphrase, and no titanium seed plate will save you.
The regulatory angle is quieter but real. This is not a securities issue. It is a product safety issue. Hardware wallets are the storage layer for billions of dollars of an asset class that is still mostly unregulated. If this incident triggers consumer complaints, agencies such as the US FTC or CPSC can open a product-safety investigation. The EU Cyber Resilience Act already contemplates mandatory security requirements for such devices. This event gives every regulator a concrete example of why a hardware wallet with fail-open randomness should not be treated as a consumer gadget.
Assume malice, verify everything, trust nothing. If you generated a wallet on affected Coldcard firmware, you should move your funds immediately. A firmware patch cannot undo a weak key. Upgrading the device does not increase the entropy that was burned into the old address. The private key on that ledger entry was produced by a generator with a searchable state space. The only sound response is to generate entirely new keys from a verified entropy source and migrate to multi-signature or MPC if the value justifies it.
Ownership is a ledger entry, not a feeling. The feeling of security was quietly violated in March 2021, and nobody noticed until August 2026. The last line of defense turned out to be a line of code that did not check the value of the thing it was protecting. The question that remains is not whether one attacker can sweep dormant addresses. It is whether other groups are already doing the same enumeration at scale. The proof is in the logic, not the promise. The logic says that every vulnerable wallet is a door left unlocked. The only rational move is to treat every such key as exposed, and build the next layer as if the attacker is already listing your address.
