The keys stayed offline, but the secret was guessable
Research cut-off: August 25, 2026. Coinkite's formal technical postmortem remains in progress, so this report separates confirmed losses, published code analysis, and vendor guidance from estimates that may still change.
The recent Coldcard theft did not involve remote access to the hardware wallets. Attackers worked without the devices, their PINs, or malware on the owners' computers. The vulnerable wallets had been created with seeds drawn from a much smaller set of possibilities than their owners were promised. Attackers could search that set offline, derive the corresponding Bitcoin addresses, compare them with the public blockchain, and spend any matching coins.
Beginning on July 30, attackers swept funds from thousands of addresses. By August 14, Galaxy Research had confirmed with high confidence that 1,778.84 BTC, worth about $112.7 million at the time, had been stolen from more than 8,600 addresses. Galaxy had spoken directly with 190 victims and identified several attack patterns. It also found evidence that more than one attacker was active.
Those 8,600 addresses are not 8,600 stolen devices. One deterministic wallet can control many addresses. That distinction matters because the event exposed a failure in seed creation, not a breach of the device's offline storage after setup.
Galaxy found no confirmed attacker activity after August 6, but it did not declare the remaining wallets safe. Its plausible explanations included successful user migration and the possibility that attackers had already taken much of the accessible balance. Any funds left on an affected seed remain exposed.
A build error weakened five years of seeds
Coldcard intended to generate wallet seeds from a hardware true random number generator. During a March 2021 migration to a supporting library, the seed-generation path began resolving to MicroPython's general-purpose Yasmarang pseudorandom generator instead.
The failure sat at a build and linking boundary. A configuration macro set the hardware RNG option to zero. A library guard used #ifndef, which checked whether that macro existed rather than whether it was enabled. The build succeeded, but the global rng_get() symbol used by seed generation resolved to the deterministic software implementation. Coinkite's hardware RNG code was present in the binary, yet the relevant call path did not reach it.
The fallback was initialized from device identity and timing state. Those values can vary, but variation is not the same as cryptographic unpredictability. Hashing the resulting bytes could make them look uniformly random. It could not increase the number of possible seeds.
Coinkite estimated an effective search space of about 40 bits for affected Mk3 seeds under its attack assumptions. It said later devices mixed in secure-element entropy and estimated about 72 bits. A coordinated Block engineering analysis reached a harsher result: no cryptographic entropy entered the Mk2 and Mk3 v4 path, while only one 32-bit state word distinguished later-device streams once the fallback state and call history were fixed.
The two estimates rest on different assumptions about what an attacker knows. They should not be merged into one number. Attackers still recovered real wallets at scale.
The firmware was open source and reproducible builds were available, yet the bug remained. Existing review had checked that the intended RNG implementation was present, but not which implementation the shipped seed-generation path actually called. For security-critical randomness, source review must be paired with tests of the final binary, symbol resolution, call reachability, and fail-closed behavior.
The risk depends on the seed's origin
The relevant version is the firmware that generated the seed, not the firmware installed today. Moving the same seed to another hardware wallet also leaves it weak. Conversely, a seed generated by a sound external process and later imported into an affected Coldcard does not inherit this particular generation defect, although its security still depends on that original process.
The current Coldcard security matrix, verified by the vendor on August 17, lists these minimum fixed releases:
| Model and track | Seed generated on affected firmware | Minimum fixed release |
|---|---|---|
| Mk2 or Mk3 | 4.0.1 through 4.1.9 | 4.2.0 or later |
| Mk4 or Mk5 standard | Before 5.6.0 | 5.6.0 or later |
| Mk4 or Mk5 Edge | Before 6.6.0X | 6.6.0X or later |
| Q standard | Before 1.5.0Q | 1.5.0Q or later |
| Q Edge | Before 6.6.0QX | 6.6.0QX or later |
Coldcard currently recommends standard release 5.6.1 for Mk4 and Mk5, and 1.5.1Q for Q. Standard and Edge are separate tracks, so their version numbers cannot be compared directly.
Coinkite says an affected seed is outside this RNG incident if its creation included at least 50 fair, independent, private six-sided-die rolls whose sequence was never recorded or exposed. Fifty rolls contribute slightly more than 128 bits of entropy. Fewer rolls, biased rolls, reused rolls, a recorded sequence, or uncertainty about the process should be treated as insufficient.
A strong, unique BIP-39 passphrase can slow or prevent use of a recovered mnemonic, but it does not repair the underlying seed. The BIP-39 specification also creates a subtle recovery risk: every passphrase, including a typo, produces a valid but different wallet. Owners who cannot prove that the passphrase is strong, exact, separately backed up, and recoverable should not use it as a reason to delay migration.
If the device, generation version, or dice history is unknown, the safer assumption is that the seed needs replacement.
Migration is the fix, not a firmware update
Updating firmware changes future seed generation. It cannot add entropy to a seed that already exists. Only a completely new seed followed by an on-chain transfer removes the exposure.
The vendor's migration procedure is careful because hurried recovery work can create a second loss. A two-device process is easier to verify when another known-good or freshly initialized signer is available:
- Install the applicable fixed firmware from the official source and verify its signed release information.
- Generate a completely new seed on the patched or otherwise unaffected device. Do not clone, import, or restore the old seed.
- Record the new backup and wallet fingerprint. Power-cycle the device, confirm the fingerprint again, and verify a receiving address on the hardware screen.
- Send a small test transaction from the affected wallet. Confirm that it arrived in the expected new wallet before moving the remaining balance.
- Reconcile every funded account, then keep the old backup only until the migration is complete and confirmed.
Migration must cover more than the base wallet. Every funded passphrase wallet must move. If the affected seed is a BIP-85 parent, every funded child needs attention. In multisig, replace the affected cosigner through a new verified policy and transfer to that policy. Reusing the same passphrase or child index with a new seed produces a different wallet.
During an urgent migration, adding an untested passphrase or building a first multisig setup can increase operational risk. Move first through a process you can verify. No legitimate support agent needs seed words, a passphrase, dice rolls, an XPRV, or a private-key QR code.
Hardware wallets fail in more than one way
Coldcard failed during seed generation. Other hardware-wallet losses can begin later, after a sound seed already exists. Each failure point needs a different control.
Weak seed generation happens before cold storage can help. Defenses include fixed firmware, verified release files, documented user-supplied entropy, independent testing, and, for holdings that justify the complexity, multisig seeds generated on genuinely separate devices and implementations.
Seed-backup theft bypasses the device entirely. A photo, cloud copy, email, ordinary computer file, or seed entered into a website can give an attacker everything needed to spend. Backups should remain offline, and the seed, device, and any passphrase should not be stored together.
Host malware can change a recipient address or transaction while leaving the private key inside the hardware wallet. The defense is to verify the amount, destination, fee, and policy on the trusted hardware display before signing. Air-gapped transfer does not help if the user approves a malicious transaction without reading it.
Physical theft gives an attacker time with the device. A strong PIN and a separately stored passphrase can buy protection, but they are not a reason to wait indefinitely. If a signer disappears or shows evidence of tampering, create a fresh wallet through a known process and move the funds. If the seed backup is missing too, treat the event as an immediate key compromise.
Supply-chain tampering begins before setup. Buy through a channel you can authenticate, inspect the device and packaging, install verified current firmware, and reject any device that arrives with a prewritten seed or asks you to use recovery words supplied by someone else. A sealed bag can reveal interference, but it cannot prove that the device is genuine or the firmware clean.
How to set up and test a safer wallet
Before depositing an amount you could not easily replace, document where the seed came from, which firmware generated it, and the wallet fingerprint. The record should identify versions and public wallet data, never the seed words or passphrase.
Generate recovery words on the hardware device or through another procedure you have independently verified. Never improvise a mnemonic from favorite words, use an online generator, or assume that a valid BIP-39 checksum proves randomness. If a device supports adding dice or coin flips, follow its documented workflow and keep the actual sequence private.
Write or stamp the seed offline. Store duplicate backups in locations that do not fail together. Keep a passphrase separate and back it up exactly. A passphrase that depends on memory alone often replaces theft risk with permanent loss.
Test recovery before the wallet holds a painful amount. A safe rehearsal confirms the fingerprint and derived receive address on dedicated hardware. It does not require typing the real seed into a laptop or browser. Send a small amount, recover the wallet, and confirm that the same address set returns.
For routine spending, verify every destination on the hardware display. Maintain a watch-only view for balance and unexpected movement, preferably without handing an extended public key to an unknown service. A watch-only wallet cannot spend, but an exposed XPUB can reveal transaction history and future addresses.
Large holdings may justify 2-of-3 multisig across different vendors, with each seed generated independently and backups distributed across separate locations. This can survive one weak seed, one failed device, or one lost backup. It also creates policy-file, inheritance, and recovery obligations. A multisig design that nobody can restore is not safer than a well-run single-signature wallet.
What Coldcard changes for self-custody
Hardware wallets still reduce important risks, especially exposure of private keys to networked computers. Coldcard's failure occurred earlier in the process. Some devices created weak secrets before offline signing began.
Users cannot inspect a 24-word phrase and tell whether it has 40 bits of effective entropy or 256. The words and checksum can look perfectly normal in both cases. That makes seed provenance part of the backup: model, release track, firmware at creation, entropy method, fingerprint, and recovery test all matter.
Vendors need stronger evidence for seed-generation claims than an open repository or a random-looking output sample. The shipped binary should prove which entropy source is reached, stop when that source fails, and test the complete path across library and linker boundaries. Independent review should reproduce those results on real devices.
For owners, adding passphrases, dice, separate signers, and multisig can reduce concentrated technical risk. Every layer also creates more recovery work and another place to make a mistake. The appropriate setup depends on the amount at stake and the owner's ability to rehearse it. If a life-changing balance depends on one device-generated seed and nobody can verify how that seed was created, the wallet needs a new recovery plan.
Sources
Research cut-off: August 25, 2026. The loss figure uses Galaxy Research's high-confidence set and excludes medium-confidence or unconfirmed clusters. Firmware and migration guidance follows Coldcard's status page verified August 17. Coinkite had not yet published its formal postmortem as of its August 15 status update.
- Galaxy Research, Coldcard exploit abates as total losses climb to at least 1,700 BTC
- Coinkite, Technical deep dive into the entropy issue
- Block Engineering, Predictable RNG fallback and 32-bit reseed in Coldcard firmware
- Coldcard, Current security status
- Coldcard, Migrate an affected seed
- Bitcoin Improvement Proposals, BIP 39