Frederick Staunch avatar
Frederick Staunch Founder, Editor-in-Chief & Technical Editor

Frederick Staunch turns the Coldcard advisory into a practical exposure-classification process built around the device model, firmware used when the seed was created, and the actual seed-generation history. His contribution is helping readers decide whether migration is warranted without exposing recovery words or confusing current firmware with the security of an older seed.

@FredStaunchBTC Last updated 3 Aug 2026

The most important Coldcard question is not which firmware is installed today.

It is this:

Which device, firmware version, release track, and entropy process created the seed that currently controls your Bitcoin?

A wallet can be running fixed firmware now while still using a seed that was generated years earlier by affected firmware. Updating the device does not change the old seed, private keys, wallet fingerprint, or addresses.

This guide helps you classify the seed without exposing secret material.

Security notice: Never enter your seed words, BIP39 passphrase, PIN, dice sequence, private keys, wallet file, or recovery screenshots into a website, form, chat, email, or support message. Bitcoin Plaster will never ask for them.

Last verified: August 3, 2026
Status: Based on Coinkite's advisory updated August 1, 2026. The vendor investigation remains ongoing.

What This Check Can Tell You

At the end of the checklist, your result should fall into one of four categories:

  1. Affected or should be treated as affected
  2. Not in the current official scope of this RNG issue
  3. Not considered at risk from this RNG issue alone because sufficient independent dice entropy was added
  4. Uncertain or multisignature-specific, requiring further review

This is not a tool that scans a wallet or checks recovery words. It is a decision process based on how the seed was created.

Before You Begin

Collect only non-secret information:

  • the Coldcard model;
  • the firmware version active when the seed was created;
  • whether Standard or Edge firmware was used;
  • whether the seed was generated on the Coldcard or imported from elsewhere;
  • whether dice rolls were added during the creation of the current seed;
  • whether the funded wallet uses a BIP39 passphrase;
  • whether the key participates in a multisignature wallet;
  • whether the seed was used as a BIP85 parent.

Do not write secret material into this checklist.

Do not assume the firmware installed now is the version that created the seed.

If you cannot establish an important fact, mark it as unknown rather than guessing.

Step 1: Was the Current Seed Generated on a Coldcard?

Start by identifying where the recovery phrase was originally created.

The Seed Was Generated on the Coldcard

Continue to Step 2.

The model and firmware active at seed creation determine whether the seed falls inside the current official scope.

The Seed Was Imported From Another Wallet

The current Coldcard did not create the seed, so its seed-generation bug did not create that secret.

However, the origin still matters.

  • If the seed was generated by an independent wallet or process outside the affected Coldcard scope, it is not affected by this specific Coldcard RNG issue.
  • If the seed was originally generated on an affected Coldcard and later imported into another Coldcard or a different hardware wallet, the seed remains affected.
  • Restoring the same words on another device does not generate new private keys.

A different device does not change the history of the seed.

You Do Not Know Where the Seed Was Generated

Treat the result as uncertain.

Look for non-secret evidence such as setup notes, purchase dates, old device records, wallet fingerprints, or documentation of the original wallet ceremony. Do not enter the seed into software to investigate its origin.

Step 2: Which Coldcard Model Generated the Seed?

The current Coinkite advisory names the following device families:

  • Mk2
  • Mk3
  • Mk4
  • Mk5
  • Q

Coinkite states that TAPSIGNER, OPENDIME, and SATSCARD are not affected because they use different codebases.

Mk1 is not named in the current official affected scope. That means it is not currently classified as affected by this advisory, not that every possible security concern has been ruled out forever.

Record the exact model before comparing firmware versions.

Step 3: Which Firmware Version Was Active When the Seed Was Created?

This is the decisive firmware question.

Do not use the version installed today unless the seed was generated after that version was installed.

As of August 3, 2026, Coinkite identifies the following affected and fixed ranges:

Coldcard model and track Seed-generation firmware in scope Fixed release for new seed generation
Mk2 and Mk3 4.0.1 through 4.1.9, inclusive 4.2.0 or later
Mk4 and Mk5, Standard Earlier than 5.6.0 5.6.0 or later
Mk4 and Mk5, Edge Earlier than 6.6.0X 6.6.0X or later
Q, Standard Earlier than 1.5.0Q 1.5.0Q or later
Q, Edge Earlier than 6.6.0QX 6.6.0QX or later

Your Seed Was Generated Inside an Affected Range

