How the Coldcard RNG Flaw Exposed $100M+ in Bitcoin: What Cold Storage Users Must Do Now

Cold storage is designed to remove private keys from the internet. The Coldcard incident demonstrated the uncomfortable distinction between offline signing and secure key generation.

According to TRM Labs, attackers drained approximately 1,816 BTC: reported at roughly $116 million at the time: from more than 5,200 addresses across multiple waves beginning July 30, 2026. The figures remain preliminary and may change as additional victims and transactions are identified.

The underlying issue was not a stolen device, malicious USB cable, or compromised exchange account. It was a firmware integration error that caused affected Coldcard devices to generate wallet secrets with substantially less randomness than intended.

The practical lesson is direct: updating firmware protects future seed generation. It does not repair a seed that was created on vulnerable firmware.

What the Coldcard RNG flaw actually did

Bitcoin wallet security begins with entropy: unpredictable data used to generate a private key or recovery seed.

A true random number generator, or TRNG, obtains randomness from physical processes. A pseudorandom number generator, or PRNG, produces a deterministic sequence from an initial state. A PRNG can be useful when its state is securely seeded. It becomes a security problem when the initial state is predictable.

In March 2021, Coldcard firmware moved wallet seed generation from a direct hardware-randomness path to ngu.random. According to Coinkite’s technical backgrounder and Block’s independent analysis, a build configuration error caused ngu.random to resolve to MicroPython’s deterministic Yasmarang fallback rather than the STM32 hardware TRNG.

The central mistake involved the setting MICROPY_HW_ENABLE_RNG.

Coldcard defined the setting as 0 because it provided its own hardware-RNG wrapper.

A related code path checked whether the macro was defined, not whether it was enabled.

The build therefore completed without an error.

The seed-generation function silently used a software PRNG.

The hardware RNG was present. The problem was that the critical code path was not reliably calling it. In security engineering, “the secure component exists somewhere in the binary” is not the same as “the sensitive operation reaches that component.” The difference is where the trouble lives.

Coinkite estimated approximately 40 bits of effective entropy for affected Mk2 and Mk3 devices and approximately 72 bits for affected Mk4, Mk5, and Q devices. Block’s analysis describes a limited 32-bit secure-element reseed on newer models. Those figures are materially below the 128-bit security target expected for a standard Bitcoin seed.

Hashing the output did not solve the problem. SHA-256 can condition or distribute existing data, but it cannot create entropy that was never present.

Why an “air-gapped” wallet could be attacked remotely

The attack did not require physical possession of the Coldcard.

Bitcoin addresses, public keys, transaction histories, and unspent transaction outputs are visible on the public ledger. If an attacker can enumerate the weakened seed space, derive candidate keys and addresses, and compare those addresses against the blockchain, the chain itself becomes a validation oracle.

The workflow is conceptually simple, even if technically demanding:

Reconstruct or enumerate candidate PRNG states.

Derive candidate BIP-39 seeds and Bitcoin keys.

Generate addresses across likely derivation paths.

Compare the candidates with funded public addresses.

Use the recovered private key to broadcast a competing spend.

The attacker does not need to “break Bitcoin.” The attacker only needs to find the private key corresponding to a predictable wallet.

This is why the difference is not online versus offline. It is unpredictable versus reproducible.

TRM reported that the stolen Bitcoin initially consolidated into a small number of destinations with limited onward movement. Galaxy Research reported an initial sweep of 1,082.65 BTC from 1,196 addresses over approximately 41 minutes. Those patterns matter because consolidation addresses, transaction timing, fee behavior, and subsequent service touchpoints can help investigators separate related theft waves from unrelated activity.

Which Coldcard users should assess exposure?

Exposure depends on the firmware that generated the seed: not necessarily the firmware currently installed and not the device holding the seed today.

Coinkite’s current advisory identifies these affected ranges:

Mk2 / Mk3: seed-generation firmware 4.0.1 through 4.1.9 is considered affected; fixed baseline 4.2.0 or later.

Mk4 / Mk5 standard: before 5.6.0; fixed baseline 5.6.0 or later.

Mk4 / Mk5 Edge: before 6.6.0X; fixed baseline 6.6.0X or later.

Q standard: before 1.5.0Q; fixed baseline 1.5.0Q or later.

Q Edge: before 6.6.0QX; fixed baseline 6.6.0QX or later.

The official Coinkite advisory also states that TAPSIGNER, OPENDIME, and SATSCARD use different codebases and are not affected by this specific bug.

A seed should be treated as potentially exposed when:

It was generated on affected firmware.

The device or firmware history cannot be established.

The seed was generated on an affected Coldcard and later imported into another wallet.

The wallet used a passphrase that was short, reused, patterned, or otherwise guessable.

The wallet is part of a multisignature policy in which affected keys alone can satisfy a spending threshold.

There is no forensic test that can inspect 12 or 24 words and determine whether they were generated with strong randomness. Secure and weak seeds look identical on paper. Provenance is the relevant evidence.

