Bitcoin Hardware Wallet Security: Lessons From the Coldcard Seed-Generation Flaw

Bitcoin Hardware Wallet Security: Lessons From the Coldcard Seed-Generation Flaw

2026/08/09 08:05:06

Custom Image

Coldcard Seed Generation Bug Exposes Weak Bitcoin Wallet Security

A March 2021 firmware change in Coinkite’s Coldcard Bitcoin hardware wallets rerouted seed generation away from the intended STM32 hardware random number generator to a deterministic software pseudorandom number generator. The error remained undetected until late July 2026, when attackers swept more than 1,000 Bitcoin addresses in coordinated waves, removing roughly 1,082 to 1,367 BTC valued between $70 million and $88 million at the time. Galaxy Research mapped the initial 41-minute sweep of 1,196 addresses on July 30 and later identified additional waves that expanded the observed total. Block’s engineering team and independent researchers traced the root cause to a preprocessor macro check that bound libngu to MicroPython’s Yasmarang fallback, which initialized from the chip’s unique ID and timer registers rather than fresh entropy.
 
Coinkite confirmed the issue across Mk2, Mk3, Mk4, Mk5, and Q models, released emergency firmware the following day, and instructed users to generate entirely new seeds because updating existing firmware cannot repair a compromised recovery phrase. The episode has renewed scrutiny of how hardware wallets source and verify entropy, the practical limits of open-source review, and the residual risks that persist even in air-gapped devices. The Coldcard seed-generation flaw demonstrates that hardware wallets remain dependent on correct firmware integration of entropy sources; a single configuration error lasting five years can reduce effective randomness far below the 128-bit target of a standard BIP-39 seed, enabling offline reconstruction of private keys and large-scale theft that no amount of physical isolation can prevent once the seed itself is weak.

How a 2021 Firmware Migration Disabled Coldcard’s Hardware RNG

In March 2021, Coinkite migrated Coldcard elliptic-curve operations to Bitcoin Core’s libsecp256k1 and introduced the libngu MicroPython library. Seed generation code switched from the board-specific ckcc.rng_bytes call, which correctly invoked the STM32 hardware true random number generator, to ngu.random.bytes. The production board configuration defined MICROPY_HW_ENABLE_RNG as zero because Coinkite supplied its own hardware-RNG wrapper. Libngu’s preprocessor check tested only whether the macro was defined, not whether its value was nonzero. As a result, the build succeeded and bound to MicroPython’s software Yasmarang fallback. That fallback initialized once, using the chip’s low 32 bits of unique ID XORed with SysTick and RTC time registers, and then produced a deterministic stream with no further entropy collection.
 
On Mk2 and Mk3 devices running versions 4.0.1 through 4.1.9, the path supplied essentially no cryptographic entropy. Later, Mk4, Mk5, and Q firmware mixed secure-element values but retained only four bytes after hashing and used them to reseed a single 32-bit state word, leaving roughly 72 bits of effective entropy against the intended 128 bits. The intended hardware RNG code remained present in the binary yet was never reached by the wallet-generation path. Existing code review confirmed the presence of the TRNG implementation but did not verify end-to-end symbol resolution from the seed-generation call site. The regression therefore persisted undetected for more than five years until active exploitation forced public disclosure.

Effect and Outcome

The practical consequence is that an attacker who can constrain or obtain the device UID, approximate boot timing, and prior RNG call history can regenerate candidate output streams offline. Each candidate can be expanded into a BIP-39 seed, derived into addresses, and checked against the public blockchain. For the most severely affected Mk3 devices, Coinkite estimated the effective search space at approximately 40 bits; Block’s analysis placed conditional ceilings well below cryptographic security levels for later models.
 
Hashing the weak output or applying the BIP-39 checksum cannot expand the number of possible seeds. Once a matching address is found, the corresponding private key controls every subsequent derivation, allowing complete drainage without physical access to the device. The attack surface therefore follows the recovery phrase itself, not the hardware that currently holds it. Restoring an affected seed onto patched firmware or onto any other wallet simply transfers the same weak secret.

Galaxy Research Maps the July 30 Sweep and Subsequent Waves

