I still remember the first time I held a Coldcard. The weight felt reassuring, the kind of solid plastic and metal that makes you think your coins are finally safe from everything the internet can throw at them. Then the numbers started rolling in last summer, and that quiet confidence took a hit. Roughly 1,816 Bitcoin vanished from more than 5,200 addresses. The total sat near $116 million at the time. The culprit was not some exotic zero-day or a sophisticated physical attack. It was a seed-generation weakness that had been sitting in the firmware since a March 2021 build configuration error.
That single mistake selected a weak software random-number generator on older devices. Effective seed strength dropped as low as 40 bits instead of the intended 128. Attackers could reconstruct private keys without ever touching the hardware. The story should have ended with a quiet firmware patch and a careful migration guide. Instead, it keeps coming back, most recently in a fresh public clash over who should have spotted the problem and when.
How The Dispute Flared Up Again
On November 9 the conversation reignited when Coinkite’s NVK posted a detailed defense. He listed at least fifteen external reviews or research efforts that had examined Coldcard hardware, firmware, RNG-adjacent tools, or release controls before the defect surfaced. Two paid third-party product reviews sat on the list—one for the Mk4 in 2022 and another for the Q in 2024. An OpenAI Cybersecurity Harness run by Rob Ham had generated 85 candidate findings. Several of those findings led to fixes. The seed-generation defect itself never appeared among them.
“The uncomfortable truth is that it took a new AI model to find what humans couldn’t,” NVK wrote. That sentence landed like a match on dry grass. Within hours Bitcoin developer Luke Dashjr pushed back hard. He said he had privately shared findings with Coinkite and was now making them public because the claim that humans could not locate the problem felt false. Dashjr was careful. He noted his look had been quick, not a full audit, and he was not claiming every item could be weaponized. Still, the core objection was clear: the assertion that only a sophisticated model could identify issues with the random-number generator did not match his experience.
Other voices joined quickly. Some accused the company of discouraging outside scrutiny of the code. Others pointed out that ongoing quality assurance is not the same as asking a team to review an entire codebase in one pass. One developer argued that looking for a needle in a haystack becomes far easier when QA is embedded at every step rather than applied only at the end. Shinobi pushed back in the other direction, saying reviewers had examined the entropy system without catching the defect and that a private message expressing concern is not the same as a formal security disclosure.
Earlier Warnings That Never Quite Landed
James O’Beirne’s posts from August resurfaced in the middle of the argument. He had started looking at Coldcard’s firmware in May 2025 simply to understand where the random-number generator obtained its entropy. He questioned the use of the libngu library, flagged hardcoded constants in the software fallback, and suggested linking directly against libsecp256k1. According to his account, the response was that the configuration was correct for physical devices and that any real problem would already have shown itself. He admits he did not pursue the matter with full rigor at the time.
The next day he mentioned receiving a second credible report of someone warning Coinkite about weak entropy back in 2021—four years earlier. That report was separate from an earlier Telegram conversation he had referenced. In his words, it was possible that three independent people had raised the issue and the warnings had been set aside each time. Whether those accounts are complete or still missing context remains an open question, but the pattern itself is what keeps the conversation alive.
I’ve found that in security work the gap between a raised eyebrow and a formal disclosure can be enormous. A casual comment in a chat or a short email rarely carries the weight of a written report with proof of concept. At the same time, companies that build tools meant to protect life savings have a special obligation to treat even informal notes with seriousness. The tension between those two realities sits at the center of this whole episode.
What The Technical Failure Actually Looked Like
The root cause was straightforward once it was mapped. A build configuration error in March 2021 caused older devices to fall back to a weak software random-number generator. On those units the effective entropy for seed generation collapsed. Instead of the expected 128 bits of strength, some seeds offered as little as 40 bits. That is a level of weakness an attacker with modest resources can brute-force without ever needing physical access to the device.
Funds began moving in four waves starting July 30. TRM Labs later described the scale: more than 5,200 addresses and roughly 1,816 BTC. Galaxy Research kept a running tally that put the value near $116 million at the height of the first reporting. Later movements continued into September. One attacker swapped roughly 10 percent of their holdings through THORChain into Ether while the rest stayed parked. An investigation update in August mentioned information had been passed to U.S. authorities. One researcher noted that an attacker’s identity “may be known to law enforcement,” though no confirmed identification or recovery has been publicly verified.
The practical advice that followed was clear and, frankly, a little brutal for users who had trusted the device for years. Firmware updates cannot repair existing affected seeds. The only safe path is to generate an entirely new seed on a patched device, create a verified backup, confirm a receiving address with a small test transfer, and only then move the remaining funds. That process is simple on paper and nerve-wracking in practice when the amounts involved are life-changing.
The Living Postmortem And What Remains Missing
Coinkite’s current security page describes its published record as a living postmortem. A separate detailed technical report is still listed as in preparation. The page carefully distinguishes targeted independent checks from a complete audit of every corrected firmware binary. Listed work includes hardware randomness testing, source reviews, and a reproducible build process. Current recommended releases are 5.6.3 for Mk4 and Mk5, and 1.5.3Q for the Q model.
That distinction matters. Many people hear the word “audit” and imagine a single thorough pass that covers every line. In practice most hardware wallet reviews are narrower. They examine specific components—randomness sources, secure elements, supply-chain controls—rather than every possible configuration of every firmware version. When a configuration error sits in an older build path, it can escape notice even when the broader system looks solid. That is not an excuse. It is simply the reality of how most security work is scoped and paid for.
Perhaps the most interesting aspect is how the conversation keeps circling back to the role of artificial intelligence. NVK’s claim that a new model spotted what human reviewers missed is both provocative and incomplete. AI can scan large codebases quickly and surface unusual patterns. Humans still decide which patterns matter, which ones are intentional design choices, and which ones require immediate action. The best outcomes usually come from the combination rather than from treating either side as a silver bullet.
Why Hardware Wallet Trust Is So Hard To Rebuild
Hardware wallets occupy a strange place in the Bitcoin ecosystem. They are sold as the final layer of protection, the device that keeps your keys offline and out of reach. When that layer fails, the psychological damage is larger than the pure financial loss. Users who followed every best practice—air-gapped signing, verified firmware, careful seed backups—still found themselves exposed. That outcome forces a deeper question: how much of our security model still rests on trusting a single vendor’s implementation of randomness?
Randomness is the quiet foundation of almost every cryptographic system. If the entropy source is weak, the rest of the design can be textbook-perfect and still collapse. Coldcard’s case is a reminder that even mature projects can carry configuration landmines for years. The 2021 build error sat unnoticed while the devices continued to ship and while multiple external eyes examined other parts of the system. That timeline is uncomfortable for anyone who prefers clean narratives about continuous improvement.
In my experience the healthiest response is not to abandon hardware wallets but to treat them with clearer eyes. Diversify across manufacturers when the amounts justify it. Test new seeds with small amounts first. Keep a mental note of which firmware versions were current when you first set up a device. And pay attention when independent researchers raise even informal flags. The cost of listening is low. The cost of dismissing soft warnings has just been demonstrated at scale.
The Broader Conversation About Review Culture
One under-discussed thread in the current exchange is the difference between paid product reviews and ongoing adversarial research. Paid reviews usually operate under defined scopes and timelines. Researchers are asked to look at specific surfaces. They deliver findings, the company remediates what it can, and the engagement ends. Adversarial research is messier. It can stretch over years, surface issues that fall outside any original scope, and arrive in the form of private messages rather than polished reports.
Both approaches have value. Neither is complete on its own. When NVK lists fifteen external efforts, he is describing a real body of work. When Dashjr and O’Beirne describe earlier private notes that did not trigger deeper investigation, they are describing a different kind of signal that the current system is not always equipped to receive. Bridging that gap may require new norms around how companies log and escalate informal reports, even when the reporter is not claiming a full proof of concept.
Kenneth’s point about quality assurance being embedded throughout the process rather than applied only at the end feels especially relevant here. Looking for a needle in a haystack is hard. Looking for a needle in a series of smaller piles is still hard, but the odds improve. Continuous attention to entropy sources, build configurations, and fallback paths would have raised the chance of catching the 2021 error earlier. That does not mean every project must hire a permanent security team the size of a major exchange. It does mean that randomness and seed generation deserve permanent, high-priority status in any hardware wallet’s internal checklist.
Practical Steps Users Can Take Right Now
If you hold funds on any older Coldcard, the migration path is non-negotiable. Generate a fresh seed on a device running the current recommended firmware. Write the new seed down carefully and verify the backup. Confirm the receive address with a small test amount. Only after that confirmation should larger balances move. Treat the old seed as permanently compromised even if it has never shown unusual activity. The weakness was in the generation process itself, not in later usage.
Beyond the immediate fix, consider a few longer-term habits. Keep a simple log of which firmware version was active when each seed was created. When a manufacturer publishes a new advisory, check that log before assuming you are unaffected. Diversify across device types if the total value justifies the extra operational overhead. And stay mildly skeptical of any claim that a single review cycle, human or machine, has closed every possible risk.
- Update to the latest recommended firmware before generating any new seed
- Verify the backup of the new seed offline and offline again
- Send a small test transaction and confirm receipt before moving the bulk of funds
- Document the firmware version and date of each new seed creation
- Treat any older seed generated under the vulnerable configuration as retired
Those steps sound basic because they are. The hard part is doing them under the emotional pressure that arrives when real money is at stake. I have watched people freeze at the moment of generating a new seed, afraid that any new process might introduce a fresh error. The only reliable antidote is slow, deliberate action and a willingness to move small amounts first.
What This Episode Reveals About Trust In Bitcoin Security
Bitcoin’s security model is often described as trust-minimized. In practice we still place a great deal of trust in the people and processes that build the tools we use every day. Hardware wallets reduce the attack surface, but they do not eliminate the need for careful engineering and ongoing scrutiny. The Coldcard case shows how a single configuration decision can undermine years of otherwise solid work.
It also shows how difficult it is to keep historical decisions visible. Firmware evolves. Build systems change. Documentation drifts. A decision made in 2021 can become invisible by 2025 even to people who care deeply about the project. That is not unique to one manufacturer. It is a structural challenge for any long-lived open or semi-open hardware effort.
The current debate is useful precisely because it refuses to settle into a simple morality play. NVK is not wrong that substantial review work occurred. Critics are not wrong that earlier signals existed and that the “only AI could find it” framing oversimplifies the record. Both sides are describing different parts of the same incomplete system. The productive path forward is to improve the system rather than to declare a winner in the latest exchange of posts.
Security is not a single audit or a single clever model. It is the accumulation of many imperfect looks over time, plus the willingness to treat soft warnings as seriously as formal reports.
That accumulation is still happening. The detailed technical postmortem remains in preparation. Additional independent researchers will keep examining the code. Users will keep migrating to fresh seeds. And the broader community will keep arguing about how reviews should be structured and how warnings should be handled. Those arguments are messy. They are also how the ecosystem slowly gets stronger.
Looking Ahead Without Easy Answers
No one can promise that the next configuration error will be caught on day one. What we can demand is clearer processes for logging informal reports, more continuous attention to entropy and seed generation, and greater humility about the limits of any single review cycle. AI tools will keep improving and will keep finding patterns humans miss. Humans will keep providing the context and judgment that pure pattern matching cannot supply. The combination is already better than either side working alone.
For individual holders the practical takeaway remains straightforward. Treat every hardware wallet as a tool that requires periodic re-evaluation. Keep seeds generated under older firmware under suspicion until proven otherwise. Move carefully, document everything, and accept that perfect security is a direction rather than a destination. The $116 million loss was real. The debate it continues to fuel is a chance to reduce the odds of the next one.
In the end the most valuable outcome from this episode may be a quiet shift in culture. Fewer soft warnings dismissed. More attention paid to the unglamorous corners of the codebase where randomness lives. A slightly lower tolerance for the claim that any one process has already looked hard enough. Those changes do not make headlines, but they are the kind that actually protect the next set of users who decide to take self-custody seriously.
The Coldcard story is not finished. The technical postmortem is still coming. Further analysis of the stolen funds will surface. And the argument about human versus machine review will flare up again the next time a subtle defect appears. That ongoing tension is healthy. It keeps the pressure on manufacturers and researchers alike. For those of us who simply want our coins to stay where we put them, the best response is to stay informed, migrate when necessary, and remember that even the solidest-feeling device is still the product of human decisions made under imperfect information.
That is the part I keep coming back to. We build these tools because we want to remove trust from the equation. Then we discover that the tools themselves still require a great deal of trust in the people who designed the randomness, the people who reviewed the firmware, and the people who decided which warnings deserved deeper investigation. Closing that remaining gap is the real work still ahead.
