The COLDCARD alert published in late July 2026 cannot be reduced to “a seed with slightly less randomness.” It reveals a much more instructive failure chain: an API change, a disabled hardware generator, a non-cryptographic pseudorandom fallback, a reseed truncated to 32 bits on newer models and tests capable of detecting zeroes — but not predictability.
The result was deceptive: perfectly valid BIP-39 words, a functioning wallet and outputs that looked random, while the real space of possible secrets could be significantly smaller than expected.
Operational summary
For users, the practical conclusions remain straightforward:
- seeds generated on affected firmware should be treated as exposed under the criteria of the official advisory;
- installing corrected firmware protects future generation but does not repair an existing seed;
- a strong BIP-39 passphrase reduces immediate exposure without correcting the initial weakness;
- at least 50 private, independent dice rolls that were correctly incorporated can supply 128 bits of entropy independently from the faulty generator;
- migration should be methodical: a new healthy seed, verified backup, address checked on-screen, test transaction and only then the remaining balance.
The official Coinkite advisory remains the reference for corrected versions and user migration guidance. The Block Engineering technical analysis provides the detailed explanation of the software path.
The starting point: an API change in 2021
According to Block’s analysis, older Mk2 and Mk3 firmware obtained bytes directly from the microcontroller’s hardware random number generator through a dedicated function.
In March 2021, secret generation was redirected to a more generic interface, random.bytes(32), provided by a library called libngu. This kind of refactor can look harmless: a local function is replaced with a shared abstraction that is expected to provide the same service.
The problem was that this abstraction did not follow the expected hardware path in COLDCARD’s production configuration.
A compilation condition that checked the wrong property
The MicroPython configuration used by COLDCARD explicitly defined the hardware generator as disabled:
#define MICROPY_HW_ENABLE_RNG (0)
That choice was not necessarily an error by itself. COLDCARD had its own wrapper for accessing the hardware RNG.
The subtle issue came from how a dependency tested that configuration. It effectively checked whether the macro existed, rather than whether its value was enabled. A macro defined as 0 still exists from the preprocessor’s perspective.
The code could therefore compile without warning while taking, at runtime, a fallback path different from the expected hardware generator.
This is a classic integration failure: each component may appear coherent in isolation, but their combination creates an unexpected security behavior.
The Yasmarang fallback: variable does not mean unpredictable
When the hardware generator was unavailable, MicroPython used a pseudorandom generator called Yasmarang.
Yasmarang can produce a long byte stream that looks irregular. It was not designed as a cryptographically secure generator. If its initial state is known or sufficiently constrained, its outputs can be reproduced.
According to Block, that initial state depended in part on:
- part of the microcontroller’s unique identifier;
- the
SysTickcounter since boot; - RTC time and subsecond registers;
- the order and number of generator calls.
These values create variation. They do not guarantee cryptographic entropy. The identifier is fixed, counters are tied to boot timing, and several variables may be correlated or partly observable.
A second deterministic instance was then combined with the result. Combining two reproducible streams does not spontaneously create an independent randomness source.
Why hashing does not repair entropy
The result was then processed through SHA-256d before becoming the material used for seed generation.
A cryptographic hash converts an input into an output that appears uniform and is difficult to reverse directly. It does not increase the number of possible inputs.
If the generator can produce only N distinct states, the hash can produce, in this context, only N reachable results:
small space of possible states
↓ SHA-256d
outputs that look uniform
but remain limited to the same space
The BIP-39 checksum does not add entropy either. It helps detect some transcription errors. The BIP-39 specification expects 128 to 256 bits of initial entropy before adding the checksum.
A 12-word or 24-word sequence can therefore be syntactically perfect while being cryptographically weaker than expected.
Why the tests did not catch it
The existing tests mainly checked that the generator did not return the exact same value twice and that the output contained enough distinct bytes.
These controls detect a frozen generator, an all-zero output or an obviously broken source. They do not detect a deterministic generator that produces a different sequence on every call.
A predictable PRNG easily passes superficial variety tests. Detecting the issue would have required verifying the effective source of entropy, testing compilation configurations and reproducing outputs from controlled initial states.
One of the incident’s most important lessons is therefore: testing that numbers change is not the same as testing that they are unpredictable.
Two different vulnerability profiles
Mk2 and Mk3: a path without a genuine cryptographic contribution
For affected Mk2 and Mk3 devices, Block describes a path where no independent cryptographic entropy source meaningfully fed this generation process.
The search difficulty then depends on what an attacker knows: device identifier, boot window, clock state and call history. Block presents several theoretical models, ranging from very small spaces when some parameters are known to broader bounds when more uncertainty must be explored.
These estimates are not universal exploitation benchmarks. They nevertheless show that security no longer rested on the expected 128 or 256 bits of a healthy seed.
Coinkite officially identifies Mk2/Mk3 firmware 4.0.1 through 4.1.9 as affected. Block, however, places the vulnerable software-path change in public version 4.0.0. As a precaution, a seed generated under 4.0.0 should therefore also be treated as potentially affected, even though that version is not included in Coinkite’s official published range.
Mk4, Mk5 and Q: secure-element input, but a limited reseed
Newer models added data from their secure elements, so their defect was not identical to the Mk2/Mk3 case.
According to Block, those values were hashed, but only four bytes of the result — 32 bits — were passed to Yasmarang’s reseed function. That function changed a limited portion of the generator state instead of initializing a full cryptographic DRBG with all available entropy.
For a fixed deterministic state and call history, the secure contribution therefore distinguished at most 2^32 streams tied to that reseed. Counters and timings introduced other unknowns, but these should not be confused with independent, robust entropy bits.
Coinkite summarizes the Mk4, Mk5 and Q impact as roughly 72 bits of entropy instead of the expected 128. Block presents theoretical bounds that depend on the attacker model. The figures describe different angles and should not be treated as one guaranteed measurement of real exploitation cost.
How an address or XPUB becomes a validation oracle
An attacker does not need to recognize the correct words directly among millions of candidates.
Public wallet information can validate each hypothesis:
- reproduce one possible generator state;
- obtain a candidate seed;
- derive the corresponding keys, XPUB or addresses;
- compare the result with a known address or XPUB;
- retain the candidate when a match appears.
The computation can be performed offline. The blockchain, a previously used address or a watch-only wallet then provides the comparison point.
This explains the principle, not the exact cost of a real attack. Block notes that its initial results were not a complete, reproducible and universal benchmark against every affected device.
The issue may have extended beyond BIP-39 seeds
Block’s analysis identifies other features that used the same pseudorandom stream in certain versions:
- some paper-wallet private keys;
- generated masks for Seed XOR;
- temporary keys used by cloning or transfer features;
- Web2FA secrets;
- some passwords or secrets generated by the device;
- material used in certain HSM modes.
This does not mean every feature was exploited or had exactly the same risk profile. Exposure depends on the version, model, use case, additional secrets and the visibility of public information that can validate candidates.
The wider scope nevertheless explains why this incident is deeper than a word-display bug: trust in a shared randomness source propagates to every feature that consumes it.
Timeline of the regression
The timeline reconstructed by Block shows why this class of defect can remain unnoticed:
- January 2021: the problematic detection logic exists in the dependency;
- March 2021: COLDCARD secret generation is redirected through that interface;
- March 2022: the limited reseed mechanism is introduced for newer models;
- July 30, 2026: Block and Coinkite publish initial warnings after reports and an accelerated investigation;
- August 2026: corrected firmware is available for the affected models and release tracks.
The regression therefore remained visible in open-source code for several years. Open source makes auditing possible, but it does not guarantee immediate discovery. The relevant compilation path, dependencies and entropy assumptions still need to be examined.
What is confirmed and what remains to be established
| Level | Elements | |---|---| | Confirmed by Coinkite | Affected versions, corrected releases, impact on existing seeds, dice exception, passphrase role and migration process | | Detailed by Block | Fallback path, role of Yasmarang, 32-bit reseed, theoretical search models and other possible RNG consumers | | Not yet publicly established with final certainty | Exact number of exploited wallets, total losses attributable to the defect, practical cost for each model and the full scope of attacked features |
Coinkite still describes its advisory as an early analysis and says a formal technical review will follow. Until that final review and complete independent reproductions are available, exploitation and loss figures should be treated as estimates rather than definitively attributed facts.
Models and versions to treat as affected
| Model | Generation to treat as affected | Minimum corrected version | |---|---|---| | Mk2 / Mk3 | Coinkite: 4.0.1 through 4.1.9; also use caution for 4.0.0 based on Block’s analysis | 4.2.0 | | Mk4 / Mk5 Standard | Seed generated before the corrected release | 5.6.0 | | Q Standard | Seed generated before the corrected release | 1.5.0Q | | Mk4 / Mk5 Edge | Seed generated before the corrected release | 6.6.0X | | Q Edge | Seed generated before the corrected release | 6.6.0QX |
Standard and Edge are separate release tracks. According to Coinkite, TAPSIGNER, OPENDIME and SATSCARD are not affected because they use different codebases.
Why the update cannot repair an existing seed
The update changes how the next secret will be generated. It does not change keys already derived from an earlier seed.
Importing that seed into another hardware wallet does not strengthen it. Applying a more robust backup method does not strengthen it either. The original secret remains identical.
This is why GLOV SSS can protect and distribute the backup of a new healthy seed, but cannot repair a seed originally created with insufficient entropy. Splitting a weak secret creates better organization around the same weak secret.
Dice and passphrase: two different protections
Coinkite states that at least 50 fair, independent, private and unrecorded dice rolls, added to the final seed, supply at least 128 bits of entropy on their own. With 99 rolls or more, the contribution approaches 256 bits.
A strong and unique BIP-39 passphrase creates another barrier: even if the base seed is recovered, the attacker must still discover the passphrase corresponding to the funded wallet.
These protections should not be confused:
- dice improve seed entropy during creation;
- the passphrase derives a distinct wallet from the seed;
- the PIN protects local access to the device but does not add a secret to the BIP-39 wallet.
Coinkite nevertheless recommends that users protected by a strong passphrase migrate as soon as this can be completed without rushing.
Migrating without creating a second incident
Migration should reduce risk, not move it elsewhere:
- identify the model and the Standard or Edge release track;
- install corrected firmware from the official source and verify the displayed version;
- generate a new seed that is distinct from the old one;
- back up and verify the new seed before receiving funds;
- verify a receiving address directly on the hardware-wallet screen;
- send a small test transaction and confirm spending capability;
- transfer the remaining balance;
- retain the old backup until the entire migration is confirmed.
In a multisig, replacing one key generally requires creating a new policy or descriptor and moving funds. The quorum reduces risk only when it contains enough genuinely independent and healthy keys.
Our guide to migrating a potentially compromised wallet explains the operational checks in more detail.
Lessons for custody architecture
This incident does not demonstrate that self-custody has failed. It shows that trust does not disappear: it moves into firmware, hardware, dependencies, build processes and test quality.
A more resilient architecture can combine:
- several understood and verifiable entropy sources;
- precise documentation of the firmware used during key generation;
- multisig using genuinely diverse implementations and vendors;
- backups separated from the devices;
- periodic recovery tests;
- a written alert and migration procedure;
- a crypto security audit that examines the full architecture, not only the hardware-wallet model.
GLOV Secure works on this organizational and governance layer without holding funds or retaining client secrets.
Technical sources
To review a seed, multisig or wallet architecture after this alert, contact GLOV.