Continue to Step 4.

The seed is inside the vendor-confirmed operational scope. Dice entropy, passphrase use, and multisignature structure may change the immediate risk, but an affected seed is not repaired by a later firmware update.

Your Seed Was Generated on the Fixed Release or Later

The seed is not in the current official scope of this RNG issue, provided you have identified the correct model and release track.

This conclusion applies only to this specific incident. It is not a universal guarantee that the complete wallet setup is free from every other failure.

You Cannot Confirm the Firmware at Seed Creation

Treat the seed as uncertain.

If the device and approximate creation date place it near or inside the affected period, the conservative response is to follow the migration guidance rather than assume the seed is safe.

Step 4: Was the Device on the Standard or Edge Firmware Track?

Mk4, Mk5, and Q users must identify the release track.

Standard and Edge are separate branches with separate version numbering.

A version beginning with 6 is not automatically newer than or equivalent to a fixed Standard release beginning with 5 or 1. The version must be compared with the fixed release for the same track.

Standard Track

Use these fixed boundaries:

  • Mk4 and Mk5: 5.6.0 or later
  • Q: 1.5.0Q or later

Edge Track

Use these fixed boundaries:

  • Mk4 and Mk5: 6.6.0X or later
  • Q: 6.6.0QX or later

You Do Not Know the Track

Do not compare only the leading number.

Treat the result as uncertain until the exact release family is established.

Step 5: Were Dice Rolls Added When This Seed Was Created?

Coinkite says the issue affected device-generated entropy. It did not remove independent entropy correctly supplied through the documented Add Dice Rolls process.

The current advisory states:

  • 50 to 98 fair, independent, private rolls: the dice input alone contributed at least approximately 128 bits of entropy;
  • 99 or more fair, independent, private rolls: the dice input contributed approximately 256 bits of entropy;
  • fewer than 50 rolls, unknown count, exposed rolls, or uncertain procedure: follow the migration guidance.

At Least 50 Valid Private Rolls Were Added

Coinkite says it does not consider the resulting seed at risk from this RNG issue alone when at least 50 qualifying rolls were incorporated into the final seed.

That conclusion depends on all of the following being true:

  • the rolls were made with a fair six-sided die;
  • each roll was independent;
  • the sequence remained private;
  • the rolls were entered correctly;
  • the rolls were added during creation of the seed currently controlling the funds;
  • you are certain that at least 50 rolls were used.

The correct result is:

Not considered at risk from this RNG issue alone because sufficient independent dice entropy was added.

This is not a statement that the entire custody setup is universally safe.

Fewer Than 50 Rolls Were Added

The dice exception does not apply.

Continue to Step 6 and treat the seed as affected if it was created inside the affected firmware range.

You Do Not Remember the Count or Procedure

Do not round up from memory or assume the dice protected the wallet.

Treat the seed as affected or uncertain and follow the migration guidance.

You Rolled Dice Later

Dice added after the current seed was created do not change that seed.

New entropy matters only when it is used to generate a completely new secret.

Step 6: Does the Funded Wallet Use a BIP39 Passphrase?

A BIP39 passphrase is not the Coldcard PIN.

The PIN protects access to the physical device. A BIP39 passphrase participates in wallet derivation and creates a different wallet from the same recovery words.

No BIP39 Passphrase

If the seed was generated inside the affected firmware range and the dice exception does not apply, classify it as:

Affected or should be treated as affected.

Continue to Step 7 if the wallet is multisignature. Otherwise, proceed to the result section.

A Strong, Unique, Secret BIP39 Passphrase Was Used

A strong passphrase adds an independent barrier. An attacker who reconstructs the affected mnemonic would also need the passphrase to reach that wallet.

However:

  • the passphrase does not repair the underlying seed;
  • the affected mnemonic still came from reduced entropy;
  • losing or mistyping the passphrase can create a separate recovery failure;
  • Coinkite still recommends migration as soon as practical.

The correct result is:

The seed remains affected, but a strong passphrase may reduce immediate exposure. Migration is still recommended.

The Passphrase Was Short, Common, Patterned, Quoted, Reused, or Human-Predictable

Treat the funds as at risk.

A passphrase that feels memorable or complicated is not automatically resistant to targeted guessing.

You Are Unsure Whether the Passphrase Is Strong

Do not use uncertainty as a security claim.

Treat the seed as affected and migrate.

