COLDCARD RNG Incident (2026) refers to the incident disclosed in July 2026 in which a software error weakened seed generation. A seed is the secret starting point from which a wallet derives its keys; RNG means random-number generator. Assessing the risk requires knowing how the seed was created and which firmware was running then. This was not a failure of Bitcoin’s rules or a remote takeover of the device.
Coinkite and Block published their initial analyses on July 30, 2026 after reports of losses. According to the manufacturer, attackers did not need control of someone else’s device: they could reproduce weakly generated secrets and obtain the corresponding private keys, which authorize transfers. Keeping the wallet offline was therefore not enough. This account of the incident does not establish the cause of every individual loss; the device’s brand alone cannot do that. [2] [3]
The wallet was meant to use a hardware source of randomness, called a TRNG. After the libNgU library was integrated, however, ngu.random.bytes reached MicroPython’s rng_get function and its Yasmarang software generator. The wrong components were connected when the program was built. MICROPY_HW_ENABLE_RNG was set to 0, while #ifndef checked only whether that setting existed, not its value. The correct hardware code could therefore be present in the file without being used to create seeds. This was neither a chip failure nor an intentional emergency mode. [1]
An attacker benefits when a secret comes from a smaller set of possibilities. Here the program’s state depended on device data, timers and previous calls. For Mk4, Mk5 and Q, Block describes an additional state refresh limited to 32 bits: at most 2^32 distinct output sequences with the remainder fixed. Coinkite’s preliminary estimates put total entropy, the amount of uncertainty, at about 40 bits for Mk2/Mk3 and 72 bits for newer models. The figures use different assumptions. They establish neither the cost of every attack nor that every wallet can be broken immediately. [3] [1]
The official advisory lists Mk2/Mk3 versions 4.0.1–4.1.9. Block’s initial analysis includes 4.0.0 and the change in March 2021. The sources therefore differ on the starting boundary; guessing is not a sound way to resolve that uncertainty. When the seed’s origin is unclear, the migration guide recommends treating the wallet as affected. Mk4/Mk5 and Q were also affected before their respective firmware tracks were fixed. The original statement about all production versions does not describe later corrected releases. [2] [3] [5]
The first fixed releases are Mk2/Mk3 4.2.0, Mk4/Mk5 Standard 5.6.0, Q Standard 1.5.0Q, Mk4/Mk5 Edge 6.6.0X and Q Edge 6.6.0QX. Standard and Edge are separate tracks; a larger number on another track proves nothing by itself. At this review, the manufacturer recommends Standard 5.6.3 for Mk4/Mk5 and 1.5.3Q for Q. Before installing, check the current official page, file hash and release signature. A hash fingerprints the contents; a signature helps verify their origin. Even a correctly installed update does not change an existing seed. [4]
Imagine restoring a weakly generated seed on a new device. The device has changed, but the secret has not. Cloning and transferring a wallet have the same limitation. Hashing, which calculates a fingerprint of data, cannot add possible inputs; BIP39 Checksum helps detect errors in the words, not supply missing randomness. Conversely, a seed securely created elsewhere is not weakened by this particular flaw merely by being imported into a COLDCARD. Its origin is what matters. [3] [5]
The manufacturer gives an exception for at least 50 independent rolls of a fair die entered through the original Add Dice Rolls feature. Their sequence must never have been recorded or exposed, and the wallet must use the final words produced after adding the rolls. With fewer rolls or uncertainty, it recommends migration. BIP39 Passphrase is a different measure: an additional secret text that, together with the seed, determines another wallet. A strong, unique passphrase puts another barrier in an attacker’s way but does not repair the seed; the manufacturer recommends migration for its users too. A PIN only protects access to the device. Today’s rules for new seeds are distinct from this historical exception. [2]
First verify that you have a usable backup of the original wallet. Following the migration guide, create a genuinely new seed on fixed firmware and verify its backup. Check the fingerprint, a short wallet identifier, and the receiving address on the device’s screen. Send a small test amount; move the remainder only after verifying the destination and receipt. Include every funded account, passphrase wallet, derived wallet and multisig arrangement. Keep the old backup until the entire move is confirmed. If anything fails to match, send or erase nothing. Never enter recovery secrets into a web form. [5]
Multisig requires a specified number of signatures from multiple keys to make a transfer. If an attacker obtains enough keys to meet that rule, the protection is no longer sufficient. Assess the remaining keys, prepare and verify a new signing policy on the device, and transfer the funds to it. Block also describes other uses of the same generator: standalone Paper Wallet keys and some temporary encryption keys. The impact depends on their specific use and the information available to an attacker; it is not the same for every feature. [3] [5]
The status page lists a hardware-generator test on an actual Mk4, source-code review and an independent rebuild of a specific fix. Those checks help validate the described mechanism, not establish the safety of every released file. Current Standard firmware also requires the user to contribute randomness when creating a new seed. Earlier advice saying that this was always optional is therefore not the current procedure for that track. The page records remediation as it develops; it still describes a separate detailed technical account of the causes as being prepared. [4]
Updated device, original problem
An owner created a seed on Mk3 4.1.9 without adding personal dice rolls. They install 4.2.0 and restore the same words on another device, but still use the original secret. Following the migration guide means creating a new seed on fixed firmware, checking its backup and address, and trying a small transfer. Only then do they move the remaining funds. They retain the old backup until the whole move is confirmed.
For the clearest picture, read this entry together with Cryptographic Entropy, Deterministic RNG, Seed Generation, BIP39 checksum, BIP39 passphrase, Dice Roll Entropy.
01Is buying a new device enough?+
No, if you restore the same affected seed on it. New hardware does not change how the secret was originally created. The procedure depends on the seed’s origin and the precise independent-dice exception. For an affected seed, the issue is moving to a new wallet, not merely replacing the device.
02Does 32 bits mean an equally easy attack on every model?+
No. In Block’s analysis it concerns the additional change to the generator’s state with the rest of the state and call history fixed. Unknown device data or timing changes the attacker’s task. The figure is neither a universal measurement of attack speed nor a guarantee that a particular seed is safe.