Coldcard Wallet Entropy Flaw and Nearly $90 Million in Losses: A Stark Warning from “Absolutely Secure” Hardware

On July 30, a highly unusual series of transfers appeared on the Bitcoin blockchain.

The first sweep to attract attention lasted just 41 minutes. During that window, 1,082.65 BTC was moved from 1,196 addresses. Galaxy Research later identified two more rounds of apparently related activity. By August 2, the three rounds totaled about 1,367.05 BTC, worth close to $88.6 million at the time, across 4,585 addresses.

These figures can be cross-checked against public updates from Galaxy Research, CoinDesk’s on-chain tracking, and the technical reporting published by The Hacker News.

The wallets shared one important feature: their seeds were believed to have been generated by Coinkite’s Coldcard hardware wallets.

Many of the affected devices had been offline for years, and their recovery phrases had never been uploaded to the cloud. The problem occurred much earlier. When those wallets were created, the devices did not use the hardware true random number generator as intended. An attacker did not need to steal the recovery phrase. They only needed to calculate the set of phrases that could have been generated, then search the blockchain for the corresponding addresses.

This is one of the hardest classes of failure for a hardware wallet to defend against. A device can remain locked in a drawer, and the private key may genuinely never leave it. But if the private key was not random enough when it was created, later protections such as air-gapping, secure elements, and tamper-resistant hardware cannot compensate for that weakness.

Evidence and limits of the conclusions

Primary verification sources: COLDCARD Mk3 Seed Generation Warning; Version History; BIP-0039: Mnemonic code for generating deterministic keys.

The verifiable claims in this article regarding COLDCARD’s low-entropy flaw, affected firmware, and safe migration are based on the official or regulatory materials cited above. Actual service availability, fees, eligibility requirements, and geographic coverage should be confirmed on the issuer’s or platform’s current application pages.

Asset migration must be performed on a trusted device, with destination addresses verified directly. Any reported loss figure should distinguish between official confirmation and third-party analysis. User experience, success rates, fee comparisons, and trend judgments not directly disclosed in the primary sources above are analytical assessments or inferences and have not been officially confirmed for individual cases by the relevant organizations.

What has been confirmed so far

Coldcard developer Coinkite has acknowledged that some firmware released between 2021 and July 2026 contained a low-entropy flaw. The company instructed affected users to generate new seeds and move their funds to new addresses. The fixed versions listed in the Coinkite security advisory include Mk2/Mk3 4.2.0, Mk4/Mk5 standard firmware 5.6.0, Q standard firmware 1.5.0Q, and Edge-branch versions 6.6.0X and 6.6.0QX.

Block’s Bitcoin engineering and security team conducted an independent analysis as well. Its technical report traced the problem to the random-number call chain. When creating a wallet seed, the firmware was supposed to call the STM32 chip’s hardware random number generator. Instead, execution reached Yasmarang, a software pseudorandom number generator built into MicroPython.

Both the firmware flaw and the on-chain sweeps are real, but the attribution between them is not fully closed. Galaxy identified related transactions using fee patterns, change behavior, batch-transfer structure, and derivation paths. No public report has yet demonstrated the complete process of reconstructing a specific victim’s weak seed and matching it one-to-one with an emptied address.

A more precise formulation is therefore this: researchers found a Coldcard firmware flaw capable of reducing private-key generation to a space small enough for offline enumeration, while multiple highly suspicious fund sweeps were observed at roughly the same time and with strongly matching characteristics. Writing that all 1,367.05 BTC was “confirmed stolen through this flaw” goes beyond what the evidence currently establishes.

The bug was hidden in the random-number call chain

Coldcard originally had code that directly read from the STM32 hardware RNG. The corresponding Python interface was ckcc.rng_bytes().

In 2021, while migrating elliptic-curve-related code and introducing libNgU, Coldcard changed the random-number interface used for new wallets to ngu.random.bytes(). That is where the flaw entered the firmware.

In the production configuration, MICROPY_HW_ENABLE_RNG was defined as 0. The developers did this because Coldcard already had its own wrapper for the hardware RNG, so there was no need for MicroPython to provide another implementation. The libNgU check, however, used #ifndef. It only checked whether the macro had been defined, not whether its value was nonzero.

The code compiled, and the device booted normally. But at final link time, rng_get() did not resolve to Coldcard’s intended hardware implementation. Instead, it was bound to MicroPython’s Yasmarang fallback routine. The relevant source code and commit history are visible in the Coldcard firmware repository, while Block’s report reconstructs the call path in detail.

Yasmarang produces values that may look random, but it is not a cryptographically secure random number generator designed for wallet master keys. Its initial state is derived mainly from the lower 32 bits of the chip UID, the SysTick timer, and the RTC time registers.

The chip UID is only a device identifier, not a secret. Timer state is not the same thing as physical noise, and these inputs may also be correlated. Once initialized, the generator does not keep absorbing fresh randomness. If an attacker can narrow the device state, startup time, and number of prior calls to a manageable range, later outputs can be reproduced on another computer.