Step 7: Is the Wallet Single-Signature or Multisignature?

Single-Signature

A single-signature wallet controlled by one affected seed has the clearest exposure.

If the seed is reconstructable, no second signer is required to spend the Bitcoin.

When the affected firmware range applies and the dice exception does not, classify the wallet as:

Affected or should be treated as affected.

A strong passphrase may reduce immediate exposure, but the seed should still be replaced.

Multisignature

Do not classify a multisignature wallet by counting devices alone.

The decisive question is:

Can the spending threshold be satisfied entirely with affected Coldcard-generated keys?

For a two-of-three wallet:

  • one affected Coldcard key plus two independent keys is not spendable with the affected key alone;
  • two affected Coldcard keys may be enough to satisfy the threshold;
  • three affected Coldcard keys may preserve the two-of-three structure while sharing the same generation failure.

Inventory every signer:

  • which device generated the key;
  • which firmware created the seed;
  • whether dice entropy was added;
  • whether the key was independently generated;
  • whether affected keys alone can satisfy the threshold.

Affected Keys Can Satisfy the Threshold

Classify the wallet as:

Affected or should be treated as affected.

Multisignature migration can involve script exposure, descriptor handling, signer replacement, and mempool risk. Do not improvise a complex migration under pressure.

At Least One Independent Unaffected Key Is Always Required

The affected Coldcard key alone is not enough to spend.

That reduces the immediate risk from this one signer, but the affected signer should still be replaced in a controlled way. The wallet remains dependent on a key that did not meet the intended generation standard.

You Cannot Reconstruct the Signer Inventory or Threshold

Classify the result as:

Uncertain and requires experienced multisignature review.

Do not reset devices, discard descriptors, or start replacing signers without a complete recovery record.

Step 8: Was the Affected Seed Used as a BIP85 Parent?

BIP85 derives child secrets deterministically from a parent seed.

It does not add independent entropy that can repair a weak parent.

If the parent seed is affected, any BIP85 child derived from it should be included in the same migration boundary.

This is not a BIP85 defect. It is the normal consequence of deriving children from compromised parent key material.

Record every wallet, child seed, or credential derived from the affected parent before retiring it.

Step 9: Classify Your Result

Use the first result that accurately matches your evidence.

Result A: Affected or Should Be Treated as Affected

This applies when:

  • the seed was generated by an affected model and firmware;
  • fewer than 50 qualifying dice rolls were used, or the dice history is uncertain;
  • no strong passphrase protects the funded wallet, or the passphrase strength is uncertain;
  • a single-signature wallet depends on the affected seed;
  • a multisignature threshold can be satisfied entirely with affected keys.

Next step: Read the full migration guide before moving funds.

How to Move Bitcoin From a Potentially Weak Coldcard Seed Without Making It Worse

Result B: Not in the Current Official Scope of This RNG Issue

This applies when:

  • the seed was generated outside the affected Coldcard firmware ranges;
  • the seed was generated on the fixed release or later for the correct model and track;
  • the seed was imported from an independent source and was not originally created by affected Coldcard firmware;
  • the product is TAPSIGNER, OPENDIME, or SATSCARD, which Coinkite says use different codebases.

This result concerns only this specific RNG issue. It is not a complete security audit of the wallet.

Result C: Not Considered at Risk From This RNG Issue Alone Because of Dice Entropy

This applies when:

  • the seed was otherwise inside the affected firmware scope;
  • at least 50 fair, independent, private dice rolls were correctly incorporated into the final seed;
  • the count and procedure are known with confidence.

Do not use this result when the number of rolls, secrecy, fairness, or procedure is uncertain.

Result D: Affected Seed With an Additional Passphrase Barrier

This applies when:

  • the seed is in the affected firmware scope;
  • the dice exception does not apply;
  • the funded wallet uses a strong, unique, secret BIP39 passphrase.

The passphrase may reduce immediate exposure, but the seed remains affected. Coinkite recommends migration as soon as practical.

Result E: Uncertain or Multisignature-Specific

This applies when:

  • the seed origin is unknown;
  • the firmware at creation is unknown;
  • the release track is unknown;
  • the dice history is uncertain;
  • the passphrase strength is uncertain;
  • the multisignature threshold or signer origin is unclear;
  • BIP85 children or other derived secrets may be involved.

Uncertainty should not be converted into a safety claim.

Gather non-secret records and seek experienced help for complex multisignature or derived-key setups.

