COLDCARD RNG Incident: What Weak Seed Entropy Means

On July 30, 2026, Coinkite published a security advisory covering seed phrases generated by affected COLDCARD firmware. The company said a software integration bug prevented the intended hardware random-number generator from contributing to seed generation. Fixed firmware is now available, but an update cannot strengthen a seed that was already created.

This is a serious wallet-security event, but it needs careful language. Coinkite's investigation is still developing, and an independent analysis from Block reaches a stricter assessment of parts of the random-number path. The facts that matter most for users are already clear: identify how and when the seed was generated, install the correct fixed firmware, and replace an affected seed rather than assuming an update repaired it.

The incident also exposes a broader self-custody lesson. A wallet can stay offline, use a secure element, and produce a valid 12- or 24-word phrase while still relying on insufficient randomness. Seed format and seed strength are different properties.

Quick Answer: What happened in the COLDCARD RNG incident?

The COLDCARD RNG incident was a seed-generation flaw in which affected firmware called a predictable software fallback instead of the intended hardware random-number generator. Coinkite says seeds created on the affected versions may have substantially less entropy than expected. The company released fixed firmware, but users with affected seeds must create a new seed and migrate funds because firmware cannot add randomness to an old seed.

Coinkite's August 1 update says seeds may fall outside the immediate risk described by the advisory if the user added at least 50 fair, independent, private dice rolls during creation. A strong, unique BIP-39 passphrase adds a separate barrier, but Coinkite still recommends migration. A device PIN is not a BIP-39 passphrase.

Key Takeaways

• The confirmed issue concerns seed generation, not a break of Bitcoin's signature algorithm or BIP-39 itself.
• Affected firmware reached a software fallback rather than the intended hardware random-number generator.
• A valid-looking seed phrase can be weak if it came from a small or predictable set of possible inputs.
• Installing fixed firmware protects future seed generation. It does not repair an existing affected seed.
• Coinkite and Block differ on the exact effective search space in parts of the affected code, but both analyses support replacing affected seeds.
• Users should follow the model-specific official advisory, verify the new wallet, send a test transaction, and only then move the remaining balance.
• The lesson applies to every hardware-wallet vendor, including UKey: seed generation needs end-to-end tests that prove the intended entropy source reaches the final wallet seed.

What is seed entropy?

Seed entropy is the unpredictable input used to create a wallet's root secret. Entropy is measured in bits. If a seed is selected uniformly from 2¹²⁸ possible values, an attacker cannot feasibly search the entire space with present-day computing. If an implementation accidentally limits the effective space to 2⁴⁰, the words may look normal while the number of realistic candidates becomes drastically smaller.

BIP-39 defines how entropy and a checksum become a mnemonic sentence and how that sentence derives a binary seed. A 12-word BIP-39 phrase normally encodes 128 bits of initial entropy plus a 4-bit checksum. A 24-word phrase normally encodes 256 bits plus an 8-bit checksum. More words do not fix a generator that selected its input from a predictable subset.

This is why a recovery phrase is more than a list of words. The phrase is a portable representation of the root secret described in our guide to recovery phrases and seed backups. Its security depends on secrecy and on how unpredictably it was created.

What Coinkite confirmed

Coinkite's security advisory, published July 30 and updated August 1, lists affected models, release tracks, fixed versions, and migration steps. The advisory says funds controlled by affected seeds are at risk when the seed was created without at least 50 independent, private dice rolls and the funded wallet lacks a strong, unique BIP-39 passphrase.

The separate technical backgrounder explains the implementation failure. During a 2021 migration to a library that exposes Bitcoin cryptographic primitives, seed generation moved from one random-byte function to another. That new path resolved to MicroPython's software fallback rather than COLDCARD's board-specific hardware RNG implementation.

The intended hardware code was present in the firmware, and the fallback had the same function signature. Existing review checked the intended code but did not prove which implementation the seed-generation call actually reached. A preprocessor check also tested whether a setting was defined instead of testing whether its value was nonzero. The build therefore succeeded when it should have failed.

The hotfix excludes the fallback object and adds a build-time symbol check. This is a useful engineering detail because it shows that reviewing a random-number function in isolation is not enough. The final production build must prove that wallet creation calls that exact function.