On July 30, 2026, an unidentified operator drained 1,196 Bitcoin addresses in a 41-minute window, removing 1,082.65 BTC valued at approximately $70.2 million. Galaxy Research identified the cluster through a distinctive fee rate of 30 sat/vB and the absence of change outputs, patterns that stood out against normal on-chain activity. The firm later documented two additional waves that raised the cumulative observed total to 1,367.05 BTC across 4,585 addresses, equivalent to roughly $88.6 million at prevailing prices. Galaxy cautioned that on-chain heuristics alone do not computationally prove every address originated from weak Coldcard entropy, yet the temporal clustering and technical linkage supplied by Block’s root-cause analysis made the connection highly probable.
 
The firm reported approximately 600 suspected attacker-controlled addresses to investigators and compliance services. No public reconstruction of a specific victim seed has been published, yet the scale of the sweeps demonstrated that the reduced entropy was sufficient for practical offline enumeration once the necessary device-state constraints were known or approximated. The speed of the first wave underscores that the vulnerability required no real-time interaction with the physical wallets. Once candidate seeds could be generated and validated against known funded addresses, the operator simply signed and broadcast transactions.
 
Subsequent waves continued after Coinkite’s advisory, indicating that not every holder had completed migration. Galaxy noted that the transaction pattern identifies the operator more than the theft itself, because a legitimate owner consolidating coins can produce identical on-chain signatures. The absence of prior activity sharing the same fee and change characteristics in the preceding thirty days strengthened the attribution to a single campaign rather than organic user behavior. The incident therefore illustrates both the power of blockchain analytics for rapid detection and the limits of those tools when the underlying cryptographic weakness originates offline.

Coinkite’s Emergency Response and Firmware Hotfixes

Coinkite issued its first public advisory on July 31, 2026, and expanded the scope the following day after further analysis. Fixed firmware versions were released for every affected track: 4.2.0 for Mk2 and Mk3, 5.6.0 for standard Mk4 and Mk5, 1.5.0Q for standard Q, and corresponding Edge builds 6.6.0X and 6.6.0QX. The company halted shipments of vulnerable stock and destroyed remaining inventory. Official guidance stressed that installing the new firmware does not repair an existing seed; a completely new seed must be generated on the patched device, and funds must be migrated after verification of the new backup and receiving address.
 
Coinkite estimated effective entropy at roughly 40 bits for affected Mk3 seeds and about 72 bits for pre-fix Mk4, Mk5, and Q seeds. The advisory explicitly exempted seeds created with at least 50 fair, independent, private dice rolls, because the dice contribution alone supplied the required 128 bits and was hashed together with the device output. Strong, unique BIP-39 passphrases were acknowledged as an additional barrier that prevents an attacker who recovers only the seed words from reaching the funds, yet the company still recommended full migration because the underlying seed remains weak.
 
Migration instructions emphasized calm sequential verification: confirm the fixed firmware version, generate the new seed, record and check the backup and fingerprint, send a small test transaction, then move the remainder while retaining the old backup until confirmation. Users whose only device was an Mk2 or Mk3 were given a careful single-device procedure that alternates between the old and new seeds. Coinkite also noted that TAPSIGNER, OPENDIME, and SATSCARD products use separate codebases and remain unaffected. The response demonstrated both the advantages of an open-source firmware model that allowed rapid patching and the practical difficulty of communicating urgency to a dispersed user base that may have generated seeds years earlier and then left the devices offline.

Entropy Estimates and Why 40 or 72 Bits Fall Short of BIP-39 Targets

A standard 12-word BIP-39 seed is designed to provide 128 bits of security. When the underlying entropy source collapses to approximately 40 bits on Mk3 devices or 72 bits on later models, the combinatorial space becomes searchable with modern computational resources. Block’s analysis showed that the MicroPython Yasmarang fallback, once initialized from fixed or constrained values, produces a fully deterministic stream. On Mk4 and later devices, the secure-element contribution is reduced to a 32-bit reseed of a single state word; subsequent outputs remain within a family of at most 2^32 streams for any fixed prior state and call history.
 
Deterministic hashing of that output cannot enlarge the family. Consequently, an attacker who obtains or approximates the necessary initialization parameters can enumerate candidates offline, derive the corresponding addresses, and match them against the public UTXO set. The cost is dominated by address derivation rather than pure random guessing, yet it remains feasible at the observed scale of theft. Coinkite’s preliminary figures align with independent assessments that the residual entropy is insufficient for long-term self-custody of significant balances.
 