Quick Decision Tree

Use this compressed path only after reading the detailed steps above.

  1. Was the seed generated on a Coldcard?
    • No: investigate the original generator.
    • Yes: continue.
  2. Was it generated inside the affected model and firmware range?
    • No: not in the current official scope of this issue.
    • Yes or unknown: continue.
  3. Were at least 50 qualifying private dice rolls added to the final seed?
    • Yes, with certainty: not considered at risk from this RNG issue alone.
    • No or unknown: continue.
  4. Does a strong, unique BIP39 passphrase protect the funded wallet?
    • Yes: immediate exposure may be reduced, but migrate.
    • No or uncertain: treat as affected.
  5. Is the wallet multisignature?
    • No: treat as affected.
    • Yes: determine whether affected keys can satisfy the threshold.
  6. Can affected keys satisfy the threshold?
    • Yes: treat as affected.
    • No: immediate spending still requires an independent key, but replace the affected signer carefully.
    • Unknown: obtain experienced review.

What Not to Use as Evidence of Safety

None of the following proves that an old seed was generated safely:

  • the device is air-gapped;
  • the device has a secure element;
  • the firmware is open source;
  • the firmware installed today is fixed;
  • the device currently works normally;
  • the PIN is strong;
  • the seed was restored onto a different wallet;
  • the wallet has not yet lost funds;
  • no suspicious transaction has appeared;
  • another person with the same model was unaffected.

The seed-generation conditions determine whether the current secret falls inside this incident.

What to Do After the Check

When the Seed Is Affected

Do not simply import the old words into another device.

The security boundary is:

  1. install and verify fixed firmware on the device that will generate the replacement seed;
  2. generate a completely new seed;
  3. record and verify the new backup;
  4. verify a receive address on the destination device screen;
  5. send a small test transaction;
  6. confirm the destination wallet works and can be recovered;
  7. move the remaining balance;
  8. keep the old backup until the entire migration is confirmed.

Read the full migration procedure before taking action:

How to Move Bitcoin From a Potentially Weak Coldcard Seed Without Making It Worse

When the Seed Is Not in Scope

Do not move funds solely because of generalized fear.

Unnecessary wallet resets, seed exposure, rushed transfers, and untested recovery changes can create new risks.

Continue normal security maintenance and verify backups through the wallet's supported offline process.

When the Result Is Uncertain

Preserve the device, backup, wallet fingerprint, descriptors, purchase records, and non-secret setup notes.

Do not destroy or reset anything needed to understand or recover the wallet.

For a complex multisignature setup, seek experienced technical help before broadcasting a migration transaction.

Frequently Asked Questions

Does the Firmware Installed Today Tell Me Whether My Seed Is Safe?

No. It tells you how the device behaves now. The relevant version is the firmware that created the current seed.

Does Updating to Fixed Firmware Repair the Old Seed?

No. Fixed firmware corrects future seed generation. It does not change existing private keys.

Does Moving the Same Seed to Another Hardware Wallet Fix It?

No. The same seed recreates the same private keys.

Does a Strong PIN Protect an Affected Seed?

A PIN protects local device access. It is not a BIP39 passphrase and does not change the wallet's cryptographic derivation.

Do 50 Dice Rolls Make the Seed Universally Safe?

No. Coinkite says at least 50 qualifying private rolls mean the seed is not considered at risk from this RNG issue alone. That does not audit every other part of the custody system.

Does a Passphrase Mean I Can Ignore the Advisory?

No. A strong, unique passphrase can add an independent barrier, but the affected seed remains affected. The vendor still recommends migration.

Is My Multisignature Wallet Automatically Safe?

No. The result depends on the threshold and how each signer was generated. Multisignature helps only when an attacker cannot satisfy the threshold with affected keys.

Should I Enter My Seed Into a Tool to Check It?

No. A legitimate exposure check does not require your recovery words. Anyone who receives the seed can control the wallet.

Related Reading

This checklist does not contain product recommendations or affiliate calls to action. Its purpose is to help users classify the seed before making a migration decision.

Update Log

August 3, 2026

  • Verified the current affected-model and fixed-firmware matrix against Coinkite's advisory.
  • Included separate Standard and Edge release-track checks.
  • Preserved Coinkite's current dice exception of at least 50 fair, independent, private rolls.
  • Separated passphrase risk reduction from seed repair.
  • Added multisignature threshold and BIP85 inheritance checks.

Primary Sources