COLDCARD RNG incident: how weak entropy became an on-chain event
A developer-focused report connecting the public firmware root cause to reproducible on-chain evidence, without publishing seed-recovery tooling, victim addresses, or private material.
Direct answer
The incident traces to a firmware path where a disabled hardware RNG was still selected by a preprocessor check, allowing a deterministic fallback generator to influence seed creation. Newer devices added hardware material, but only a 32-bit derived value entered the reseed path. Firmware updates close the generation flaw; they do not strengthen seeds created earlier.
reported first-wave collector clusters
graph-linked source inputs in wave one
graph-linked source inputs in follow-on observations
primary technical advisories cited
The technical method, step by step
This is the public, defensible explanation of the failure chain. It is detailed enough for firmware and wallet developers to review the class of defect, but it stops before operational key recovery.
Configuration said “disabled”
The board configuration defined the RNG feature as zero. That expresses a disabled value, but the symbol still exists to the preprocessor.
The guard checked existence, not value
A conditional compiled the fallback path when the RNG symbol was defined, even when its value was zero. The linked rng_get implementation therefore resolved to a deterministic software generator instead of a hardware entropy source.
Observable device state seeded the fallback
The fallback initialization mixed identifiers and timer registers. These values can vary, but they are not equivalent to cryptographically independent entropy and can be constrained by device behavior and call order.
Hashing did not create missing entropy
Downstream hashing and BIP-39 checksum processing can distribute existing uncertainty; they cannot manufacture entropy that was absent from the generator state.
Newer devices truncated the reseed
On later devices, hardware RNG reads were hashed, but only four digest bytes were unpacked into the reseed value. That bounds the direct reseed contribution to 32 bits, subject to the wider execution context.
Public addresses become a validation oracle
An attacker who can enumerate plausible internal states can derive public keys or addresses and compare them with public blockchain data. This explains the risk model; it is not an end-to-end benchmark or a claim that every seed is equally recoverable.
The control-flow mismatch in four safe fragments
These fragments describe the root cause without providing a wallet-recovery loop.
#define MICROPY_HW_ENABLE_RNG (0)#ifndef MICROPY_HW_ENABLE_RNGpad = UID_low32 ^ SysTick->VALreseed = SHA256d(rng1 || rng2)[0:4]
Affected firmware and the action boundary
The matrix below follows Coinkite’s public advisory. Device owners should verify the current vendor guidance before acting because release channels may change.
| Device family | Affected range | Fixed release | What the fix means |
|---|---|---|---|
| Mk2 / Mk3 | 4.0.1 through 4.1.9 | 4.2.0 or later | New seed generation uses the corrected path; old seeds remain weak. |
| Mk4 / Mk5 | Standard releases before 5.6.0 | 5.6.0 or later | The corrected release prevents future generation through the affected path. |
| COLDCARD Q | Standard releases before 1.5.0Q | 1.5.0Q or later | Update first, then create and migrate to a new seed. |
| Edge channel | Before 6.6.0X / 6.6.0QX | 6.6.0X / 6.6.0QX or later | Use the fixed channel release appropriate to the device. |
A firmware update does not retroactively add entropy to an existing seed. The defensive action is a newly generated seed on fixed software followed by a verified migration.
What the public chain shows
We reproduced a bounded public snapshot from reported collector labels and Blockstream’s public address and transaction endpoints. The table is evidence of flow, not proof of operator identity and not a definitive victim or loss total.
Wave one linked source-input volume
1,082.58680432 BTC
Reproduced graph snapshot; labels are public incident reports, not identity attribution.
Follow-on linked source-input volume
76.09142381 BTC
Reproduced graph snapshot; labels are public incident reports, not identity attribution.
Publicly reported collector addresses
| Wave | First observed | Address | Total received at snapshot | Address tx count |
|---|---|---|---|---|
| Wave 1 | 2026-07-30 | bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 | 594.47727254 BTC | 506 |
| Wave 1 | 2026-07-30 | bc1qc779m8gec84k3t0ffvu0pps94zheht7lr7ueyn | 398.48587857 BTC | 492 |
| Wave 1 | 2026-07-30 | bc1qdaarag7729c2n4l2wnyt3hkhfpcs66n98z7uuh | 88.85045709 BTC | 101 |
| Wave 1 | 2026-07-30 | bc1qh0l7q0mca3ln7wsl9luwns0jc9jhgrtft025l4 | 0.77324382 BTC | 105 |
| Wave 2 | 2026-07-31 | bc1qsjrf5ze5tmulz7y2x4pc7qaex2a35sanp3rqlx | 45.90666052 BTC | 1217 |
| Wave 2 | 2026-08-07 | bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6 | 30.18478329 BTC | 96 |
“Total received” is an address statistic as observed on 12 August 2026. Do not add these balances to downstream consolidation outputs or describe the sum as confirmed theft.
Representative consolidation transactions
| Observed | Inputs | Single output | Transaction |
|---|---|---|---|
| 2026-07-30 01:43 UTC | 491 | 398.47573857 BTC | 14edd9ee8445… |
| 2026-07-30 01:43 UTC | 204 | 89.62327890 BTC | 4b50d61a3d6e… |
| 2026-07-30 01:51 UTC | 341 | 562.01962301 BTC | 0c6bf853a645… |
| 2026-07-31 09:22 UTC | 1212 | 45.90251994 BTC | ba119968ec4b… |
| 2026-08-07 03:35 UTC | 93 | 30.18461329 BTC | 93df0d26e08c… |
Reproducible on-chain methodology
- 01Start only from collector labels already published in incident reporting; exclude self-reported victim addresses from the public page.
- 02Query public address and transaction endpoints, preserving transaction IDs, confirmation times, input counts, output values, and the verification date.
- 03Recalculate BTC values from integer satoshis rather than formatted screenshots or market-price estimates.
- 04Deduplicate by transaction ID and classify source, first-stage, and second-stage nodes before aggregating.
- 05Never add a consolidation output to the source inputs that funded it; both describe the same flow at different stages.
- 06Treat graph labels as observed relationships. A blockchain path alone does not prove ownership, intent, device model, or legal responsibility.
Defensive reproduction, without real wallets
A separate local harness used 1,000 deterministic synthetic wallets to validate BIP-39 checksum handling, expected-address re-derivation, and test-vector uniqueness. All 1,000 synthetic vectors re-derived successfully and five bounded recovery smoke tests passed. The dataset contains no real wallet material and is not published because the objective is engineering validation, not operational recovery.
Important limits
- Neither the official source nor this report claims a universal end-to-end brute-force time.
- The 32-bit reseed observation is not automatically equivalent to exactly 32 bits of complete seed security; call history and fallback state still matter.
- Collector addresses can receive unrelated or later funds, so current address totals are not a frozen loss ledger.
- The public graph does not identify the actor and cannot independently prove every source input came from the same firmware defect.
- FRB Agent is not a Bitcoin hardware wallet and this report does not claim FRB prevents this incident class.
Defensive actions for potentially affected owners
Read the current Coinkite advisory and confirm the exact device and firmware channel.
Update to a fixed firmware release before generating replacement material.
Create a new seed using a corrected process; follow the vendor’s dice guidance if using manual entropy.
Move assets from all wallets derived from the affected seed, including passphrase-derived wallets, after verifying the new backup.
Do not post seed words, xprvs, private keys, or suspected victim addresses in support threads or public checkers.
Why execution developers should care
The incident is a reminder that “local” and “non-custodial” are architecture boundaries, not automatic proofs of safety. Entropy, signer firmware, key lifecycle, update provenance, simulation, and operator verification remain separate controls. FRB’s security pages document its own local-signing boundary; they do not substitute for wallet-firmware review.
Primary sources and live evidence
Sources were checked on 12 August 2026. Explorer state can change as addresses receive or spend funds.
Frequently asked questions
Does updating firmware repair an old seed?
No. The update corrects future seed generation. A seed created through the affected path must be replaced and funds migrated to addresses derived from new material.
Was this a remote exploit against the device?
The documented weakness is in seed generation. The public attack model uses constrained candidate state plus public blockchain data as a validation oracle; it does not require later remote control of the hardware wallet.
Does a 32-bit reseed mean every seed can be recovered instantly?
No. It bounds one contribution to the reseed path, but practical exploitability also depends on fallback state, call order, observations, derivation targets, and implementation details. No universal timing claim is made here.
Why publish collector addresses but not victim addresses?
Collectors are already public incident labels and help independent researchers verify consolidation flows. Victim addresses add privacy risk and are unnecessary for explaining the technical or graph methodology.
Why is recovery code omitted?
The page is intended to help developers audit entropy and help owners migrate safely. An executable seed-recovery pipeline would add misuse risk without improving the public root-cause evidence.