Coldcard Entropy Failure (July–August 2026): Complete Technical Analysis of the Seed Generation Flaw, Attack Vectors and Practical Mitigation
Over the past two weeks, X (Twitter) and the broader Bitcoin community have been dominated by one critical security issue: the entropy failure in Coinkite’s Coldcard hardware wallets. Since 30 July 2026, successive on-chain sweeps have drained between 1,500 and more than 2,000 BTC (public estimates reach ~$130 million) from addresses generated on affected devices. The attack requires no physical access to the hardware, no malware and no classic phishing. It is purely offline and based on weak cryptography.
This guide is written for readers who want the real root-cause analysis (not just headline summaries), the exact attack vectors used by the attackers, verification tools and a precise step-by-step mitigation protocol. The goal is to raise the technical level of discussion and help users act with accuracy.
1. Current context on X and in the community (August 2026)Since the first sweep of 594 BTC in roughly 25–41 minutes (blocks near 960,183), multiple waves have been identified by Galaxy Research, Block Engineering and on-chain analysts. More than 15 distinct attackers have already participated. Daily active Bitcoin addresses surged to 980k (highest since December 2024), reflecting mass seed migration. Technical discussions on X centre on “entropy vs PRNG”, “Yasmarang”, “#ifndef vs #if”, “are dice rolls enough?”, “does a passphrase save you?” and comparisons with other hardware wallets.
The flaw has existed since the March 2021 firmware migration and remained silent for more than five years.
2. Technical root cause (reverse-engineering analysis)In 2021 Coinkite migrated elliptic-curve operations to libsecp256k1 (the same library used by Bitcoin Core) via the embedded libNgU library. Seed generation (make_new_wallet / ngu.random.bytes()) began depending on rng_get().
The failure occurred in symbol resolution at link time and in the compilation guard:
- The firmware defines MICROPY_HW_ENABLE_RNG as 0 (to disable MicroPython’s native path and use Coinkite’s own wrapper).
- libNgU checked only #ifndef MICROPY_HW_ENABLE_RNG (whether the macro exists), not its value (#if).
- Because the macro existed (even though its value was 0), the error guard never triggered.
- The linker resolved rng_get() to MicroPython’s fallback implementation (ports/stm32/rng.c), based on the Yasmarang pseudo-random generator, instead of the STM32 hardware TRNG (RNG->DR) that Coinkite had implemented.
Yasmarang is initialised only once from device and timing state:
- pad = UID_low32 XOR SysTick->VAL
- n = RTC->TR
- d = RTC->SSR
On Mk2/Mk3 models (firmware 4.0.1 to 4.1.9 / some 5.x builds) effective entropy dropped to approximately 40 bits (Coinkite estimate; independent Block Engineering analyses indicate even lower structural ceilings in certain cold-boot scenarios).
On Mk4, Mk5 and Q (before the fixes) a partial reseed from the Secure Elements (32 additional bits) raised the estimate to 72 bits — still catastrophically below the 128 bits expected from a standard 12-word BIP-39 seed.
The output looked like a perfectly valid BIP-39 mnemonic (correct checksum, words from the wordlist). The weakness exists only in the search space: 2^40 is enumerable with modern hardware; 2^72 is feasible for well-resourced actors.
Critical point: updating the firmware does
not repair an already-generated seed. A weak seed remains weak forever.
3. Exact attack vector (how the funds were drained)- The attacker reconstructs the generation pipeline (Yasmarang A XOR Yasmarang B → SHA-256 → BIP-39 → BIP-32 → address).
- Enumerates the reduced space of possible seeds (no physical device required).
- Derives the corresponding addresses and matches them against the set of on-chain UTXOs (especially higher-value and dormant addresses).
- When a match is found, signs and spends.
There is no signature exploitation, reentrancy or smart-contract bug. It is pure brute-force of a private key derived from insufficient entropy. Seeds generated with ≥50 independent private dice rolls + a strong unique BIP-39 passphrase fall outside the practical reach of this specific attack.
4. Affected models and firmwares (current summary)- Mk2 / Mk3: firmware 4.0.1 through 4.1.9 (and some 5.x builds) → ~40 bits (critical).
- Mk4 / Mk5: before 5.6.0 → ~72 bits.
- Q: before 1.5.0Q → ~72 bits.
- Official fixes: Mk2/Mk3 4.2.0+, Mk4/Mk5 5.6.0+ (and 6.6.0X Edge), Q 1.5.0Q+ (and 6.6.0QX).
- Not affected: TAPSIGNER, OPENDIME, SATSCARD (different codebases); seeds generated with sufficient dice rolls + strong unique passphrase.
5. Practical mitigation and verification protocolStep 1 – Diagnosis- Identify the model and the exact firmware version used at the moment the seed was generated (not the currently installed version).
- If the seed was created on vulnerable firmware without adequate dice rolls + a strong unique passphrase, treat it as compromised.
Step 2 – Hardware update- Download the official corrected firmware directly from Coinkite (verify hashes and signatures).
- Update the device before generating any new seed.
Step 3 – Generate a new seed with verifiable external entropy- Prefer generation with dice rolls (minimum 50–100 quality dice rolls, preferably casino-grade, in a controlled environment) or a combination of independent sources.
- Always add a strong, unique, long BIP-39 passphrase that is never reused (stored offline and separately from the seed).
- Verify the new wallet’s fingerprint (xpub / descriptor).
Step 4 – Fund migration- Create the new wallet on the updated device.
- Send a small test transaction.
- Confirm receipt and the change of fingerprint.
- Move the main balance in one or more transactions (consider fees and UTXO management).
- Never import the old seed into any other software or hardware — it remains weak.
Step 5 – Additional tools and practices- Monitor old addresses with explorers and on-chain alerts.
- For high-value setups: multisig with keys generated on devices from different manufacturers and independent entropy sources.
- Future code audits: always review the complete symbol-resolution chain for RNG (not merely the presence of TRNG code).
- Official sources: blog.coinkite.com (Technical Deep Dive and Security Advisory).
6. Engineering and cryptographic lessonsThis incident reinforces classic principles:
- Entropy is the foundation. A silent one-line compilation-guard bug can nullify years of Secure Element design and code review.
- Software fallbacks in security hardware must be impossible to activate accidentally (fail-closed).
- Link-time symbol verification and production-build entropy tests are mandatory.
- “Trust but verify” applies even to open-source firmware: the presence of TRNG code does not guarantee it is the path actually executed.
No hardware is magical. Real security lies in architecture (multisig, external entropy, passphrase, disciplined cold storage) and in the user’s ability to audit what actually happens during key generation.
Questions for technical debate- Which external entropy generation methods (dice, avalanche noise, etc.) do you consider the most robust and auditable in practice for high-value seeds?
- In multisig setups, what is the best current strategy for combining devices from different manufacturers after this incident?
- Has anyone implemented or responsibly tested tools for enumerating/verifying weak seed spaces (only against their own addresses)?
- How should the community push for automated entropy tests and fail-closed behaviour in open-source hardware-wallet firmwares?
Share technical analyses, migration experiences and factual corrections. The goal is deep learning and collective protection.
Stay safe and verify everything.