The firmware later hashes the generated result, but hashing does not solve the problem. Ten thousand possible inputs remain only ten thousand possible outputs after SHA-256. The distribution may look more uniform, but the search space has not become larger. The BIP-39 checksum only verifies format; it does not add real entropy to the recovery phrase.

40 bits versus 72 bits: how large is the difference?

The BIP-39 specification requires initial entropy of between 128 and 256 bits. A typical 12-word recovery phrase corresponds to 128 bits, while a 24-word phrase corresponds to 256 bits.

Coinkite’s preliminary estimate for the affected firmware was that Mk2/Mk3 seed generation had an effective search space of about 40 bits, while Mk4/Mk5/Q had about 72 bits.

A 40-bit space contains roughly 1.1 trillion candidates. That still sounds large, but it is nowhere near the same scale as 128 bits. The candidate spaces differ by roughly 2^88. Once an attacker can further narrow the range using the device model, chip UID, boot timing, or common derivation paths, offline enumeration stops being merely a theoretical concern.

Later models included an additional step. At startup, Mk4 mixes in random data from a secure element, but after hashing the result, the code keeps only 4 bytes and uses those 32 bits to replace one state word in Yasmarang. Block therefore concluded that, if the other state values and call history are known, the secure element can distinguish at most 2^32 output streams. Even when unknown timer state is counted using a generous upper bound, the candidate space remains below 2^73.3.

It would be misleading to reduce that conclusion to “Mk4 has 72-bit security.” Block itself cautions that 2^73.3 is a loose upper bound on candidate space, not 73 bits of cryptographic security in the conventional sense. Real-world cracking cost depends on UID information, boot timing, prior call count, address derivation, and verification speed. No complete public cracking benchmark is currently available.

What can be said with confidence is that the later models are in a better position than Mk2/Mk3, but they still failed to reach Coldcard’s intended 128-bit target. That is why Coinkite also requires those users to replace their seeds.

The seed is affected, not just the device

The easiest mistake during remediation is to look only at the firmware currently installed on the device.

What determines the risk is the firmware version that generated the recovery phrase in the first place. Upgrading a Mk3 to 4.2.0 today does not retroactively add randomness to a phrase generated five years ago. Importing the same phrase into a Ledger, Trezor, or software wallet does not help either. The weakness is already embedded in the seed itself.

There is another versioning detail worth noting. Standard and Edge firmware are separate release branches. An older Edge version cannot be assumed safe simply because its version number is higher than 5.6.0. The exact scope should be checked against Coinkite’s latest notice and the official version history.

Coinkite says that TAPSIGNER, OPENDIME, and SATSCARD use different codebases and are not affected by this flaw.

If the wallet was offline, how could an attacker move the coins?

A hardware wallet stores private keys and signs transactions. If the randomness is sound, remotely obtaining the private key is indeed very difficult.

This attack path bypassed the device itself. An attacker could enumerate possible random states on their own computer, generate candidate recovery phrases, derive the corresponding extended public keys and commonly used addresses, and then check the public Bitcoin blockchain to see whether those addresses held funds.

Once a match is found, the private key calculated by the attacker is identical to the one in the wallet. The attacker can sign and broadcast a transaction independently, without connecting to the original device and without knowing the device PIN. The claim that a device “was never online” does not rule out this attack, because the candidate-key search can be performed entirely offline.

Long-dormant coins are not safe simply because they have not moved. The risk of a weak seed does not expire on its own. As research becomes public and computing costs decline, a search that was previously uneconomical may become profitable. Dormant addresses with larger balances may in fact become more attractive targets.

How should the 4,585 on-chain addresses be interpreted?

Galaxy Research’s main figures as of August 2 were:

The first two rounds used similar fixed fee patterns and batching behavior. They may have come from the same operator, or they may simply have used the same tooling. The third round changed the consolidation addresses and output structure. Galaxy did not attribute all three rounds to one attacker because the on-chain evidence is insufficient to support that conclusion.

Address count cannot be converted directly into victim count either. One person may control many addresses, and one recovery phrase can derive a large number of receiving addresses. Conversely, if researchers scanned only standard derivation paths, they may have missed additional funds belonging to the same wallet.

On-chain attribution also has a fundamental limitation: when a wallet owner voluntarily migrates funds, the transaction pattern may resemble an attacker sweep. Galaxy’s model relies on transaction fingerprints, derivation paths, and victim reports. It does not read a “theft” label directly from the blockchain. For that reason, 1,367.05 BTC is better described as the scale of “observed, apparently related activity.”

The code was public for five years. Why did nobody catch it?

Coldcard firmware was open-source throughout this period, and the hardware-randomness implementation was indeed present. Earlier reviews could see the TRNG code, but they did not verify whether the wallet-creation path actually resolved to that implementation.