The gap is not theoretical; the July 30 sweeps and follow-on waves provided empirical confirmation that the reduced space was already being exploited. Even the higher 72-bit estimate for later models leaves a margin far below the security level expected by users who chose hardware wallets precisely to avoid software-wallet entropy failures. The episode therefore supplies a concrete calibration point for future hardware-wallet design: any path that can silently fall back to a software PRNG seeded from a non-cryptographic device state must be rejected at build time, not merely reviewed after the fact.
 

Dice Rolls and Passphrases as Partial Mitigations

Coinkite’s advisory drew a clear distinction for seeds that incorporated at least 50 fair, independent, private dice rolls entered through the device’s dedicated interface. In those cases, the dice entropy alone met or exceeded the 128-bit target and was combined with the weak device output before the final seed words were displayed. Provided the rolls were never recorded or observed, the resulting seed is considered outside the scope of the RNG flaw. Fewer than 50 rolls, or any uncertainty about the number or privacy of the rolls, returns the seed to the at-risk category.
 
A strong, unique BIP-39 passphrase creates an independent wallet that cannot be reached from the seed words alone; an attacker must also recover the passphrase. Short, common, or reused passphrases do not qualify. Even when a strong passphrase is present, Coinkite recommended eventual migration because the underlying seed remains cryptographically weak and the passphrase itself becomes a single point of failure if ever exposed. These mitigations illustrate the value of layered defenses yet also their incompleteness. Dice rolls require disciplined physical procedures that many users never performed.
 
Passphrases demand careful separate backup and exact recall; a single typographical error produces a different, empty wallet. Neither measure restores the entropy that the firmware failed to supply, and neither protects advanced device features that continue to rely on the same weakened random-number path. Users who relied solely on the device’s default seed generation therefore faced the full impact of the reduced search space, while those who had already adopted supplemental entropy or passphrases gained time but not permanent safety.

Multisignature Setups and the Limits of Shared Risk

When every key in a multisignature quorum is generated on an affected Coldcard, the entire policy becomes spendable by an attacker who recovers the weak seeds. A 2-of-3 arrangement in which two of the three seeds originate from vulnerable firmware still allows the attacker to meet the threshold once those two seeds are known. Only configurations that retain at least one strong external key outside the affected set preserve security. Liana and other miniscript-based wallets introduce additional path considerations: a primary path that can be satisfied solely by weak Coldcard keys is immediately spendable, while a recovery path gated by a timelock remains protected only while the lock is active. Spending a SegWit wallet reveals the full descriptor on the first transaction, potentially allowing reconstruction of every address if all keys are weak.
 
Taproot confines the revelation to the used path, limiting blast radius, yet still exposes the weak keys that participate in that path. The practical lesson is that hardware diversity and independent entropy sources remain essential even inside multisignature schemes. Relying on multiple devices of the same model and firmware generation concentrates risk rather than distributing it. Users who mixed Coldcard keys with keys from other vendors or with dice-generated seeds retained partial protection; those who standardized on a single vulnerable product line discovered that the quorum threshold offered no defense once the entropy failure was exploited. The incident therefore reinforces long-standing recommendations for heterogeneous key sources while demonstrating that the recommendation is not merely theoretical.

Open-Source Review Failures and the Role of AI in Discovery

Coldcard firmware has long been published under an open-source license, enabling independent inspection. The RNG integration error nevertheless survived multiple release cycles and external scrutiny. Existing reviews verified that the intended hardware-RNG implementation existed in the binary yet did not confirm that the wallet-generation call site actually reached that implementation rather than the MicroPython fallback. The preprocessor guard used #ifndef rather than a value check, allowing a zero definition to pass silently. Coinkite noted that even recent AI-assisted code review performed by the company itself failed to surface the issue, while the attackers or the researchers who first identified the weakness may have benefited from similar tools. The episode therefore highlights a persistent gap between the presence of source code and the verification of runtime behavior across submodule boundaries.
 
The five-year latency also illustrates the difficulty of detecting silent entropy failures. Unlike buffer overflows or signature bugs that produce immediate crashes or invalid signatures, a weak PRNG continues to generate plausible-looking seeds that pass internal consistency checks. Only later offline enumeration against the blockchain reveals the deficiency. Future review processes will need explicit end-to-end entropy audits that force the build system to reject any fallback path and that measure the statistical quality of output under controlled conditions. Open source remains a necessary condition for trust, yet the Coldcard case shows it is not a sufficient one without targeted verification of the most security-critical code paths.

Migration Practicalities and the Risk of Rushed Transfers

