Coldcard has disclosed an entropy-generation flaw that affected multiple versions of its hardware wallets, prompting firmware updates and a fund-migration warning for users. The issue, first raised by Coinkite on July 31, has since been linked by Galaxy Digital researchers to thefts exceeding 1,596 BTC—reported as at least $100 million—via coordinated attacks.

The incident is a reminder that even long-established hardware wallets can fail at the most foundational step of self-custody: producing the randomness used to generate private keys. It has also reignited a broader debate in the industry over how wallets prove to users—technically and practically—that their entropy sources remain secure in production.

Key takeaways

Coldcard attributed the problem to a specific fallback path in seed generation that could produce weak entropy on-device firmware, affecting certain firmware versions.
Galaxy Digital researchers say attackers exploited the weakness to steal more than 1,596 BTC through multiple coordinated attacks.
Coinkite states that devices where users generated their own entropy (for example via manual dice rolls) were not affected by the specific fallback path.
Ledger, Trezor, and Foundation emphasize different trust models—secure hardware, layered randomness, and open-source transparency—but all agree entropy generation must not silently degrade.
Security leaders argue that certification and testing should extend beyond components, requiring assurance that production firmware actually uses the intended randomness source.

Entropy flaws hit the core of Bitcoin key generation

Unlike bugs that directly break encryption or exploit Bitcoin’s consensus rules, the Coldcard vulnerability is rooted in something more subtle: randomness. Bitcoin wallets typically start by generating a seed phrase from random data; from that seed, private keys are derived. “Entropy” describes how unpredictable that randomness is.

If the randomness is weakened—or becomes predictable enough—attackers may narrow the set of possible keys, increasing the odds of reproducing private keys tied to affected wallet setups. In other words, the security failure is not merely about having “less randomness,” but about allowing determinism or partial predictability into a process designed to be unguessable.

Coinkite initially warned users that wallets created on affected firmware should be treated as at risk and that funds should be migrated to newly generated wallets. As researchers assessed the underlying cause over subsequent days, attention turned to how such an issue could persist for years without being detected.

How the issue may have entered production—and what’s confirmed

Core Lightning developer Dustin Dettmer suggested that the flaw may have originated from firmware changes in 2021. His theory centers on an intended interface with a hardware random number generator that was potentially disabled, causing wallet creation to fall back to a weaker pseudo-random number generator used by MicroPython.

Coinkite has not confirmed that exact chain of events, but it did describe the nature of the problem: “Certain firmware versions had a fallback path in seed generation that could produce weak entropy when generated on the device firmware itself.”

Coinkite also stated that manual-entropy setups—where users generated their own entropy via dice rolls or similar approaches—were not impacted by that specific fallback path. That distinction matters because it frames the incident not as a total break of the device, but as a conditional failure mode tied to how the seed was generated.

Experts note that RNG vulnerabilities are notoriously hard to detect. As stated by Ledger product security leader Vincent Bouzon, weak randomness can still pass output tests—meaning values may look random statistically even when the generator is compromised.

Different wallet architectures, different ways to earn trust

Hardware wallet makers generally agree on the principle that secure entropy generation is non-negotiable. Where they differ is in implementation and the methods used to establish confidence that the wallet is really using a strong randomness source.

Ledger’s model relies on dedicated security hardware. Bouzon said Ledger generates seeds using a true random number generator embedded in a certified Secure Element, with the entropy source certified under the AIS-31 PTG.2 standard and the Secure Element undergoing Common Criteria certification. He argued the Coldcard incident reflects a failure in one implementation rather than a verdict on secure self-custody, emphasizing that the architecture must prevent silent downgrade to an untrusted software-based source.

Trezor takes a layered approach. Its chief technical officer Tomáš Sušánka said Trezor combines randomness produced inside the device with randomness provided by the host computer, rather than depending on a single entropy input. He also pointed to entropy checks that are intended to confirm the device contributed unpredictable randomness during wallet creation. “The takeaway for the whole industry is that randomness cannot depend on a single source or a single line of code being correct,” Sušánka said.

Foundation’s Passport similarly uses multiple entropy sources and pairs that with transparency. Zach Herbert, Foundation’s CEO, said Passport combines randomness generated by separate hardware components before creating a wallet. He also highlighted that Passport firmware is published as free and open-source software with reproducible builds, enabling independent verification that what runs on the device matches the published code.

Certification gaps and the push for stronger assurance

The Coldcard event has underscored tension between what certifications and component testing can guarantee—and what users ultimately need to trust: that production firmware uses the intended entropy mechanism correctly under real conditions.

Security and infrastructure leaders argue that many existing validation schemes focus on individual parts, not the full behavior of the complete system in operation. Nick Percoco, chief security officer at Kraken (and formerly CSO at Uptake), called the entropy failure a “wake-up call” for the hardware wallet industry. He argued that certification often verifies components, but not whether production firmware actually invokes them correctly.

Percoco proposed an industry-specific assurance standard that would include independent validation of entropy sources, checks that firmware calls the intended hardware random number generator, and certification tied to specific hardware and firmware versions.

The debate also extends to how openness and security culture influence outcomes. Herbert argued that inviting external researchers and maintaining open-source practices are part of building resilient products, not just a matter of code transparency or auditing. The larger point from multiple stakeholders is that redundancy, verification, and accountability must span the full chain from hardware entropy to final seed generation.

What Bitcoin users should do after Coldcard’s warning

For Coldcard holders, the immediate action is straightforward: follow Coinkite’s migration guidance if the wallet was created using affected firmware versions. The purpose is to move funds to wallets generated with safe, newly created seeds.

More broadly, the episode reinforces a principle emphasized by custody-focused experts: designs that rely on a single device, single vendor, or single institution being correct can leave users exposed when that assumption fails. Michael Tanguma, head of product at Onramp Bitcoin, said the trust model for self-custody depends on vendors getting multiple layers right, while emphasizing that “architectural” mitigations—such as multisig setups with independently generated entropy—are the approaches that scale to real-world risk.

In short, Coldcard’s entropy issue appears to reflect a vulnerability in a particular implementation pathway rather than a claim that all hardware wallets are broken. Yet it demonstrates why randomness generation—the part most users never see—remains one of the hardest to verify and one of the most important to get right.

As Coinkite prepares a fuller technical postmortem “soon,” and as the industry responds to calls for stronger end-to-end assurance, the next thing readers should watch is whether wallet makers tighten their verification methods around entropy usage in production firmware—not just around isolated components.