Bitcoin's massive theft by entropy failure in Coldcard exposes BIP39 seeds

On July 30, an attacker emptied 1,196 Bitcoin addresses in 41 minutes and took 1,082.65 BTC - approximately $70.2 million according to value at that time - after exploiting a weakness in Coldcard seed generation, the unique Bitcoin-based hardware purse designed by Coinkite. Public research that maps the operation and tracks the technical cause points out that it was not a direct physical attack leak but a firmware integration failure that appeared in March 2021 that, in certain buildings, caused seed generation to be based on a software determinist generator rather than the STM32 chip random number generator.

In concrete terms, the error chain includes a production configuration that disable the MicroPython macro for the RNG, the verification in the libngu library of the mere existence of that macro rather than its effective activation, and the initialization of the pseudorandom with the unique chip identifier and timer records without collecting fresh entropy. The result: 12-word BIP-39 seeds with effective entropies well below the 128 bit expected, estimated by Coinkite around 40 bits in some Mk3 models and about 72 bits in other Mk4 / Mk5 / Q models, which drastically reduces the practical cost of generating seed candidates and checking addresses in the public chain.

It is important to stress that the exposure depends exclusively on the firmware version used when the seed was created, not on the version the user installed later. Coinkite published emergency patches and users must install them, but install the patch does not correct a seed already generated with vulnerable firmware. The official recommendation is to generate a new seed with patched firmware and transfer the funds; to restore the ancient seed in the corrected firmware or in another purse reproduces weakness.

From the perspective of the attacker, this failure is dangerous because it allows an offline and directed approach: if an opponent can track or know data such as the device's ID, the timing status when starting or the RNG call history, it can reproduce candidate flows and derive words to check if any match addresses in the public chain. Public research has not yet presented a confirmed reconstruction of the seed of one of the looted addresses, and the "sweep" pattern observed by some teams (no change transactions at the rate of h.30 sat / vB) serves to identify the operator who moved coins, not to demonstrate the technique of per se theft.

For any Coldcard holder the practical priority is simple and urgent: to check whether the seed was created in an affected version and, if so, to migrate. Coinkite placed vulnerable series and versions in warning (e.g. Mk3 in certain patches 4.0.0-4.1.9, set at 4.2.0; Mk4 / Mk5 before 5.6.0; Q before 1.5.0Q, and "edge" buildings prior to specific indices). If you can't verify with certainty that the seed was born in secure firmware, generates a new seed with updated firmware and moves the funds to it. Do not restore or export the old seed to another device and do not make a seed safe simply because the device now has the latest version installed.

There are key nuances for advanced users: if the seed was created using at least 50 private and independent spins of a six-sided given (Coinkite's recommendation to provide physical entropy) or through a high-quality external source, the seed may not be at risk for this particular failure; in case of doubt, migrating remains the safest option. A strong BIP-39 password adds a layer that the single list of words can't jump, but Coinkite continues to recommend replacing the seed even when using passphrase. In multi-sig setups the exposure only exists if All The signatories share seeds that are significantly generated; multisig with heterogeneous signatories remains a solid mitigation.

The operational implications for industry are broad. Custodians, exchangers and fund managers should check volume key generation procedures and audit that third-party toolchains and bookstores use hardware RNG correctly. The chain of trust in a hardware wallet is not only the physical device but also the integration of firmware, compilation macros, and the treatment of wrappers that abtract the RNG. Firmware audits, entropy tests and use of independent mechanisms (e.g. seed generation with physical dice) should be part of the playbook for high-value systems.

For end-users and administrators I recommend to check the device version and the seed creation date, install the manufacturer's emergency firmware, generate a new seed in that firmware and transfer all the funds, check not to restore the old seed in any environment, use strong passphrases as additional defense and, where possible, deploy multiple signatures with different suppliers to minimize risk of common failure. It is also good practice to monitor own addresses and lists of transactions with unusual patterns (such as those mentioned without change) and to notify suppliers if suspicious activity is detected.

This incident recalls that critical security depends on both cryptographic robustness and software engineering. Hardware wallets users should consider not only the manufacturer's reputation but also the RNG implementation details and firmware construction practices. To read technical documentation on the BIP-39 seed standard and understand why entropy matters, you can see the official specification in GitHub: BIP-39 (specification). For information and advice from the manufacturer, visit the Coinkite / Coldcard website: Coinkite / Coldcard. If you manage significant funds, contact the manufacturer's support and consider professional advice for safe migration.