Assessing your exposure
Firmware at generation, dice workflow, passphrase generation and threshold structure are the facts that change the assessment.
No code. Written to be actionable.
This incident concerns mnemonic generation, not every operation performed by an affected device. The relevant firmware is the version running when the words were created. Installing an update later does not change an existing mnemonic.
Decision path
flowchart TD
START(["Where did the mnemonic come from?"])
START -->|"imported or generated elsewhere"| PROV{"Generation method and provenance independently verified?"}
PROV -->|"yes, outside the affected path"| OUT["Not affected by this generator"]
PROV -->|"no or unknown"| ORIGIN["Assess the original generation method"]
START -->|"generated on a COLDCARD"| FW{"Firmware used at generation"}
FW -->|"before affected range"| CLEAN["Not affected by this incident"]
FW -->|"named vendor fix release"| FIX["Source fix verified; published binary not independently checked here"]
FW -->|"inside affected range or unknown"| DICE{"Dice workflow"}
DICE -->|"pure dice, sufficient fair secret rolls"| PURE["Affected generator bypassed"]
DICE -->|"mixed dice"| MIX["Assess roll count and secrecy"]
DICE -->|"none or unknown"| HELD{"How are funds controlled?"}
MIX --> HELD
HELD -->|"single signature"| SINGLE["Assess passphrase and migrate"]
HELD -->|"threshold wallet"| THRESH["Count affected keys against threshold"]
THRESH -->|"below threshold"| BELOW["Affected keys alone cannot sign
rotate them"]
THRESH -->|"at or above threshold"| PUB["Check script, descriptor and
public-key exposure before moving"] The branches identify which technical question comes next. They are not a substitute for checking the model-specific firmware range.
Affected generation ranges
| Model | Not affected | Affected | Named vendor fix release |
|---|---|---|---|
| Mk1 | all published firmware | none identified † | not applicable |
| Mk2 | v3.2.2 or earlier | v4.0.0 to v4.1.9 † | v4.2.0named by the vendor for Mk2 and Mk3; binary not independently checked here |
| Mk3 | v3.2.2 or earlier | v4.0.0 to v4.1.9 † | v4.2.0published binary not independently checked here |
| Mk4 | not before its affected line | v5.0.0 to v5.5.1 † | v5.6.0published binary not independently checked here |
| Mk5 | not before launch | v5.5.0 to v5.5.1 † | v5.6.0published binary not independently checked here |
| Q | none in the published release history before the fix | v0.0.3Q to v1.4.1Q † | v1.5.0Qpublished binary not independently checked here |
†
Coinkite publishes a narrower lower bound for Mk2 and Mk3. Its Mk3
advisory and technical backgrounder, in the versions held here as of
2 August 2026, give the affected range as
v4.0.1 to v4.1.9,
rather than from v4.0.0. Neither boundary is a
typographical slip. This site classifies v4.0.0 as affected because its release commit 910e306e contains the affected generation path, its pinned libngu revision carries the guard defect, and the signed-release record published by Coinkite lists the 17 March 2021 image. What the record does not settle is how widely v4.0.0 was installed during the twelve days before v4.0.1 on 29 March 2021. Chain analysis published by Galaxy Research on 1 August 2026 reports that no coin drained in its first three sweep waves was created before roughly block 674,951 on 17 March 2021, which is the v4.0.0 release date rather than the 29 March v4.0.1 date, so it corroborates a March 2021 onset without settling which of the two releases marks the boundary. The
firmware timeline sets out the release commit, the pinned libngu revision, the
signed-release entry and the limits on that chain analysis; the
captured advisory carries the vendor wording.
What changes the response
An affected mnemonic with no independently generated secret protecting the spend
- Single-signature wallet without a uniformly generated BIP39 passphrase
- Threshold wallet where affected key targets meet the threshold and the complete script, descriptor or equivalent construction data is exposed
- Generation on affected firmware is established, but dice use cannot be established
Follow the vendor advisory and prepare a migration to a newly generated mnemonic. For a single-signature wallet, the ordered steps are on moving funds from an affected seed. For threshold wallets, review the script-reveal issue before broadcasting.
A separate source of uncertainty or a hidden script may change the search
- Dice were mixed into an affected generated seed
- A uniformly generated BIP39 passphrase is in use
- A threshold wallet has not revealed its script or descriptor
- The mnemonic was imported, but its original generation method or provenance cannot be independently verified
Record the actual roll count, passphrase generation method and descriptor custody. The detailed pages state the assumptions rather than assigning a universal deadline: dice, passphrases, multisig thresholds, and the candidate-space estimator for the published scenarios behind each figure.
The mnemonic did not depend on the affected path
- Generated on a pre-affected firmware release identified in the table
- Imported from a source whose generation method and provenance were independently verified as outside the affected path
- Generated through the pure-dice path with sufficient fair, independent and undisclosed rolls
This conclusion is limited to the predictable-generator incident. It is not a general security assessment of the wallet or backup process.
Coinkite separately reports that TAPSIGNER, OPENDIME and SATSCARD use different codebases and are not affected. Those codebases have not been independently assessed by this archive.
How the mitigations differ
| Mitigation | Where it acts | Qualification |
|---|---|---|
| Pure dice | instead of device RNG | The pure path starts from the roll string and bypasses the affected generator. Its strength depends on enough fair, independent and secret rolls. A 12-word result caps usable entropy at 128 bits. |
| Mixed dice | after device RNG output | The affected output is still a prefix. Unpredictable rolls add a separate search term, but the mixed path enforces no roll minimum. |
| BIP39 passphrase | after mnemonic generation | Adds an offline search whose strength depends on the generation method and on whether the mnemonic is already known. It does not repair the mnemonic. |
| Threshold wallet | at authorisation | Affected keys below threshold are insufficient by themselves. At or above threshold, script and public-key exposure determine whether keys can be tested independently. |
Checks that do not require recovery material
- Firmware at generation. Use the device model, setup date, release record and any retained firmware notes.
- Dice workflow and roll count. Distinguish pure-dice generation from adding dice to already generated words.
- Passphrase generation method. Length alone does not establish randomness.
- Threshold and descriptor custody. Count affected keys on each spending path and determine whether public keys or descriptors have been exposed.
- What else came from the same seed. BIP85 children, seed XOR shares, device-generated paper wallets and retained backups carry the same generation history. What else is affected lists the call sites and what each one does or does not settle.
Once the generation path is classified, the response is wallet-specific. Single-signature owners can follow the ordered steps on moving funds from an affected seed. Threshold wallets have a separate first-spend problem, set out on migrating a threshold wallet. Neither page assigns a universal deadline; the published candidate-space scenarios that bound the question are compared in the estimator.