Dice and passphrase exceptions

Coinkite identifies two circumstances that may reduce exposure:

At least 50 fair, independent, private dice rolls were incorporated into the seed.

The wallet is protected by a strong, unique BIP-39 passphrase.

These are not interchangeable safeguards.

A Coldcard PIN is not a BIP-39 passphrase. A memorable phrase is not necessarily a strong phrase. A passphrase that appears nowhere else and was generated with sufficient randomness can add an independent barrier; a familiar quotation or reused password may not.

Even where the dice or passphrase exception appears to apply, migration remains the conservative long-term response. The goal is not merely to avoid the currently known attack. It is to retire a seed whose generation process cannot be treated as dependable.

What cold-storage users should do

1. Establish the seed’s history

Record, without exposing the seed phrase:

Device model.

Firmware version used when the seed was created.

Approximate seed-generation date.

Whether dice rolls were added, how many, and whether they were private.

Whether a BIP-39 passphrase was used.

Wallet fingerprint, extended public key, descriptors, and derivation paths.

All known receiving addresses and transaction hashes.

Do not enter the seed into a website, support form, messaging application, or “recovery” tool. Anyone requesting the words is requesting control of the wallet.

2. Install the fixed firmware before generating a replacement

Do not generate a replacement seed on an affected firmware version. Follow the model-specific instructions in Coinkite’s advisory and verify the installed version directly on the device.

Firmware updates prevent new weak seeds. They do not alter the entropy of an existing seed.

3. Create and verify a new wallet

Generate a new seed on fixed firmware or another appropriately reviewed signing device. Then:

Record the new backup on a durable medium.

Confirm the wallet fingerprint.

Verify a new receive address on the device screen.

Restore or test the backup before funding it.

Send a small test transaction.

Confirm receipt and control of the test output.

Move the remaining funds only after the test succeeds.

Keep the old backup until the migration is complete and confirmed. It may be compromised, but it remains necessary to control funds that have not yet moved.

Multisignature users should map the policy before broadcasting. The relevant question is not simply, “Did one Coldcard participate?” It is, “Can an attacker satisfy any active spending path using the affected keys?” A diverse multisignature arrangement can reduce dependence on one vendor’s implementation, but only when the threshold and key origins are properly documented.

4. Review derived and adjacent secrets

The investigation should not stop at the primary Bitcoin balance.

Assess whether the affected seed was used to derive:

BIP-85 child seeds.

Lightning wallet material.

Nostr keys.

Passwords.

Duress wallets.

Seed-XOR components.

Other application credentials.

The precise impact depends on the feature and implementation. The strategic point is simple: a compromised master seed can contaminate more than one address set.

If Bitcoin has already moved

If an unexpected outbound transaction appears, preserve evidence before attempting to interpret it.

Create an incident package containing:

Source addresses and transaction hashes.

Block heights, timestamps, and confirmation data.

Device model and firmware history.

Wallet fingerprints and derivation paths.

Screenshots or exports showing the original balance.

Exchange, custody, or service records connected to the wallet.

Communications concerning the original wallet setup or migration.

Then map the movement:

Where did the stolen Bitcoin consolidate?

Were outputs split into peel chains?

Did funds reach an exchange, broker, mixer, bridge, or OTC service?

Which addresses appear operationally related?

What service touchpoints create a realistic preservation target?

Are the transactions still unconfirmed, or have they achieved finality?

That is the difference between “the coins disappeared” and a usable investigative record.

A professional crypto fraud investigation may combine cryptocurrency tracing with traditional evidence collection, attribution analysis, and preservation planning. In a stolen crypto recovery matter, the objective is not to promise a result. It is to identify the asset path, document the evidence, and support counsel, law enforcement, insurers, or financial institutions with a defensible record.

StonePath’s blockchain investigation methodology reflects that distinction: the blockchain is not the entire case, but it is often the most durable starting point. For teams that need to trace a Bitcoin transaction, every hash, address relationship, timing marker, and service interaction should be preserved with the same discipline applied to conventional financial evidence. See our sample report for the level of documentation involved.

The larger security lesson

The Coldcard incident is not evidence that cold storage has failed as a concept. It is evidence that custody security is a system, not a product label.

The system includes:

Hardware design.

Firmware build configuration.

Entropy sources.

Code review and testing.

Backup procedures.

Wallet policy.

Multisignature diversity.

Incident monitoring.

Evidence preservation.

Open-source code and audits improve transparency, but neither is a guarantee by itself. The relevant audit question is not only, “Can we see the source?” It is also, “Can we demonstrate that the production binary reaches the intended security boundary?”

For cold-storage users, the immediate task is to establish seed provenance, migrate where necessary, and preserve evidence of any loss. For institutions and legal teams, the longer-term task is to document key-generation assumptions, vendor dependencies, signing policies, and response procedures before an incident turns those assumptions into exhibits.