What the Coldcard Exploit of $88M Worth of Bitcoin Taught Us About Wallet Entropy

Coinkite sent out a security notice on July 30, 2026, telling Coldcard Mk3 owners that seeds generated on their devices since March 2021 might be unsafe. Hours earlier, roughly 594 BTC (~$38M) had been swept from about 500 single-signature addresses. It didn't stop there: two more waves followed, and by August 2 Galaxy Research put the total at roughly 1,367 BTC (~$88.6M) across 4,585 addresses. Every drained address shared the same root cause: a seed with far less randomness behind it than anyone assumed.

Nobody phished these users, nothing leaked. This was a randomness bug that sat quietly in shipped firmware for five years. The takeaway isn't "Coldcard shipped a bug" - it's that entropy is the foundation the rest of wallet security sits on, and it can go quietly wrong in ways nobody notices until money moves.

What went wrong

A 12-word BIP-39 mnemonic is meant to carry 128 bits of entropy, meaning an attacker has to search through 2^128 possible seeds, a space no realistic amount of compute gets through.

The bug lived in a Mk3 firmware component called libngu, meant to pull randomness from the device's hardware RNG on its STM32 chip. Instead, due to a build error, it silently fell back to a software PRNG called Yasmarang, which was never built for security. Seeds generated this way landed around 40 bits of real entropy on early units and roughly 72 bits on later ones, nowhere close to 128. That's not a small shortfall - it's the difference between a search space no one can brute-force and one a motivated attacker can search directly.

This shipped in firmware 4.0.1 (March 2021) and stayed through 5.0.3. Five years passed before anyone noticed. Once one attacker showed the keyspace was searchable, others followed: what started as one wave of 594 BTC became three waves totaling roughly 1,367 BTC by August 2. Attackers are still sitting on almost all of it, which researchers read as waiting out the attention before cashing out.

Why this isn't really a hardware wallet story

The easy read is "hardware wallets have a weak point, software doesn't," or the reverse. Neither is right. Every wallet, hardware or software, custodial or not, is only as secure as the randomness that generated its keys. The signature scheme, the derivation path, the address format, all of it assumes the private key came from somewhere unpredictable.

Break that assumption and nothing above it matters. You can have flawless elliptic curve math and airtight storage, and it won't help if the seed came from a 40-bit pool instead of a 256-bit one. What makes Coldcard unsettling is how ordinary the mistake looks in hindsight: code assumed it was reading from hardware when it wasn't, and that one wrong assumption downgraded five years of "secure" wallets with no alarm.

So when we build anything that generates a wallet, whether that's one seed or a set of MPC shares, the randomness source is the first thing we check, not a detail for later. Every bit of entropy behind a key comes from a proper CSPRNG, sourced from the operating system. No homemade generators, no faster substitutes, nothing that can silently degrade the way Coldcard's did.

This keeps happening, and it's always the same mistake

Coldcard isn't an outlier - it's the latest in a line of incidents that trace back to the same root cause: real cryptographic randomness got swapped for something weaker, and nobody caught it until funds moved.

• Android's Java SecureRandom bug (2013). A flawed SecureRandom implementation repeated the same "random" number across signatures. Since ECDSA breaks if a nonce is ever reused, this exposed keys across Bitcoin Wallet, blockchain.info, Bitcoin Spinner, and Mycelium. (The Hacker News)
• Profanity / the Wintermute hack (2022). This Ethereum vanity address generator seeded key generation with 32 bits of entropy instead of 256. An attacker brute-forced a Profanity-generated Wintermute address and drained $160M; researchers later reproduced the attack on a laptop in under 48 hours. (Halborn)
• Trust Wallet browser extension (2023, CVE-2023-31290). Wallets were generated from a PRNG with a 31-bit initial state, seeded from a guessable timestamp. Ledger's Donjon team showed an attacker could compute a private key straight from a public address, no user interaction needed. (Ledger Donjon)
• Milk Sad / Libbitcoin Explorer (2023, CVE-2023-39910). bx seed used a Mersenne Twister seeded by system time, collapsing 256 bits of expected entropy to about 32. Over 120,000 wallets were exposed, with $900K+ confirmed stolen. (Milk Sad disclosure)

Different chains, different tools, different years, same failure: someone assumed a randomness source was strong, it wasn't, and the gap sat invisible until an attacker went looking. Entropy bugs don't discriminate by form factor.

How this plays out across Hyper Wallet and Mpcium

We run two wallet systems: Hyper Wallet, our standard HD custody system, and Mpcium, our MPC-based threshold wallet engine. Different architectures, same rule underneath - any randomness feeding a private key comes from the operating system's CSPRNG at full 256-bit strength, no compromises.

Hyper Wallet generates one fresh seed per workspace, per coin type, from the OS CSPRNG at full strength. Every individual wallet after that is derived from that seed as a distinct child key, the same hierarchical-deterministic model behind BIP-32 - so a workspace needs one strong root, not fresh randomness per wallet. Nothing about that root seed comes from a predictable source like a timestamp or user ID, and there's no fallback path that could quietly downgrade it. Once a seed exists it's the most sensitive thing in the system: encrypted before storage, held in protected memory only as long as needed, and wiped immediately after. This is the same class of system Coldcard's bug hit, so we hold it to the standard that bug proved matters - verify the randomness source, don't just trust the label.

Mpcium works differently. There's no single seed and no point where the full private key exists in one place. Each party in the signing group generates its own key share independently from its own local CSPRNG, and those shares combine through a threshold protocol with no trusted dealer - nobody ever holds or reconstructs the complete key. Signing works the same way: a threshold of parties cooperate without ever assembling the full key in memory.

That structure changes what a randomness failure means. On a single-seed device, one bad RNG is a total loss for every wallet it generated, exactly what happened here. In Mpcium, an attacker would need to compromise multiple independent parties' randomness at once; one party's weak randomness alone reveals nothing, because the key never lived in one place.

Comparing the two side by side

Both start from the same floor: every root of entropy, whether an HD seed or a party's key share, is full-strength and OS-sourced. Mpcium adds a second layer on top: since the key never exists in one place, a single point of randomness failure isn't enough to break it.

If you're building anything that touches private keys, a trading bot, a payment gateway, a custody backend, this is the layer to check first. Ask any vendor, us included, where their randomness comes from and whether that's verified in code, not assumed from documentation.

Mpcium is open source, so you don't have to take our word for it. Read the key-generation code, run it yourself, and have a self-hosted MPC wallet cluster running in about 10 minutes.

Where we land on this

We don't treat randomness as something you verify once and file away - it's an ongoing check, the same as key storage or access control. Every entropy source feeding Hyper Wallet or Mpcium comes from the operating system's CSPRNG, with no custom generators, no predictable inputs, and no quiet fallback paths like the one that turned Coldcard's hardware RNG into a software PRNG for half a decade unnoticed. We'd rather a customer ask us this directly than assume it's handled, because "assumed instead of verified" is exactly how Coldcard's bug lasted as long as it did.

Frequently asked questions