Imagine placing your long-term Bitcoin savings in a hardware wallet—a dedicated device designed to ensure your private keys never touch an internet-connected computer. You carefully record your recovery words. You keep the device offline. You store everything securely and leave the Bitcoin untouched for years. Then, one day, you open your wallet software and the balance is zero. You did not reveal your seed words. Your computer was not infected. Nobody stole the physical device. Nevertheless, your Bitcoin is gone.
On July 31, 2026 UTC, this nightmare became reality across roughly 500 single-signature wallets. In a coordinated sweep lasting about 25 minutes, an attacker stole approximately 594 bitcoin, worth around US$38 million at the time. Source: CoinDesk
Today is August 4, 2026, and the Coldcard debacle continues.
The Weakest Link
Bitcoin’s cryptography was not broken. SHA-256 was not broken. Elliptic-curve cryptography was not broken. The attacker did not work backwards from public keys to calculate private keys. The failure happened earlier—when affected Coldcard devices originally created their wallet seeds. A wallet seed must be generated from highly unpredictable random information known as entropy. A normal 12-word BIP39 seed begins with 128 bits of entropy, creating a search space so large that guessing the seed is practically impossible. But affected Coldcard firmware did not always use its secure hardware random-number generator as intended. The resulting seed words still looked random. They passed the BIP39 checksum. The wallets operated normally and could securely sign transactions. But those seeds had been selected from a dramatically smaller and more predictable search space.
A Terrible Fallback
The central failure was a major misunderstanding during a software migration.
Earlier Coldcard firmware generated wallet entropy by directly calling the device’s hardware random-number generator. In March 2021, wallet generation was changed to use a new library interface called ngu.random.bytes().
The code configuration contained the comment:
“We have our own version of this code.”
That comment strongly suggests the developer believed the new rewrite already included—or automatically reached—Coldcard’s own secure RNG function, so no further connection was required. That belief was wrong. The rewrite only provided a new interface for requesting random bytes. It did not generate secure physical randomness itself and still had to be explicitly connected to the hardware RNG used by the older code. Because that connection was never made correctly, the seed-generation request went to MicroPython’s weak software fallback instead – that is, a predictable software substitute.
In simple terms: The secure hardware generator was still inside the device, but the rewritten seed-generation path did not reach it.
The misunderstanding created the wrong path. The existence of a weak fallback made the consequences catastrophic. For software responsible for creating permanent Bitcoin private keys, failure to reach the secure hardware generator should have stopped the device with an error. It should never have quietly continued using a weaker source. Sources: Block Engineering and Coinkite
The bug also remained in released firmware for years. Whatever software-review, testing and quality-assurance processes were in place, they did not detect that the product’s core seed-generation function had stopped receiving its intended hardware randomness. Coinkite also stated that a later AI-assisted security review failed to discover the issue. For a company whose central business is Bitcoin security, that failure is especially serious. Source: Coinkite
Where Strong Entropy Comes From
A properly functioning hardware wallet generates entropy by measuring unpredictable physical activity, such as electrical noise, temperature fluctuations or oscillator timing. This raw analogue input is processed into random bits. Dice rolls or coin flips can also provide strong entropy when performed correctly. Hashing can clean and combine randomness, but it cannot create entropy from a predictable source.
From 128 Bits to Something Far Weaker
A correctly generated 12-word seed should begin with 128 bits of genuine entropy.
For affected Mk2 and Mk3 firmware, Block’s analysis found that no cryptographically secure entropy reached ngu.random. If the device identifier, timing state and previous RNG calls could be determined or sufficiently narrowed, wallet generation became reproducible.
Later Mk4, Q and Mk5 firmware mixed in secure-element data, but only 32 bits of that secure input reached the reseeding process. The later devices therefore received some additional protection, but not the intended 128-bit security level. Sources: Block Engineering and Coinkite.
Compare the scales:
32 bits = about 4.3 billion possibilities
40 bits = about 1.1 trillion possibilities
128 bits = about 340 undecillion possibilities
Billions or trillions of possibilities may sound enormous, but modern computing can search spaces of that size—especially when the work can be optimised, distributed among machines or reused against many known Bitcoin addresses. A full 128-bit search space is in another universe entirely.
Hashing the weak output with SHA-256 made the final seed look random, but it could not create entropy that was never present. Attackers still only needed to search the much smaller underlying set of possible inputs.
How the Bitcoin Was Taken
Once an attacker understood the defective generator, they could reproduce its possible outputs offline. For every candidate seed, the attacker could derive its Bitcoin addresses and compare them against funded addresses visible on the public blockchain. When a derived address matched, the attacker had found the wallet seed—and therefore the private keys required to spend its Bitcoin. No internet connection to the Coldcard was necessary. No physical access was necessary. Nothing needed to be extracted remotely from the hardware wallet. The attacker could recreate the secret because the device had originally chosen it from a dangerously limited range. An address, public key or extended public key provided a way to test whether a candidate secret was correct. Source: Block Engineering
Updating the firmware only protects newly generated wallets. It cannot add missing entropy to an existing seed. Affected users must update their firmware, generate a completely new seed and move their Bitcoin to addresses controlled by that new seed. Coinkite says that at least 50 fair, independent and private dice rolls may have supplied sufficient separate entropy. A strong, unique BIP39 passphrase also adds another barrier. Neither, however, repairs the affected underlying seed itself. Source: Coldcard Security Advisory
The Real Lesson
Hardware wallets are often described as devices that keep private keys offline. That protection matters—but it assumes the private keys were secure when first created. The broader security chain is shown in the diagram below.
If strong entropy fails at the beginning, every later security layer rests on a weak foundation. Even flawless offline storage cannot protect a secret that was predictable from the moment it was created. The Coldcard did not need to leak its private keys from secure storage. The affected private keys were potentially reproducible from the day they were generated. Coldcard’s cryptography remained secure, but weak entropy made some wallet seeds guessable.
That is the Coldcard debacle: a device built to protect private keys failed at the more fundamental task of creating them securely.