The most important accuracy rule is not to turn a serious, confirmed RNG failure into claims the evidence does not support.

During a 2021 cryptographic-library migration, Coldcard wallet generation changed from its board-specific hardware RNG path to ngu.random.bytes(). That call resolved to MicroPython’s deterministic Yasmarang fallback instead of the intended hardware random-number generator.

The hardware RNG code was still present in the firmware binary, but the wallet-generation path did not reach it. The fallback exposed the same function shape, so the build completed. Code review confirmed that the intended implementation existed; it did not prove which implementation the seed-generation call actually used.

The result was not merely “bad-looking randomness.” A deterministic generator can produce output that appears statistically uniform while still selecting from a candidate family far smaller than the expected 128-bit or 256-bit security target. An attacker can generate candidates offline and use public wallet material, such as an address or extended public key, to test them.

Block says its investigation followed theft reports and concluded that active exploitation was underway. Block also explicitly says its report reflects its current understanding and that it had not performed full empirical testing to confirm every exploit path. CryptoCloaks has not independently verified individual theft claims. We therefore present Block’s statement as Block’s conclusion, not as independent proof of each reported loss.

The version that generated the seed is what matters. Installing safe firmware today does not change how an existing seed was created.

Standard and Edge are different release tracks. A numerically higher older Edge version is not automatically fixed. Use the fixed release for the model and track you actually run.

Coinkite’s current estimates are approximately 40 bits for affected Mk2/Mk3 generation and approximately 72 bits for affected Mk4/Mk5/Q generation. Both are below the intended security target.

These are preliminary effective-search-space estimates under stated attack assumptions, not promises that every wallet takes the same amount of work to recover. Practical attack cost depends on what can be constrained about device identity, boot timing, prior PRNG calls, derivation paths, passphrases, and public wallet information.

Block’s independent analysis describes deterministic fallback behavior on Mk2/Mk3 and a later-model reseed that retained only four bytes, or 32 bits, from secure-element-derived material. Coinkite says the later secure-element input materially improved Mk4, Mk5, and Q compared with Mk2/Mk3, but still did not meet the intended security level.

1. Stop sending new funds to the potentially affected wallet. Preserve the existing device and backup long enough to authorize and verify the migration.
2. Determine the seed’s origin. Record the model, standard or Edge track, and firmware version that generated it. If the history is uncertain, treat that uncertainty as risk.
3. Read the current primary guidance. Use Coinkite’s security advisory and technical backgrounder, not screenshots or early summaries.
4. Prepare a different trusted generation workflow. CryptoCloaks recommends not using Coldcard to generate the replacement. If you instead follow Coinkite’s path, install and verify the fixed release before creating anything new.
5. Create a completely new seed. Never “upgrade” by reusing the affected words. Do not type seed words or private dice rolls into a website, chat, cloud note, or ordinary networked computer.
6. Back up and reproduce the new wallet. Verify the wallet fingerprint and a receive address. Keep any BIP-39 passphrase separate from the seed words.
7. Send a small test transaction. Confirm receipt and prove that you can reproduce the same wallet before transferring the remainder.
8. Move the remaining funds and retire the old seed. Keep the old backup until every expected balance has arrived and confirmed. Then prevent the compromised or suspect seed from receiving funds again.

Mk2/Mk3 owners who have only one device should follow Coinkite’s dedicated one-device sequence rather than improvising. CryptoCloaks’ stronger platform recommendation does not change the need to preserve access long enough to move funds safely.

At least 50 fair, independent, private D6 rolls

Coinkite says the bug did not erase independent entropy added through Coldcard’s dice-roll seed flow. Its current guidance states that 50 to 98 fair, independent, private D6 rolls contribute at least 128 bits of entropy, while 99 or more contribute approximately 256 bits.

• 50 or more qualifying rolls: Coinkite does not consider the resulting final seed at risk from this RNG issue alone.
• Fewer than 50, uncertain count, predictable rolls, recorded rolls, or exposed rolls: migrate.
• The exception applies to the final seed words displayed after the rolls were added. It does not apply if you later used a different seed.

A strong BIP-39 passphrase is a separate barrier, not a repair

A strong, unique, secret BIP-39 passphrase can make immediate candidate testing harder because an attacker must also discover the passphrase wallet. A short, common, patterned, quoted, reused, exposed, or uncertain passphrase should not be treated as protection. The Coldcard PIN is not a BIP-39 passphrase.

Coinkite still recommends that passphrase users migrate as soon as practical. Every passphrase, including a typo, creates a valid but different wallet, so compare the wallet fingerprint before moving funds.

Coldcard moved elliptic-curve operations to Bitcoin Core’s libsecp256k1 through the embedded libNgU library. During that migration, seed generation changed from ckcc.rng_bytes() to ngu.random.bytes().

The board configuration defined MICROPY_HW_ENABLE_RNG as zero because Coldcard supplied a separate hardware-RNG wrapper. LibNgU checked whether the macro was defined, not whether its value was nonzero. MicroPython used the zero value to compile its deterministic fallback. Compatible function signatures allowed the wrong implementation to satisfy the build.

On affected Mk2/Mk3 firmware, the fallback was seeded mainly from device and timing state. On Mk4, Q, and Mk5, secure-element values were mixed into the software generator, but Block’s analysis says only four digest bytes reached the reseed function.

Coinkite says the hotfix removes the fallback PRNG object and adds a link/build-time symbol check so the build fails unless the board-specific RNG implementation supplies the expected symbol and the upstream fallback supplies none.

Block’s report says the same ngu.random construction fed additional functions, including random paper-wallet keys, random Seed XOR masks, some cloning and encrypted-transfer keys, generated Secure Notes passwords, and other temporary key material.

That does not mean every feature has the same impact or that every use reveals the main wallet. Consequences depend on whether public material allows candidate private values to be tested and what an attacker captured. A vulnerable paper-wallet key, for example, could threaten that standalone paper wallet without necessarily exposing the device’s primary seed.

A hardware wallet is a trust decision about key generation, implementation review, release engineering, and incident response. The specific hotfix matters, but so does the failure mode that reached production.

• The intended secure RNG implementation existed in the firmware, yet the critical wallet-generation path reached a deterministic fallback.
• The integration survived builds and review because symbol presence was mistaken for proof of runtime binding.
• The affected path remained in released firmware across multiple product generations and release tracks.
• The same random stream was used by functions beyond standard seed generation.
• Coinkite’s own estimates say some affected seeds delivered far less search resistance than users expected.

Coinkite has published fixes, owner guidance, and a technical backgrounder. Those actions matter and should be judged on their merits. Our conclusion is still that we are not comfortable recommending Coldcard for new or primary custody. That is a vendor-trust conclusion, not a claim that the fixed firmware is secretly proven broken.

• Coinkite: Coldcard Security Advisory
• Coinkite: Technical Deep Dive into the Entropy Issue
• Coldcard: Current firmware and upgrade instructions
• Coldcard: Verifying dice-roll math
• Coldcard: BIP-39 passphrase documentation
• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in Coldcard Firmware

SECURITY NOTE // CryptoCloaks will never ask for your seed words, passphrase, dice rolls, xprv, private keys, or wallet backup. No legitimate migration help requires sending those secrets to us.