Wallet entropy: what the Coldcard incident teaches about randomness

At 01:31 UTC on July 31, 2026, bitcoin began leaving wallets whose owners had done nothing at all. By 01:56 — twenty-five minutes later — roughly 594 BTC, about $38 million, had been swept from around 500 single-signature wallets. Later analysis from Galaxy Research and Chainalysis coverage linked up to roughly 1,083 BTC across some 1,196 addresses. Nobody was phished. Nobody installed malware. Nobody approved a transaction. The one trait the victims shared was the date their wallet was created — because what failed was wallet entropy: the randomness a seed phrase is made from, fixed in the first second of a wallet’s life.

The wallets had been generated on Coldcard hardware devices, and the flaw behind them had been sitting in shipped firmware for more than five years. This article covers what happened, why this bug class stays invisible, what it does and does not say about hardware wallets — and what to ask about any wallet’s randomness, including ours.

A 2021 flaw, cashed out in 2026

According to Coinkite’s security advisory, a firmware bug weakened seed generation on Coldcard Mk2 and Mk3 firmware 4.0.1 through 4.1.9 — a range that began with 4.0.1 in March 2021 — and on Mk4, Mk5 and Q devices running releases older than the fixed versions. Coldcard’s security status page describes the remediation as removing a software fallback in the random-number path. A BIP39 seed phrase is supposed to encode 128 bits of entropy — 2¹²⁸ possible seeds, a space no attacker can search. The advisory puts affected Mk4, Mk5 and Q seeds at about 72 bits and says the older Mk2/Mk3 impact was more severe; it gives no bit figure for those models, so the roughly 40 bits this article uses for affected Mk3 seeds is an estimate, not a number from the advisory. 2⁴⁰ is about 1.1 trillion candidates — enormous to a human, entirely searchable to a machine. That is the Coldcard vulnerability explained in one sentence: seed generation quietly lost most of its randomness, and nothing visible gave it away.

Two groups were far less exposed. A strong, unique BIP39 passphrase adds an independent barrier: the advisory says the reduced seed entropy alone is not enough to reach a passphrase wallet. But a short, common, patterned or reused passphrase may be guessable, and no passphrase repairs the weak seed underneath, so Coinkite advises passphrase users to migrate as soon as practical too. Seeds created with at least 50 fair, independent, private dice rolls are not at risk from this issue alone; with fewer rolls or uncertain records, the vendor says to migrate. Coinkite disclosed the issue and shipped corrected firmware — 4.2.0 for the Mk2 and Mk3; on the standard track 5.6.0 for the Mk4 and Mk5 and 1.5.0Q for the Q; on the Edge track 6.6.0X and 6.6.0QX. In the five years between, affected wallets worked flawlessly and looked identical to safe ones. Whoever ran the sweep never needed to touch a victim: enumerate the weak keyspace, derive addresses, match them against the chain, move everything in one 25-minute window.

Silent entropy degradation: why the seeds looked random

The unsettling part is that nothing about the affected seeds ever looked wrong. A seed built from 40 bits of predictable input still comes out as twelve perfectly ordinary BIP39 words with a valid checksum. The wallet accepts it, derives addresses, signs transactions; every screen shows exactly what a strong wallet would show.

Statistical testing cannot help either: a deterministic generator seeded with predictable data still produces output that passes randomness tests — the bits are well distributed, just drawn from a catastrophically small set of possible sequences. The weakness lives in a property no output can reveal: how many other seeds could have been generated instead. Only the generation code carries that answer.

A weak seed does not look weak. The difference between 2¹²⁸ and 2⁴⁰ exists only in the code that made the words.

That is why this bug class persists for years, and why the Coldcard incident belongs to a family. Milk Sad in Libbitcoin’s bx tool, the Trust Wallet browser extension’s MT19937 generator, Cake Wallet, the Profanity vanity-address tool, and Randstorm in early browser wallets all share one shape: a CSPRNG silently replaced by a predictable source — no error, no warning, no visible difference, until someone enumerates the keyspace.

The uncomfortable lesson

“Hardware wallet” names a form factor, not a guarantee. The wallets swept on July 31 were created on purpose-built signing hardware — and that was not the layer that failed. What decided survival was a property fixed years earlier: how the seed was generated on the day the wallet was created. Everything downstream — cold storage, air-gapped signing, careful verification — protects a key from being stolen. None of it helps if the key can be regenerated.

It matters equally that Coinkite disclosed the flaw and shipped fixed firmware promptly. This is not a story about a careless vendor; it is a failure mode the industry keeps rediscovering, in hardware and software alike. Any wallet — ours included — is one silent fallback away from the same class of bug. The honest question is not “which vendor is immune?” but “how would this wallet fail, and would anyone notice?”