The bug crossed several layers. The wallet-generation function changed interfaces, libNgU’s compile-time macro check was incomplete, and MicroPython provided a software fallback with the same functional role. None of these pieces looked especially alarming in isolation. The software compiled normally, the device worked normally, and the output did not simply repeat. The problem becomes visible only when symbol resolution and the final call path are traced through the actual build.

Ordinary randomness tests may not have exposed it either. A non-cryptographic PRNG can still produce uniformly distributed values with no obvious repetition between adjacent samples. The problem is not that the output “looks nonrandom.” The problem is that the internal state can be inferred.

Coinkite’s hotfix added a build-time RNG symbol check. If the wrong implementation enters the firmware again, the build will fail. The company’s technical postmortem also acknowledged that earlier checks confirmed the expected TRNG existed, but did not verify which implementation the wallet-generation path ultimately resolved to.

Open source still mattered. The reason the issue could be located and historical commits reviewed so quickly was precisely because the code was public. But “anyone can audit it” is not the same as “someone has already audited every security-critical path.” For hardware wallets, reproducible builds are only a starting point. Seed generation, signing, and backup call chains also need end-to-end verification.

Multisig can reduce risk, but only if the keys were generated independently

In a 2-of-3 multisig setup, recovering one weak private key is not enough to move funds. The attacker still needs a second signing key. If the remaining keys were generated by different vendors, different codebases, and independent randomness sources, multisig can protect against a systemic defect in one hardware-wallet vendor.

But combining three affected Coldcards into a multisig setup does not automatically fix the problem. If the attacker can recover enough weak keys to satisfy the signing threshold, the funds can still be moved. Block’s report states this directly: the multisig threshold must contain a sufficient number of secure devices.

For ordinary users, more complicated multisig is not automatically better. Missing descriptors, derivation paths, device fingerprints, or backups can make recovery fail. If the user has never performed a full recovery drill and merely followed a tutorial to combine several devices, the operational risk may be no lower than with single-signature custody.

How to migrate now

If your seed was generated under one of the firmware versions listed above, and you did not add enough independent dice entropy at the time or use a strong, unique BIP-39 passphrase, you should treat it as an at-risk legacy seed.

First, obtain the fixed firmware for your exact model and release branch from Coldcard’s official download page, and confirm the version on the device screen. Then generate a completely new recovery phrase and carefully record and verify the backup, wallet fingerprint, and receiving address.

Do not move the entire balance immediately. Send a small test transaction first, confirm receipt in the new wallet, verify the fingerprint and address again, and only then move the remaining funds. Keep the old backup until the full balance has arrived. After migration is complete, stop using the old addresses to receive funds.

Coinkite provides one exception for dice entropy. If, when creating the seed, you used Coldcard’s “Add Dice Rolls” function and entered at least 50 fair, independent, fully private six-sided dice rolls, the dice themselves contributed at least 128 bits of entropy; 99 or more rolls provide roughly 256 bits. If you cannot remember how many rolls were used, or if the results were photographed or recorded on a network-connected device, do not rely on this exception.

A BIP-39 passphrase can also add an independent secret, but short words, quotations, common variations, and reused passwords may still be guessed. The device PIN is not a BIP-39 passphrase. Even if the passphrase is strong, Coinkite still recommends replacing the seed because the underlying recovery phrase itself has not been repaired.

During migration, be especially wary of fake advisories, fake support representatives, and websites offering “seed security checks.” Anyone asking you to enter a recovery phrase into a website, chat window, or remote-support application should be treated as untrustworthy.

What this incident teaches

Coldcard’s air-gapped design, reproducible builds, and physical protections still have value. They simply cannot protect a private key that was weak at the moment of generation. A hardware wallet is not a single safe. It is an entire process: random-number generation, firmware build, private-key storage, signing, backup, and recovery. A failure in any one of those stages can compromise the whole system.

Users cannot realistically audit every line of a hardware wallet’s code, but they can reduce single points of failure. Large balances should not remain indefinitely tied to one vendor and one seed-generation method. Record which device generated each seed, along with firmware version and date. Review vendor security advisories periodically. And when a vulnerability affects the seed itself, do not assume that a firmware update finishes the job.

The key is what needs to be replaced this time. As long as the old seed still controls funds, the risk remains.

References

Official company and firmware sources

• Coldcard official website

• Coinkite official website

• Coldcard / Coinkite official security advisory

• Coinkite official technical postmortem

• Coldcard official firmware source and security notices

• Coldcard official firmware version history

• Coldcard official firmware download page

Independent technical and standards sources

• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

• Bitcoin BIPs: BIP-39 mnemonic specification

• Coldcard 2021 commit introducing libNgU

On-chain tracking and news verification

• Galaxy Research: third-round tracking and three-round totals

• CoinDesk: three rounds expanded to 4,585 addresses and roughly 1,367 BTC

• The Hacker News: vulnerability path, affected versions, and Galaxy data update