Affected COLDCARD seed-generation ranges and fixed firmware listed in Coinkite's August 1, 2026 advisory.

Model and track	Affected seed generation	Fixed version	Does updating repair an old seed?
Mk2 / Mk3	Versions 4.0.1 through 4.1.9	4.2.0 or later	No. Create a new seed after updating.
Mk4 / Mk5 standard	Before 5.6.0	5.6.0 or later	No
Q standard	Before 1.5.0Q	1.5.0Q or later	No
Mk4 / Mk5 Edge	Before 6.6.0X	6.6.0X or later	No
Q Edge	Before 6.6.0QX	6.6.0QX or later	No

Standard and Edge are separate release tracks. Users should confirm the exact model, track, and version on the device instead of comparing version numbers across tracks. Coinkite says TAPSIGNER, OPENDIME, and SATSCARD are not affected because they use different codebases.

Why a valid BIP-39 phrase can still be weak

BIP-39 validates structure, not the quality of the original randomness. A wallet can create words from the official list, add the correct checksum, and derive addresses exactly as the standard specifies. None of those steps proves that the starting entropy was unpredictable.

Imagine a machine that is supposed to choose one ticket from an enormous warehouse but accidentally chooses only from one small drawer. Every selected ticket can have the correct format. The problem is that an attacker can search the drawer instead of the warehouse.

This distinction also explains why checking whether a phrase restores successfully is not a security test. Recovery proves that the backup is internally consistent and reaches the expected addresses. It does not measure how many other seeds an attacker may need to test. Our seed phrase vs private key guide explains how the root backup and derived signing keys relate, but both inherit the strength of the original seed.

What do the 40-bit and 72-bit estimates mean?

Coinkite's preliminary technical assessment estimates an effective search space of about 40 bits for the affected Mk2 and Mk3 path. It estimates about 72 bits for Mk4, Q, and Mk5 because later models mixed additional secure-element values into the state. The company says these estimates may change as the investigation continues.

Block's independent technical analysis presents a stricter model of the predictable fallback and the later devices' reseeding behavior. The two analyses do not currently agree on every estimate or assumption. That disagreement should be reported, not smoothed over.

Users do not need to settle the technical dispute before acting. Both positions lead to the same practical conclusion for a seed covered by the advisory: update first, generate a fresh seed, verify it, and migrate. Waiting for a final bit count adds no protection to the old seed.

For context, NIST's random-bit generation guidance treats entropy sources, deterministic generators, validation, and health testing as parts of one system. The IETF's randomness requirements make the same basic point: cryptographic keys depend on inputs an adversary cannot predict.

Who should treat a COLDCARD seed as affected?

A user should compare the device model, firmware track, firmware version at the time of seed creation, use of dice entropy, and use of a BIP-39 passphrase. The version installed today is not enough. The relevant version is the one that generated the seed now controlling funds.

Under Coinkite's August 1 advisory, treat the seed as affected if it was created in one of the listed ranges and you did not add at least 50 fair, independent, private dice rolls. If you added fewer than 50, cannot remember the number, recorded the rolls, or exposed them, the advisory says to migrate.

A strong, unique BIP-39 passphrase adds an independent secret. A short quotation, reused password, pattern, or common phrase may be guessable. Coinkite says even users with a strong passphrase should migrate as soon as practical because the passphrase does not repair the root seed. Read our passphrase vs seed phrase comparison before changing either part of a wallet setup.

If the history is uncertain, uncertainty itself is a reason to use the conservative path. Do not enter the old seed into a website, online checker, AI assistant, support chat, or networked "audit" tool to determine whether it is affected.

Why a firmware update cannot repair an old seed

A firmware update changes future behavior; it does not rewrite the mathematical origin of an existing wallet. Addresses and private keys are deterministically derived from the same root seed. Keeping the old seed after updating keeps the same candidate an attacker may already be searching.

The remedy is key rotation at the wallet level: create a new root seed with the fixed process and transfer funds to addresses derived from it. Restoring the old phrase on fixed firmware also does not strengthen it. The device will faithfully recreate the same old wallet.

This principle appears in other weak-key incidents outside hardware wallets. Once a cryptographic secret was generated from weak randomness, patching the generator only protects secrets created after the patch. Existing keys have to be replaced.

