The 2026 Coldcard exploit stands as one of the most significant self-custody failures in Bitcoin history. A firmware integration error dating to March 2021 silently degraded seed entropy from the designed 128 bits to approximately 40 bits on Mk2/Mk3 devices and roughly 72 bits on later models. Attackers reconstructed candidate seeds offline, matched derived addresses against the public blockchain, and drained funds without physical access to any device. Confirmed losses exceeded $100–130 million across multiple waves.
This article provides an engineer-level examination of the failure, quantifies the cryptographic impact, details immediate remediation, and outlines durable prevention practices for hardware wallet design and user operations.
Technical Root Cause: Linker Resolution and a Misapplied Build Guard
In March 2021, Coinkite migrated elliptic-curve operations to Bitcoin Core’s libsecp256k1 and introduced the libngu cryptographic support library for the MicroPython environment. Seed generation previously called the board-specific ckcc.rng_bytes(), which correctly exercised the STM32 hardware True Random Number Generator (TRNG). The migration changed this call to ngu.random.bytes(32).
The critical defect occurred at the boundary between configuration and symbol resolution:
- Coldcard board configuration defined #define MICROPY_HW_ENABLE_RNG (0). Developers intended this to disable MicroPython’s built-in RNG paths because Coinkite maintained its own TRNG wrapper.
- Inside libngu, the guard used #ifndef MICROPY_HW_ENABLE_RNG rather than #if MICROPY_HW_ENABLE_RNG. Because the macro was defined (even with value zero), the guard passed.
- MicroPython’s ports/stm32/rng.c therefore compiled the software fallback: a Yasmarang PRNG. The linker resolved the external rng_get() symbol required by libngu to this fallback implementation instead of the hardware path present in Coldcard’s own rng.c.
The hardware TRNG code existed and was exercised for secondary purposes, but the primary seed-generation path never reached it. Two Yasmarang instances were effectively XORed: one seeded from device UID, SysTick, and RTC registers; the other from hardcoded public constants that contributed zero entropy.
Entropy Collapse and Search-Space Quantification
A standard BIP-39 12-word seed encodes 128 bits of entropy (plus checksum). The vulnerable path reduced this dramatically:
- Mk2 / Mk3 (firmware 4.0.1–4.1.9)**: Effective entropy ≈ 40 bits under Coinkite’s preliminary estimate. Primary contributions came from the low 32 bits of the STM32 Unique Device ID XORed with SysTick->VAL, plus limited RTC state. On cold boot with RTC at zero the space collapses further.
- Mk4 / Mk5 / Q (pre-fix firmware)**: Additional mixing of secure-element TRNG output raised the estimate to ≈ 72 bits—still far below the 128-bit design target.
At 40 bits the candidate space is roughly 1.1 trillion. Modern hardware can enumerate it in hours to days. At 72 bits the space remains within reach of well-resourced attackers performing offline pre-computation. Because the generation process is fully deterministic given the initial state, an attacker who constrains UID and timing variables can regenerate the exact PRNG stream offline, derive BIP-39 mnemonics, compute addresses, and match them against the public UTXO set.
Attack Surface and Observed Exploitation
The attack required no device possession, no side-channel measurement on victim hardware, and no network interaction with the wallet. Attackers:
- Reproduced the Yasmarang seeding logic.
- Enumerated plausible initial states (UID ranges extractable from USB descriptors or public data, SysTick ranges, RTC assumptions).
- Generated candidate seeds, derived addresses (typically native SegWit paths), and scanned the blockchain for funded matches.
- Executed rapid sweeps once matches were confirmed.
Galaxy Research documented multiple organized waves beginning 30 July 2026, with the largest single sweep moving more than 1,000 BTC in under an hour. Multiple independent attackers later appeared, indicating the technique became widely known.
Firmware updates cannot repair an already-generated weak seed. The vulnerability lives in the seed material itself.
Affected Scope and Fixed Firmware
| Model | Vulnerable Seed Generation Period | Fixed Firmware | Estimated Effective Entropy |
|----------------|--------------------------------------------|-------------------------|-----------------------------|
| Mk2 / Mk3 | 4.0.1 – 4.1.9 | 4.2.0+ | ≈ 40 bits |
| Mk4 / Mk5 | Before standard 5.6.0 / Edge 6.6.0X | 5.6.0+ / 6.6.0X+ | ≈ 72 bits |
| Q | Before standard 1.5.0Q / Edge 6.6.0QX | 1.5.0Q+ / 6.6.0QX+ | ≈ 72 bits |
Exceptions exist for seeds created with ≥ 50 independent, private dice rolls (≈ 129 bits of additional entropy) or protected by a strong, unique BIP-39 passphrase that itself supplies high entropy.
*Immediate Remediation Protocol
*
- Inventory — Determine the exact firmware version active when each seed was generated. If uncertain, treat the seed as potentially vulnerable.
- Migrate — On a device running fixed firmware (or an independent entropy source such as verified dice + BIP-39 tools), generate an entirely new seed. Prefer ≥ 50 private dice rolls mixed with hardware entropy.
- Transfer — Move all funds in a single transaction or carefully planned multi-output transaction to addresses derived from the new seed. Avoid address reuse patterns that could link old and new wallets.
- Verify — Confirm the receiving addresses on the new device before broadcasting. Destroy or securely archive the old seed material only after confirmed receipt and multiple confirmations.
- Passphrase users — Even with a strong passphrase, evaluate residual risk; the underlying weak entropy still reduces the overall security margin.
Updating firmware alone provides no protection for existing seeds.
Engineering-Level Prevention and Defense-in-Depth
For hardware wallet manufacturers and firmware developers:
- Enforce value-based conditional compilation (#if rather than #ifndef) for security-critical paths.
- Implement build-time assertions that fail compilation if the seed-generation call graph does not reach a verified hardware TRNG.
- Continuously monitor and mix multiple independent entropy sources (hardware TRNG, secure-element noise, user dice, timing jitter) with explicit entropy accounting.
- Subject the full seed-generation path to differential testing against a known-good TRNG oracle.
- Publish measurable entropy estimates and allow independent statistical testing of production RNG output.
- Maintain rigorous linker and symbol-resolution audits during library migrations.
For users and operators practicing self-custody:
- Prefer seed generation that incorporates independent physical entropy (dice, cards, or verified external sources) in addition to device RNG.
- Employ multi-signature schemes (2-of-3 or higher) so that compromise of any single seed is insufficient.
- Use strong, unique BIP-39 passphrases as an additional entropy layer, understanding that passphrase strength becomes critical when base entropy is degraded.
- Maintain air-gapped verification of address derivation and transaction construction.
- Periodically rotate high-value cold storage using newly generated, high-entropy seeds.
- Prefer open-source firmware with reproducible builds and independent security reviews focused on entropy sources.
Broader industry practices:
- Treat RNG quality as a first-class security property subject to the same rigor as key storage or secure-element isolation.
- Require continuous health testing and failure modes that halt seed generation on entropy failure.
- Encourage third-party entropy audits and formal verification of critical generation paths.
- Educate users that “hardware wallet” does not automatically equal “high-entropy seed.”
Conclusion
The Coldcard incident demonstrates that a single misplaced preprocessor directive, combined with silent fallback behavior and incomplete call-graph verification, can nullify years of careful hardware design. The resulting entropy collapse turned an offline, deterministic reconstruction attack into a practical, large-scale theft.
Immediate user action remains migration of any potentially affected seed to new, high-entropy material. Longer-term resilience requires treating entropy generation as a continuous, measurable, multi-source process that is verified both at build time and at runtime. Hardware wallets remain a powerful tool for self-custody, but only when every layer—from silicon noise to final BIP-39 mnemonic—delivers the cryptographic strength the design claims.
Users and developers who internalize these lessons will substantially reduce the probability of similar systemic failures in future Bitcoin custody systems.
Top comments (0)