Five questions to ask about any wallet’s randomness

You do not need to be a cryptographer to raise the bar. Five questions sort wallets meaningfully:

1. What is the entropy source? A seed should come from a CSPRNG, not from timestamps, device identifiers, or anything an outsider could reconstruct.
2. What happens if that source fails? The acceptable answer is a hard error that stops wallet creation. The unacceptable one is a quiet substitute — silent fallback is the defining trait of this bug class.
3. Is the generation path open source and verifiable? Weak entropy is invisible in outputs, so code review is the only place it can be caught.
4. Does the wallet support a BIP39 passphrase? A passphrase adds secret material the device’s generator never touched. On affected Coldcards, a strong, unique passphrase meant the weakened seed alone was not enough to reach the funds — but a weak or reused passphrase may be guessable, and no passphrase repairs a weak seed.
5. In a multisig, are keys generated on independent devices? Independent devices mean independent randomness: one flawed generator compromises one key, not the quorum.

How Ownbit generates entropy

Questions like these deserve concrete answers about our own product. Ownbit’s mnemonic generation has two layers. At the app layer, generateMnemonicRandom(entropy, langIndex) calls generateMnemonic from the standard bip39 library — 128 bits of entropy by default, with eight BIP39 wordlists supported: English, Simplified and Traditional Chinese, Japanese, French, Italian, Korean, and Spanish. At the library layer, bip39’s randomBytes draws from crypto.getRandomValues — the platform CSPRNG.

What matters here is what happens when that source is unavailable: the library throws an error. It does not consult a clock, a chip identifier, or any secondary source — there is no fallback path in the code. The failure mode is a loud error at creation time, never a silently weaker seed. That property — fail loudly, never fall back — is the exact inverse of the flaw behind the Coldcard incident, Milk Sad, and Randstorm, where generation quietly carried on from a predictable source.

We will not claim this makes Ownbit immune to bugs; no honest vendor can. What it removes, by construction, is this failure shape: no code path exists on which an Ownbit wallet quietly generates a weak seed. The rest of the model is laid out on our security page.

Why independently generated keys survive this bug class

The July 31 sweep hit single-signature wallets: one seed, one signature, funds gone — the textbook case of a seed phrase as a single point of failure. Multisig changes the arithmetic. In an Ownbit MultiSig wallet, every key is its own standard BIP39 seed phrase, generated on that participant’s own device. Suppose one device carried exactly this class of flaw. In a 2-of-3 wallet, an attacker who enumerates the weak keyspace holds one key — below the threshold. Nothing moves. A weak key becomes a maintenance task — rotate it — instead of a loss.

The protection comes from independence, not from the word “multisig.” Three cosigner keys generated on the same flawed device model would fail together. Three keys born on genuinely different devices — your daily phone, a spare phone kept offline as a QR-signing cold wallet, a family member’s device — do not depend on one device’s generator, so one faulty generator weakens one key, not all three. That independence is not absolute: devices running the same wallet software or library can still share a failure mode, which is why the generation code matters as much as the hardware. The same logic explains why a strong, unique BIP39 passphrase shielded affected Coldcard users: the passphrase is secret material the device RNG never produced, so enumerating the weakened seeds alone was not enough to spend. That shield is only as strong as the passphrase, and the seed underneath stays weak — which is why the vendor still advises migrating.

If you own an affected Coldcard

Three actions. Coinkite’s advisory remains the authoritative source and is updated as its investigation continues:

1. Update the firmware — and check your model and release track. The minimum fixed releases named in Coinkite’s advisory are 4.2.0 for the Mk2 and Mk3 (the final release for those models), 5.6.0 for the Mk4 and Mk5 and 1.5.0Q for the Q on the standard track, and 6.6.0X and 6.6.0QX on the Edge track. These are minimums, not necessarily the current recommended releases; the COLDCARD security status page keeps the current matrix. Do not generate a new seed on an affected model until the update is installed.
2. Move funds to a new seed generated on fixed firmware. Updating protects future seeds; it cannot strengthen an existing one. A seed born with roughly 40 bits stays enumerable forever — retire it completely, never re-use it, never send funds back to its addresses. This applies to passphrase wallets too: Coinkite advises passphrase users to migrate as soon as practical. Follow the official migration guide without rushing — verify the new backup and a receive address, send a small test transaction, then move the rest, and keep the old backup until the migration is confirmed.
3. Never type an existing seed phrase into any website offering to “check” whether it is vulnerable. Entering a seed into anything online is how remaining funds get taken; “checker” sites are a standing phishing pattern after incidents like this.

Frequently asked questions