The data indicates the most widely trusted Bitcoin hardware wallet was exploited in the simplest way possible.
This week, roughly 594 BTC disappeared from about 500 Coldcard wallets in 25 minutes. The attackers moved funds in one automated batch. Most of the addresses had been dormant since 2021. A few were as recent as 2026. The victims were not active traders. They were cold-storage hodlers who did exactly what the security industry told them to do: take the keys offline, buy the most respected open-source hardware wallet on the market, and wait.
They are now waiting for nothing.
I have spent years auditing risk infrastructure, and the first thing I check is not the cryptography. It is the compiler. It is the handwritten macro. It is the quiet assumption that the hardware random number generator actually ran. In this case, it did not.
This is not a mysterious zero-day. This is a bug. A compile-time check was written with #ifdef where it should have used #if. The result: firmware silently fell back to a non-cryptographic pseudo-random number generator. The private keys generated on warm boot were not random. They were predictable.
Let me walk through the failure.
Context: Coldcard’s place in Bitcoin self-custody
Coldcard, made by Coinkite, occupies a unique position in the Bitcoin ecosystem. It is not the largest seller. It is the most doctrinaire. Its marketing has always said: no USB unless you want it, no wireless, no cloud, open source, verifiable firmware. For the “proof-of-keys” crowd, Coldcard is the end of the argument. It is the wallet you recommend after you have already recommended the boring answer.
That reputation made the attack a structural event, not a price event.
The hardware wallet category runs on a core promise: the private key never leaves the device, and the device’s random number generator is anchored in the physical chip. Trust in that promise is the entire business model. Once a hardware wallet’s RNG is broken, all of its other security controls become irrelevant. The keys are the castle. If the castle walls are made from a 32-bit PRNG, no lock on the gate matters.
Core: The technical teardown
Let me be precise about the failure chain.
Modern STM32 microcontrollers contain a hardware true random number generator. On Coldcard devices, the firmware is supposed to draw seed material from that TRNG. Somewhere in the boot path, there is a compatibility layer from MicroPython that decides whether the RNG is available. That decision is made at compile time, not runtime.
The macro is named MICROPY_HW_ENABLE_RNG. The correct check is #if MICROPY_HW_ENABLE_RNG, which examines the value of the macro. If the value is 0, the RNG code is not compiled in. The author wrote #ifdef MICROPY_HW_ENABLE_RNG, which checks whether the macro is defined at all. Defining a macro with value 0 still satisfies #ifdef. So the firmware believed its RNG code was active when it was not.
The compiler saw the check and moved on. So did Coinkite’s QA. So did the community auditors who had the source code for years.
With the hardware RNG path disabled, the firmware fell back to MicroPython’s default random generator: Yasmarang. Yasmarang is not a cryptographically secure pseudo-random generator. It was not designed to be. It has a small internal state, and in this implementation its entropy came from user-visible events like the number of times the Settings button was pressed and the timing of that interaction.
Bitcoin Core developer Gregory Sanders reproduced the attack. His work is the single most important data point in this story. He was able to generate Coldcard private keys by simulating the seed input from button presses. That is not theory. That is an on-the-record proof that the private key space was small enough to enumerate.
Let me describe what the attacker likely did:
- Read the public Coldcard firmware, with or without AI assistance.
- Discovered the
#ifdefmistake and the Yasmarang fallback. - Built a precomputed list of low-entropy addresses. Because the seed is based on observable button-press counts, an attacker can simulate a set of plausible user behaviors and derive corresponding private keys.
- Scanned the Bitcoin blockchain for matching addresses.
- Found about 500.
- Waited until the moment was right, then drained them in 25 minutes.
The speed matters. Moving 500 wallets in 25 minutes is not a manual operation. It is a script. It is a bulk sweep. The attacker had the private keys before the transaction broadcast. The 25 minutes was just the execution window.
The affected models are not a single subset. Coinkite initially said the problem was limited to the Mk3. That was wrong. Block’s Max Guise examined the firmware and found the bug in the Mk2, Mk3, Mk4, and Mk5. Sanders confirmed the expansion. Coinkite had to walk back its “Mk4/Q/Mk5 are not affected” statement. External analysis beat the manufacturer’s own initial incident assessment. That is not a small detail. A vendor that does not know the blast radius of its own vulnerability cannot be trusted to contain it.
Let me add the “bug” word back in: The bug is old enough to vote. It appears in firmware versions spanning 2021 to 2026. It survived multiple product generations. It survived all of the open-source audits that were supposed to give Coldcard its reputation. It survived the “we are open source, we have nothing to hide” argument. It survived because it was invisible to anyone who did not look specifically at preprocessor directives and the RNG fallback path.
This is the kind of bug that gets product liability lawyers paid. It is also the kind of bug that should force the entire hardware wallet industry to stop patting itself on the back.
Why 25 minutes matters: precomputation, not luck
The 25-minute attack window is the tell. A random attacker who discovered a vulnerability after a firmware leak would need time to scan for targets, derive keys, and test transactions. This attacker did not. They moved exactly the wallets they wanted, in one coordinated sweep. That is the signature of a precomputed address list.
Precomputation changes the risk equation. It means the attacker may have generated more private keys than the 500 wallets they drained. The 500 is just the subset they chose to loot first. The remaining list may contain addresses with smaller balances, addresses that were not yet active, or addresses controlled by users who will deposit into old Coldcard-derived keys in the future.
That last point is the one that should keep security-conscious Bitcoiners up at night. A private key generated by a low-entropy RNG is not safe just because the attacker did not spend it today. The key is still inside the attacker’s search space. If funds move into that address tomorrow, they can be taken. The only remedy is rotation.
The AI question
Coinkite speculated that the attacker “may have used AI.” There is no direct evidence for that. There is also no direct evidence they did not. What is documented is a claim by a security researcher named DeLorme that he used Claude Opus 5 to find the vulnerability after the attack. That claim has not been independently verified. It should be treated as an assertion, not a fact.
But the assertion is plausible, and the plausibility is the story.
Source code has always been a double-edged sword. For a defender, it allows verification. For an attacker, it allows precomputed failure. What changes with large language models is the cost of that precomputation. An LLM can read the firmware, notice the #ifdef pattern, and ask the question: “What happens if this macro is zero?” It can do this across thousands of repositories in hours. A human auditor might do the same in weeks. A competent security researcher might already know. But the competence threshold is dropping.
In the absence of data, opinion is just noise. The data here is uncomfortable: the source code was public for years, and no systematic audit caught the flaw. An AI-assisted researcher found it after the exploit. Whether the attacker used AI or not, the next attacker will. The relevant question is not “did AI do this?” The relevant question is “can your security-critical code survive an LLM looking at it?” For most projects, the answer is no.
Market impact: small numbers, large signal
Let me run the market arithmetic.
594 BTC is about 0.0003% of the total Bitcoin supply. It is not enough to move the price. The 562 BTC still sitting in the attacker’s wallet is not even enough to create a material sell wall against $20 billion of daily volume. The direct market impact is overstating it. The market impact is structural, not numerical.
The structural impact is in the hardware wallet sector. Coldcard is a premium, high-conviction brand. Its users are not casual buyers. They are the people who tape their BIP39 cards to steel plates. When that group loses private keys, the message propagates differently. It does not say “one wallet failed.” It says “the safest wallet was unsafe.” That is why the attack is more than a $38 million event. It is a reset of expectations for a whole category.
There is also a behavioral shift. Hard wallet users who were dormant for years are now learning migration procedures. Some will move to Ledger, Trezor, or BitBox. Some will move to multisig. Some will abandon hardware wallets entirely and use a well-audited software wallet on a laptop. The diversity of exit directions creates uncertainty. In a sideways market, uncertainty is the main currency.
Competing wallet vendors will probably see a short-term bump in sales. That is a transfer of trust, not an increase in trust. Every hardware wallet vendor should be asking whether its firmware has the same fallback pattern. If they are not asking, they are part of the problem.
Ecosystem: open source did its job, after the attack
The usual narrative is that open source failed here. That is wrong. Open source allowed Block’s Max Guise to inspect the firmware and expand the affected model list. It allowed Gregory Sanders to reproduce the attack and post a warning. It allowed DeLorme to claim a post hoc AI-assisted find. The transparency did not stop the attack, but it did accelerate the diagnosis.
What failed is the process around the open source. Publication is not the same as verification. The Coldcard firmware was public, but the audits were ad hoc, unpaid, and unstructured. There was no mandatory external review process. There was no bug bounty large enough to make a security researcher invest weeks in preprocessor macros. For years, the project relied on a model that assumes a global army of auditors is staring at every commit. That model is a myth.
This is why the involvement of Block is important. It was not a coordinated public audit. It was a private actor with security talent doing the analysis that the ecosystem assumes is happening. That should be institutionalized. Hardware wallets are infrastructure. They need independent certification, continuous fuzzing, and mandatory disclosure windows. If a bug like this can survive five years, the difference between “published” and “audited” is not semantics. It is a class-action complaint.
Bitcoin Core developer Sanders said the moment was “time to panic.” I would not use the word panic. I use the word verify. Every Coldcard user should verify the firmware version, check the affected list, and move funds to a device whose RNG path has been externally confirmed. The problem is that external confirmation is exactly what we do not have. Not for Coldcard, and not for any other hardware wallet.
Code is law. Bad code is bad law.
There is a phrase in this industry: code is law. The Coldcard incident demonstrates the more useful version: code is law, and bad code is bad law. The firmware told the hardware it was using a true random number generator. The hardware was not. The user’s intent to secure funds was never translated into the machine’s behavior. The law was broken before the attack happened.
That framing matters because it moves the blame away from the victim. The victims did not click a phishing link. They did not share a seed phrase. They did not use a hot wallet. They did exactly what the security community told them to do, and the security community failed them. A vendor cannot claim “user error” when the RNG path was silently disabled by a macro.
This is also why external audit obligations are not optional. In traditional finance, a bank that claims to hold segregated assets is required to prove it. In Bitcoin self-custody, there is no equivalent requirement for hardware wallet vendors. The user is told to trust the code because the code is open. But the code was open for five years and the bug was still there. Trusting open code without paid verification is just a slower form of blind faith.
Contrarian: what the bulls got right
Let me steelman the open-source position. There is a legitimate argument that code transparency is still better than the alternative. Ledger’s closed-source architecture has its own trust problems. A closed supply chain can hide a vulnerability just as easily. The Bitcoin ecosystem generally rewards verifiable claims over marketing promises. That tendency is correct.
The bulls are also right that this attack does not prove hardware wallets are obsolete. It proves a specific implementation had a generic flaw. The concept of an air-gapped signing device remains sound. The private key should not live on a phone. The “only you hold your keys” principle is not refuted by a bug in one vendor’s firmware.
But the bulls made one enormous error. They claimed open source is a security feature because it invites inspection. They never asked who is paying for that inspection. The answer is no one. Coldcard users paid Coinkite for hardware, not for a professional security audit. The open-source community contributed code reviews, but no one had a contractual obligation to spend the 1,000 hours required to find this bug.
Security is not a function of visibility. Security is a function of incentives. If you want a bug like this caught, you need an attacker-level adversary with a defender-level budget. That means paid auditors, automated analysis, and a mandatory filing window. The open-source model can work. But it works only when the source is paired with institutional structure.
Regulatory angle: this is consumer protection, not securities law
This event does not trigger the Howey test. There is no token, no issuer, no investment contract. The regulatory stress will be in product liability and supply-chain rules. If a manufacturer’s marketing says “the safest way to store your Bitcoin” and a compile-time check allows predictable keys, that is a potential defect claim.
Canada’s Coinkite and the global customer base are the natural forum. The question is whether the jurisdiction can reach a Canadian small company for losses suffered in dozens of countries. That is an enforcement problem. The more immediate pressure will be on insurance and procurement: institutions will start asking hardware wallet vendors for independent audit reports, RNG validation, and a responsible-disclosure process. If you cannot provide those, you will not be on the approved list.
Regulators also cannot ignore the AI angle. If attackers can use language models to discover exploitable patterns in public firmware, the risk shifts from “who has the skills” to “who has the subscription.” This may eventually push regulators to require AI-assisted security audit for critical infrastructure. That would be the first time AI security becomes a compliance requirement. It is coming.
What you should do now
If you are a Coldcard user, do not wait for a future firmware patch to feel safe. The private keys in the affected address range are not something a patch can change. A patched device will generate new random keys, but the old keys still exist in the attacker’s possible preimage table.
Move funds to a newly generated wallet. Use a different device if possible. If you must reuse the same hardware, update the firmware, reset the device, and generate a new seed from a verified random source. Do not reuse the old seed. Do not keep the old addresses as a “collector’s item.” The risk is not symbolic.
If you are a multisig user, rotate all keys that came from Coldcard devices. If you are a business with a corporate treasury on Coldcard, treat this as a security incident even if none of your addresses were drained. The absence of a known loss is not evidence that the key is safe. In the absence of data, opinion is just noise.
If you are a hardware wallet manufacturer, hire an external firm to audit your RNG path. Not your overall architecture. Not your marketing copy. Your RNG path specifically: the compiler directives, the runtime fallbacks, the default random library in whatever embedded operating system you use. Then publish the audit results. Then fund a bug bounty that rewards boring bugs like a wrong preprocessor directive.
The hidden risk: 500 is a floor, not a ceiling
Let me end with the part that should scare readers. The 500 wallets that were drained are the wallets the attacker could identify and spend. The bug is not limited to those wallets. Any private key generated by an affected firmware with a low-entropy Yasmarang seed is theoretically in the enumerable space. The address list may be larger. The attacker may only have swept the largest or easiest balances.
If enough time has passed, the attacker may have generated an enormous preimage table. They may not need to attack again. They can wait for new funds to land in an old deterministically generated address. That means some of the remaining 562 BTC may stay put for months, not because the attacker is charitable, but because the market is still learning.
I have no evidence that the attacker has more addresses. But the absence of data is not a reason to assume the threat is over. It is a reason to move funds off any device affected by this firmware. If there is even a probabilistic argument that your private key is inside a known enumeration space, the only correct response is to generate new keys from a verified source.
Takeaway
The Coldcard attack was not a cryptographic break. It was a five-year-old compiler check that nobody treated as important. The industry’s strongest brand was brought down by a preprocessor directive.
Do not romanticize this. Open source did not fail. The process around it failed. Security is not a property you buy when you purchase a metal box. It is a discipline you fund, test, and pay for with attention. The next bug will not be #ifdef vs #if. It will be something equally banal. It will be in a layer that nobody audits because the visible layer looks safe.
If you hold Bitcoin on a Coldcard, migrate. If you build a hardware wallet, commission an external audit before you ship. If you regulate, bring product liability into the digital asset era. And if you believe “the code is open, so it is safe,” ask who is actually reading it.
The answer will tell you what your private keys are really worth.