Skip to content
Opublikowano August 27, 2026 · autor: Coinator Team

When randomness is not random: what the Coldcard incident means for investigators

From 30 July 2026, more than 7,000 Bitcoin addresses belonging to Coldcard users were drained in a few waves, with losses above 130 million US dollars. The cause was not a hack but a random number generator that had not produced real randomness since 2021. An analysis from a forensic perspective.

#coldcard #hardware-wallet #entropy #theft #case-study

Hardware wallets are considered the gold standard of self-custody: the private key never leaves the device, and malware on the PC cannot reach it. The incident involving Coinkite's Coldcard shows that this security rests on a silent assumption: the key has to have been generated randomly in the first place.

What happened

On 30 July 2026 attackers began draining addresses belonging to Coldcard users. In the first wave alone, around 1,200 addresses were emptied within 41 minutes. Further waves followed over the next days. Depending on the analysis, the losses add up to 1,600 to just over 2,000 BTC from more than 7,000 addresses, worth more than 130 million US dollars at the time. It is the largest known loss from a hardware wallet vulnerability.

Block's Bitcoin engineering team identified the cause the same day and, once active exploitation was confirmed, published a technical analysis.

The cause: a macro that was checked, but not read

The Coldcard has a hardware random number generator (TRNG) in its STM32 microcontroller. With firmware version 4.0.0 in March 2021 the cryptographic library was restructured. The code checked whether the macro for the hardware RNG was defined, but not whether it was enabled. The macro was set to zero. The call therefore silently fell back to MicroPython's software pseudo-random generator.

That generator was initialised from three values that have nothing to do with randomness: the lower 32 bits of the device ID, a millisecond counter of the processor and the time from the real-time clock. All three are fixed or time-derived and correlated with each other.

The result for the Mk2 and Mk3 models on firmware 4.0.0 to 4.1.9: instead of 128 bits of entropy, a seed had only 16 to just under 41 bits depending on the assumptions. A trillion combinations sounds like a lot, but at a million checks per second it is exhausted in under two weeks. The newer Mk4, Q and Mk5 models were affected through a second flaw: when reseeding from the secure element, only four bytes reached the generator, so at most 2^32 distinct seeds could result.

The attacker therefore needed no access to any device. He generated all possible seeds offline, derived the addresses and matched them against the blockchain. Wherever there was a balance, he knew the key.

Coinkite has released firmware updates that require human-supplied entropy for every seed generation, such as 65 key presses at irregular intervals, 50 dice rolls or 128 coin flips. Users of affected versions should move their funds to a freshly generated seed.

What investigators can take from this

First: "hardware wallet" says nothing about the quality of the key. In investigations we regularly encounter the argument that a loss cannot be theft because the coins were on a hardware wallet. The Coldcard case refutes that. Conversely, anyone claiming to be a victim of such an attack has to show plausibly that their seed came from an affected firmware.

Second: mass sweeps leave a characteristic pattern. Thousands of addresses that have not moved for years are emptied within minutes and consolidated into a few collection addresses. For the co-spend heuristic this is a gift: every consolidation transaction links dozens of victim addresses into a cluster that unambiguously belongs to the attacker. The victim addresses themselves remain cleanly separated from that cluster, because they never spent together with foreign addresses. In Coinator the attacker side can thus be fully delineated without victim balances being wrongly attributed to the attacker.

Third: dormant addresses that suddenly wake up are a warning sign. The attacker's collection addresses are unambiguously identifiable on-chain. We maintain them in Coinator as a dedicated entity with the finding "proceeds of theft", so that inflows from these addresses to exchange accounts stand out immediately. For exchanges and banks this means: deposits that trace back to these clusters should be held until clarified.

The uncomfortable lesson

The bug sat in open-source firmware for five years. It took no zero-day and no supply-chain manipulation, just a wrongly checked compiler switch. For forensics this means: the origin of a key is a matter of evidence, not only the origin of the coins. How Coinator keeps consolidation clusters and victim addresses apart is explained in our methodology overview.

This post is currently only available in the language shown above.