Coinkite repeatedly stressed that hurried migration can create new loss vectors that exceed the original risk. Users were instructed to verify the fixed firmware version on-device, generate the new seed only after the update, record the backup and fingerprint offline, confirm a receive address on the device screen, and move a small test amount before the bulk of funds. Single-device owners faced additional steps of alternating between the old and new seeds while keeping both backups intact until final confirmation. Any error in the order of operations, any mistyped address, or any premature destruction of the old backup could permanently strand coins.
 
The company also warned against restoring an affected seed onto a new device or software wallet, because the weakness travels with the phrase itself. The volume of affected wallets and the continuing sweeps created time pressure that conflicted with the need for deliberate procedure. Many long-term holders had generated seeds years earlier, stored the devices offline, and retained only paper backups. Reconstructing the precise firmware version in use at generation time was not always straightforward. The advisory therefore balanced urgency with caution, urging immediate action for unprotected seeds while insisting on verification steps that prevent self-inflicted loss. The tension between speed and safety remains an inherent feature of any large-scale seed migration and will reappear in future hardware-wallet incidents.

Industry Context: Hardware Wallets After the Coldcard Incident

The Coldcard flaw arrives after earlier episodes of weak entropy in both software and hardware environments, including the Ill Bloom research that linked a separate software-wallet PRNG issue to more than $5 million in multi-chain losses. Hardware wallets were long marketed as the definitive solution to software entropy failures and malware. The 2026 events demonstrate that the protective boundary is only as strong as the firmware that implements the entropy path. Competitors that rely on different secure elements, different random-number architectures, or different review processes have not been implicated, yet the broader market must now confront the possibility that similar integration errors could exist elsewhere. Demand for independent entropy measurement tools, formal verification of RNG call graphs, and standardized dice-rolls or external-entropy interfaces is likely to increase.
 
Self-custody advocates face a parallel challenge. The incident has already prompted public discussion of whether long-term holders should consider diversified storage, including regulated products, for a portion of their holdings. At the same time, the rapid release of fixed firmware and the transparency of the technical disclosures reaffirm the advantages of open hardware ecosystems that can respond in hours rather than months. The net effect is a more realistic calibration of risk rather than a wholesale rejection of hardware wallets. Users who treat the device as one component inside a layered security model that includes external entropy, passphrases, and multisignature diversity retain stronger protection than those who treat any single product as an absolute safeguard.

Lessons for Future Hardware Wallet Design

Build systems must enforce the presence of a verified hardware RNG at the exact call sites used for seed generation; a silent fallback to a software PRNG seeded from device metadata is unacceptable. Preprocessor checks should test the enabled state of entropy features rather than mere definition. Secure-element contributions should retain full entropy rather than being truncated to 32 bits before reseeding a weak state machine. End-to-end tests that measure the statistical quality of generated seeds under realistic boot conditions should become standard release criteria.
 
Documentation must make clear that firmware version at the moment of seed generation, not the version currently installed, determines exposure. Finally, user interfaces should surface entropy-source status and encourage or require supplemental dice or external entropy for high-value wallets. These design changes are incremental yet would have prevented the Coldcard regression and would reduce the probability of similar failures in other products.

Practical Steps for Current Coldcard Owners

Owners who generated seeds on Mk2 or Mk3 firmware 4.0.1–4.1.9, or on Mk4, Mk5, or Q firmware before the July 31 fixed releases, should treat the seeds as compromised unless they can confirm at least 50 private dice rolls or a strong unique passphrase. Install the appropriate fixed firmware from the official Coinkite download pages, generate a new seed on the updated device, verify the backup and fingerprint offline, confirm a receive address on the device screen, send a small test transaction, and only then migrate the remaining balance.
 
Retain the old backup until the new wallet shows the full confirmed amount. Users who never generated a seed on an affected device but who imported an affected seed into another wallet must still migrate, because the weakness resides in the phrase. Multisignature participants should evaluate each key independently according to its generation device and firmware. The official advisory and the technical backgrounder remain the authoritative references for model-specific instructions.

Broader Implications for Bitcoin Self-Custody Practices

The Coldcard episode reinforces that self-custody is a continuous process rather than a one-time purchase of hardware. Entropy quality, firmware provenance, backup verification, and key diversity must be revisited periodically. On-chain analytics can detect large-scale exploitation rapidly, yet individual holders still bear responsibility for monitoring official channels and acting on advisories. The market for independent security audits of hardware-wallet firmware is likely to expand, as is demand for tools that allow users to measure the effective entropy of their own seeds without exposing them.
 