How affected users should migrate

Use the current model-specific Coinkite instructions as the source of truth. The following summary explains the logic without replacing those instructions.

1. Confirm the model and release track. Standard and Edge firmware have different fixed versions. Download only from the official vendor route.
2. Install the fixed firmware before creating anything new. Check the version on the device. Do not generate the replacement seed on affected firmware.
3. Create a completely new seed. Do not reuse, rearrange, extend, or "upgrade" the old words.
4. Record and verify the new backup offline. Confirm the wallet fingerprint and a receive address on the device itself.
5. Send a small test transaction. Restore or re-open the new wallet as required and verify that the test arrived at the address you checked.
6. Move the remaining balance. Confirm the full balance in the new wallet before considering the migration complete.
7. Keep the old backup until confirmation is complete. Destroying it too early can turn a careful migration into an unrecoverable loss.

A one-device migration requires switching safely between the old and new wallets. This raises operational risk, so follow the vendor's exact workflow. For a broader preparation checklist, see what to do when a hardware wallet must be recovered or replaced.

Migration mistakes to avoid

• Do not rush because of social-media claims or an unverified countdown.
• Do not generate the replacement seed before confirming fixed firmware.
• Do not type either seed into a browser, phone note, cloud document, email, or support form.
• Do not send the full balance before verifying a test transaction and the destination address on the hardware screen.
• Do not assume a new passphrase transforms the weak seed into a repaired seed.
• Do not discard the old backup before every relevant account and balance is confirmed on the new wallet.
• Do not follow recovery links sent by direct message. Security incidents attract impersonators.

Calm verification matters more than speed alone. A migration introduces new chances to select the wrong network, copy the wrong address, lose a passphrase, or erase the only valid backup. The practical controls in our guide to securing crypto assets still apply during an emergency.

What every hardware-wallet vendor should prove

The COLDCARD incident is not evidence that hardware wallets are pointless. It is evidence that security claims need tests at the final boundary users depend on. An air gap can reduce network exposure. A secure element can isolate secrets. Open source can permit outside review. None of these properties alone proves that the final seed received the intended entropy.

A credible seed-generation design should be able to answer these questions:

• Which independent entropy sources contribute to the seed?
• What happens if one source fails, returns repeated data, or is absent from the build?
• Does the device fail closed, or can it silently fall back to a weaker generator?
• Do production-build tests trace the wallet-creation call to the expected implementation?
• Are source-combination rules, minimum entropy targets, and health checks documented?
• Can external reviewers reproduce the build and inspect the seed-generation path?
• How will users be notified, patched, and guided through key migration after a defect?

The OWASP Cryptographic Storage Cheat Sheet recommends cryptographically secure random-number generators for keys and warns against insecure general-purpose random functions. For a hardware wallet, that requirement must survive compiler settings, library integration, symbol resolution, and the final release build.

What this means for UKey users

The same standard should be applied to UKey. Users should not accept the words "hardware wallet," "secure element," or "offline" as a substitute for evidence about the full seed and signing path. UKey's security documentation should make its trust boundaries clear and should be updated when implementation details or audit evidence change.

Our article on how UKey protects private keys explains the intended separation between connected software and hardware signing. That separation addresses key exposure during ordinary use. Seed generation is an earlier boundary and deserves its own end-to-end verification.

Users can also reduce concentration risk through good recovery practice: initialize through official software, keep recovery material offline, verify backups before funding, and treat every migration as a controlled key-rotation exercise. An authenticity check helps confirm the device and software route, but it does not replace careful seed handling.

Related Resources

• What Is a Recovery Phrase?
• Seed Phrase vs Private Key
• Passphrase vs Seed Phrase
• How to Secure Your Crypto Assets
• What to Do If You Lose a Hardware Wallet
• How UKey Protects Private Keys

Source status: This article reflects Coinkite's advisory and technical backgrounder as updated on August 1, 2026, plus Block's independent analysis available by August 3, 2026. The investigation may change technical estimates or model-specific guidance. Check the official advisory before acting.

This article is for educational purposes only. It is not financial, legal, investment, or personalized incident-response advice. Never disclose seed words, dice rolls, passphrases, private keys, or funded wallet backups to a website, support agent, or third party.