At the same time, the incident does not invalidate the core value of offline key storage; it simply demonstrates that the offline boundary must be complemented by verified cryptographic strength at the moment of key generation. Holders who combine patched hardware, supplemental entropy, passphrases, and multisignature arrangements continue to control their own keys with a higher degree of assurance than those who rely on any single layer.
 
KuCoin is celebrating its 9th anniversary with a special platform campaign filled with exclusive rewards, trading activities, and limited-time offers. Don’t miss the chance to participate and enjoy the benefits as the exchange marks nine years of growth and innovation. Visit the official campaign page now:
 

Custom Image

FAQs

What firmware versions of Coldcard are affected by the seed-generation flaw?

Mk2 and Mk3 devices running versions 4.0.1 through 4.1.9 inclusive generated seeds with approximately 40 bits of effective entropy. Mk4 and Mk5 devices before standard version 5.6.0 or Edge version 6.6.0X, and Q devices before standard version 1.5.0Q or Edge version 6.6.0QX, produced seeds with roughly 72 bits of entropy. Exposure is determined by the firmware present at the moment the seed was created, not by the version currently installed. Fixed releases correct new seed generation but cannot repair existing weak seeds. Official download pages list the corrected versions for each model and release track. Users who generated seeds outside these ranges, or those who used at least 50 private dice rolls, fall outside the primary risk category.
 

Does updating the firmware on an existing Coldcard protect an already-generated seed?

No. The vulnerability resides in the entropy used to create the seed words themselves. Installing fixed firmware changes only the generation path for future seeds. Restoring an affected recovery phrase onto patched firmware or onto any other wallet simply carries the same weak secret forward. The only reliable remediation is to generate an entirely new seed on fixed firmware and migrate funds after full verification of the new backup and receiving address. Coinkite’s advisory is explicit on this point and supplies step-by-step migration procedures for both multi-device and single-device scenarios.
 

Are seeds created with dice rolls still safe?

Seeds that incorporate at least 50 fair, independent, private dice rolls entered through the device’s official interface receive sufficient entropy from the dice contribution alone. The device hashes those rolls together with its own (weak) output, so the final seed meets or exceeds the 128-bit target provided the rolls were never observed or recorded. Fewer than 50 rolls, or any uncertainty about the number or privacy of the rolls, returns the seed to the at-risk category. Dice rolls do not protect advanced device features that continue to rely on the same random-number path, but they do protect the seed words themselves from this specific flaw.
 

How does a BIP-39 passphrase change the risk profile?

A strong, unique BIP-39 passphrase creates a separate wallet that cannot be derived from the seed words alone. An attacker who recovers only the weak seed still cannot reach the passphrase-protected funds without also discovering the passphrase. Short, common, patterned, or reused passphrases do not provide meaningful protection. Even with a strong passphrase, Coinkite recommends eventual migration because the underlying seed remains cryptographically deficient and the passphrase itself becomes a critical secret that must be backed up separately and never entered on untrusted devices. The passphrase is independent of the device PIN.
 

What should multisignature users do if some keys came from affected Coldcards?

Evaluate each key according to the device and firmware that generated it. If the number of affected keys meets or exceeds the spending threshold of any path, that path is at immediate risk. A 2-of-3 arrangement that includes two weak Coldcard keys can be spent by an attacker who recovers those two seeds. Recovery paths protected by active timelocks remain safer until the lock expires. Users should generate replacement keys on fixed firmware or on unaffected devices, construct a new multisignature policy, and migrate funds after verifying the new descriptor and addresses. Heterogeneous key sources reduce the chance that a single firmware flaw compromises the entire quorum.
 

Is the attack still ongoing, and how can holders monitor for further sweeps?

Galaxy Research observed multiple waves after the initial July 30 sweep and reported that activity continued while users migrated. On-chain patterns characterized by specific fee rates and change behavior can be watched through public explorers and analytics services, yet individual holders cannot rely solely on detection after the fact. The most effective protection is prompt migration of any unprotected seed. Official Coinkite channels and reputable research accounts remain the primary sources for updates on additional waves or newly identified address clusters.
 
Disclaimer: This content is for informational purposes only and does not constitute investment advice. Cryptocurrency investments carry risk. Please do your own research (DYOR).