The Coldcard Seed Failure

How this report was put together

This report is a BTIX Research analytical reconstruction based on public technical material and attributable investigator reporting. BTIX Research did not independently discover the underlying vulnerability; our contribution is the reconstruction, confidence assessment, exposure analysis, migration guidance, detection logic and defensive recommendations. Confirmed, assessed and unknown claims are kept separate throughout the report.

Offline, and still guessable

Nothing was broken in Bitcoin, and nothing reached into anyone's device. The wallets failed at the one moment that cannot be repaired later: the instant the secret was created.

Coldcard firmware asked for randomness through a module named ngu.random. Because of how the build was configured, that request never reached the STM32 hardware generator on the board — it landed in Yasmarang, a deterministic algorithm MicroPython carries as a fallback for non-cryptographic use.

On Mk2 and Mk3 running version-4 firmware, nothing secret entered the pipeline at all; the Coinkite advisory puts effective strength there at roughly 40 bits against the 128 a 12-word mnemonic should carry. Later Mk4, Q and Mk5 firmware did pull material from the secure elements, but only four bytes survived — enough to reseed a single 32-bit state word, for about 72 bits. Hashing the output made it look fine. It could not make it unguessable, because a hash cannot invent possibilities absent from its input.

The regression entered wallet generation in March 2021 and shipped in version 4.0.0. Coinkite's affected range for Mk2/Mk3 runs 4.0.1 to 4.1.9; later hardware is affected if the seed predates standard 5.6.0 or Edge 6.6.0X on Mk4/Mk5, or standard 1.5.0Q or Edge 6.6.0QX on the Q. Exposure attaches to the seed, not the device: a firmware update leaves the old seed exactly as weak. Two exceptions exist — at least 50 fair, independent, private dice rolls mixed into generation, and a strong unique BIP-39 passphrase as an added barrier.

On the chain side, Galaxy Research puts confirmed losses at more than 1,778 BTC — roughly $112 million — from over 5,200 addresses across three proven waves and 41 smaller footprints. A candidate fourth wave of 638.5 BTC remains unconfirmed; including it would carry the total to 2,417 BTC, above $151 million. BTIX keeps those tiers apart. The sweep that drew the most attention ran 41 minutes on 30 July, 01:10:20 to 01:51:26 UTC, moving 1,082.65 BTC out of 1,195 addresses across blocks 960,183 to 960,191 — every transaction at 30 sat/vB, every source emptied without change.

The sweeps have since stopped — no confirmed activity since 6 August — not because the method failed but because the reachable population has largely been drained or migrated.

Five years between the commit and the sweep

The defect was quiet for five years. The sequence separates when the code changed, when the exposure widened, and when the money moved.

Two correct assumptions, one broken contract

Coldcard is a Bitcoin-only signer: keys stay on the device and PSBTs move over MicroSD, or QR on the Q. That removes several classes of host and network risk. It says nothing about whether the seed was unpredictable when it was made.

The board carried its own STM32 randomness wrapper, ckcc.rng_bytes. Because it existed, the build deliberately set MICROPY_HW_ENABLE_RNG to zero to switch off MicroPython's own hardware path. Block's published source analysis shows the crypto library then checked whether that macro was defined — with #ifndef — rather than whether its value was on. Finding it defined, it concluded a hardware TRNG was present and bound CHIP_TRNG_32() to rng_get(). MicroPython, reading the value, compiled rng_get() as the Yasmarang fallback.

Confirmed
The binary linked cleanly — no symbol missing, no test failed. The error was substitution, not absence: a cryptographic consumer silently wired to a deterministic producer. A check that asks for bytes, watches them change and rejects repeats passes this build without complaint.

Nobody violated their own assumptions

This is what makes the bug instructive rather than embarrassing. The firmware author disabled a redundant path. The library author checked for a macro that signals hardware capability. The runtime compiled the branch its configuration specified. Each behaved exactly as documented, and the integration of the three destroyed the only property that mattered — that wallet entropy must originate somewhere unpredictable.

Before the migration, generation filled a 32-byte buffer through rng_bytes, landing on the board's STM32 peripheral. After it, the same call became random.bytes(32), resolving to ngu.random.bytes. One line of routing separated a hardware source from a software imitation of one.

Four control gaps let it survive to production: a non-cryptographic generator inside a namespace called random, with nothing warning against using it for keys; no compile-time assertion on the macro's value rather than its existence; no end-to-end test of entropy provenance; and health checks that looked only for stuck or trivially repeating output — a bar Yasmarang clears comfortably.

Varying is not the same as secret

The fallback seeded itself from the low 32 bits of the MCU's unique ID, XORed with the SysTick counter, plus the real-time clock and its sub-second register. Those values move between boots, but movement is not secrecy. The UID is fixed metadata stamped into the chip, and the timing values sit inside ranges that manufacturing data, user behaviour, boot duration or enumeration can narrow considerably. Fix the starting state and the number of prior calls, and everything afterwards follows deterministically.

The library then XORed that stream against a second Yasmarang instance seeded from public constants — a step that adds nothing, since XOR only preserves uncertainty when at least one input carries some. Applying SHA256d changes how the bytes look; the number of possible outputs is still the number of possible inputs.

Confirmed
On Mk4, Q and Mk5, boot logic read material from two secure elements, hashed it, kept the first four bytes, read them as a 32-bit integer and passed that to ngu.random.reseed(n). That call overwrites one state word. It does not build a cryptographic DRBG, reset the fallback, or accept the rest of the digest. For a fixed fallback state and call history, Block bounds the number of securely distinguished streams at 2^32. Coinkite separately puts effective strength at roughly 40 bits on Mk2/Mk3 and about 72 bits on Mk4, Mk5 and Q. Block declines to publish a single practical figure at all, cautioning that a ceiling is not a security level. These numbers describe different models under different assumptions; collapsing them into one headline figure would misrepresent all three.

Twenty-four words of nothing

BIP-39 takes an initial block of entropy, appends a checksum, maps it to mnemonic words and stretches the result through PBKDF2-HMAC-SHA512 into a seed. BIP-32 grows a key tree from it. Both assume the first step was unpredictable, and neither can notice when it wasn't. The checksum catches a mistyped word; derivation turns one secret into millions of keys. Neither restores entropy that was never there.

A twelve-word mnemonic should start from 128 bits, a twenty-four-word mnemonic from 256. If the generator reaches only a much smaller family of candidates, that family is the real security level regardless of word count or hash width — exactly the distinction NIST SP 800-90B draws between an entropy source and a deterministic generator.

Dice matter because they enter from outside the broken path. Coinkite treats 50 to 98 fair, independent, private six-sided rolls as contributing at least 128 bits, and 99 or more as reaching roughly 256. The conditions carry weight: fair, genuinely independent, unobserved, and the seed in use must be the one produced after mixing. Fewer rolls do not qualify.

A BIP-39 passphrase does not repair the seed; it derives a different wallet from it, adding a dimension the attacker must also search. That helps only if the phrase is strong, unique and secret — it is not the device PIN, and it protects no wallet derived without it.

What an operator would have to do

Assessed
No public material describes the attacker's code, hardware, throughput, or how they obtained UID and timing constraints. What follows is a BTIX reconstruction from the mechanism — it shows the work is feasible, not how it was done.

The operator starts by bounding device state: plausible UID values or serial ranges, clock and sub-second positions, boot conditions, and how many random calls preceded the one that made the seed. They reimplement the Yasmarang state machine and whatever model-specific reseed applies. Each candidate output goes through the same SHA256d, BIP-39, BIP-32 and script-type derivations real wallet software would use, producing candidate addresses.

Those addresses are checked against a local chain index or UTXO set — here the public ledger becomes the attacker's oracle, confirming a correct guess without ever touching the victim. Transactions are then built to spend every UTXO found, with fees set high enough to confirm before anyone reacts.

For Mk2 and Mk3 on version 4, there is no secret input to defeat once the environment is pinned down. For later devices Block's model requires walking up to 2^32 reseed values per fixed fallback state and call history, averaging around 2^31 attempts — a statement about search-space size, not a published benchmark. Real cost swings widely with derivation paths, address types, gap limits and UID knowledge. What later analysis does show is that the sweeping was not indiscriminate: the recoverable population appears to have been surveyed first, the largest balances taken early.

1,778 BTC we can stand behind

The defining early event ran from 01:10:20 to 01:51:26 UTC on 30 July 2026 across blocks 960,183 to 960,191: 1,082.65 BTC out of 1,195 source addresses in 41 minutes, uniformly at 30 sat/vB, with no change outputs anywhere. One fee rate, one window, one construction pattern, at that scale, is a strong operational fingerprint — and it remains the largest proven wave.

According to Galaxy Research, the confirmed owner-attributed total stands at more than 1,778 BTC — around $112 million — at very high confidence, across three proven waves and 41 smaller footprints covering over 5,200 addresses. The candidate fourth wave of 638.5 BTC is carried separately, unconfirmed, and would lift the total to 2,417 BTC if it is ever attributed.

The confirmed address count fell from roughly 7,300 to just over 5,200 while confirmed losses rose. That is attribution tightening, not victims disappearing: more than 190 victims have been interviewed directly, and addresses counted on resemblance alone were dropped when they could not be tied to an owner.

The money has mostly not moved. Of the confirmed haul, 1,531 BTC still sits in attacker-controlled addresses untouched; roughly 246 BTC has moved since the theft, about 65% of it into CoinJoin rounds. Only 174.97 BTC can be followed to a final endpoint. That leaves an unusually wide window open for exchanges and law enforcement.

Limitation
BTIX Research does not publish attacker addresses. The complete corpus was not available to BTIX in an authoritative, machine-readable form, so we cannot independently reproduce the totals or offer exchange attribution we would defend. This is a statement about BTIX reach, not doubt about the events.

Assessed
The absence of confirmed activity after 6 August should not be read as the vulnerability being closed: the defect is unchanged and every un-migrated seed remains recoverable. Dormancy is a supply problem for the attacker, not a fix.

A fingerprint of the tool, not of the hand

The shape is many-to-few: victim UTXOs spent in quick succession by reusable transaction logic, converging on a much smaller set of destinations. The uniform fee and absent change make the pattern legible, because unrelated wallet activity rarely shares a narrow window and an identical template at that volume.

That legibility is temporary — fee policy is a property of software, and software changes. When later waves look different, three explanations fit equally well: the tooling evolved, the operator tightened their tradecraft, or a second party picked up the same public vulnerability. The evidence does not choose between them, and BTIX does not either.

Reliable flow work is layered: seed provenance, proximity in time and block height, full-balance spends without change, shared fee policy, consolidation, then exposure to services. Attribution to an exchange or mixing service must rest on current licensed labels and be corroborated before it drives a notification or a legal step.

One heuristic will mislead you here

BTIX Research weights evidence rather than trusting a single rule. A victim's verified generation history, with cryptographic proof they controlled the address, outranks any behavioural signal. Matching templates and consolidation into confirmed attacker infrastructure sit below it; temporal proximity alone never suffices.

The common-input heuristic is the trap here. Inputs spent together normally imply one signer — but an attacker holding thousands of recovered keys satisfies it while those inputs represent thousands of unrelated victims, clustering control at the moment of theft rather than ownership before it. With no change outputs to follow, consolidation is the stronger pivot, and it holds only until funds reach a custodial service or collaborative protocol.

Exposure follows the seed, not the box

The affected population is defined by where a seed came from, not what hardware holds it today. A user who updated firmware, restored that mnemonic onto another brand, or destroyed the original device is still exposed: the same seed controls the same key tree, and the update leaves it exactly as weak.

The inverse holds too. Owning an affected model proves nothing if the seed predates the regression, was imported from a sound source, had qualifying private dice entropy mixed in, or sits behind a strong unique passphrase.

Single-signature wallets are the clean target. Multisig helps only where the quorum's keys come from independent generation failure domains — one assembled entirely from affected devices is as recoverable as a single key, and different brands sharing code lineage do not fix it. And an address count is not a headcount.

Deciding whether a specific seed is affected

Most holders do not need a threat assessment; they need a verdict about one seed. Work these questions in order and stop at the first that resolves.

Rotating a compromised seed without making it worse

Migration is where avoidable losses happen — funds moved to an address derived from the same broken seed, or a rushed transfer nobody verified. The order below is deliberate; the test transfer is not optional.

1. Assume the old seed is public

   Treat every key under it as known to an adversary who is actively sweeping. That framing prevents half-measures.

2. Install the fixed release for your exact model and track

   Standard and Edge are different tracks with different version numbers. Confirm the version on the device screen, not the download page.

3. Generate a completely new seed

   A new seed — not a new account or derivation path under the old one. Mix in dice if your procedure supports it.

4. Verify the backup and the fingerprint

   Confirm the written backup restores, and check the fingerprint against your coordinator before the wallet holds value.

5. Verify the receiving address on the device itself

   Read it from the hardware screen, not the computer. This is what defeats address substitution.

6. Send a small test and confirm it

   Wait for confirmation and verify the funds are spendable before committing the balance.

7. Move the full balance

   Highest-value UTXOs first. If a sweep is already in progress, prioritise rather than batching into one slow transaction.

8. Keep the old backup until migration is confirmed complete

   Destroying it early risks stranding an overlooked UTXO. Retire it once nothing remains under the old key tree.

9. Record the provenance of the new seed

   Model, firmware at creation, generation method, passphrase and derivation policy. This makes the next advisory answerable in minutes.

Capable, prepared, unidentified

The operational picture shows preparation. Constraining device states, deriving wallet branches, running a chain index and emptying more than a thousand addresses inside 41 minutes is not opportunistic work — the infrastructure was staged before the first transaction went out. The timing relative to disclosure allows three readings: independent discovery, knowledge through a non-public channel, or an unusually fast reaction to early private reports. Nothing available distinguishes them.

Assessed — moderate
The first two waves were run by a single actor or with a single toolchain, on consistent fee and batching behaviour. That judgment does not extend across the campaign: once the mechanism was public, the barrier to entry was a laptop and an offline reconstruction tool, and subsequent reporting describes multiple independent parties working the same flaw. Later divergence in construction is at least as likely to be a different operator as an evolving one.

No attribution to any named group, country, employee, researcher or competitor is supported, and the widely repeated claim that AI found the bug is speculation the vendor itself flagged as such. Motive is assessed as financial with high confidence; where the funds went afterwards remains unknown.

Provenance beats hashes in this incident

There is no malware sample and no infrastructure to block. The useful indicators describe how a seed was made and how funds behaved — for triage, never for attribution.

What defenders can see that holders cannot

Population-level visibility is the advantage. A monitoring service can flag synchronised full-balance spends from long-dormant addresses, an unusual shared fee rate, absent change, and rapid convergence onto common outputs. An individual watching one wallet sees none of it until their turn.

Enterprises can build the same advantage internally without touching secrets: a local record of which assets were generated on which firmware answers the exposure question directly, and descriptor-based scanning finds affected balances from public receive information alone.

Exchanges and custodians should consume confirmed clusters through trusted channels, preserve deposit metadata and escalate under existing legal process — but not freeze a customer because an address resembles a fee template. Detection logic should be versioned, because transaction construction can change at any time.

An approximate mapping, offered as one

ATT&CK Enterprise models intrusions into enterprise technology. This was a key-recovery campaign that never entered a victim environment, so the mapping below is an approximate crosswalk for teams that report in ATT&CK terms — not a claim that the framework describes the incident. Stages the evidence does not support are left out entirely, which is why the table carries three techniques rather than a fuller-looking set. Every identifier and name was verified against the official MITRE ATT&CK Enterprise pages at the evidence cutoff; where a technique is defensible only as vocabulary, the limitation is stated in the row rather than resolved by upgrading the classification.

By audience

• Exposed holders

  Follow the triage sequence in section 12, then the runbook in section 13. If the answer to any question is "I'm not sure," migrate.

• Enterprises and funds

  Keep a key-origin inventory — model, firmware at generation, generation method, passphrase and derivation policy, quorum composition — and treat it as sensitive metadata. Search for exposure against public descriptors, never seed material.

• Manufacturers

  Remove deterministic fallbacks from cryptographic APIs, feed a reviewed DRBG at full width, and document the entropy budget. Test the linked binary on production hardware, and treat a cryptographic library swap as a threat-model event, not a refactor.

• Wallet coordinators

  Warn on firmware provenance without collecting it centrally, and build a migration flow that never asks for a mnemonic on a connected machine. Make previews distinguish a migration destination from an attacker's spend.

• Responders and exchanges

  Work from a versioned indicator feed, record confidence and source for every cluster edge, and keep confirmed victim funds separate from suspected flows. Irreversibility makes speed matter; it does not make evidentiary discipline optional.

• Assurance and audit

  Assess entropy systems against SP 800-90B principles and treat passing statistical tests as evidence of nothing. State the invariant — no seed unless the required assessed entropy has entered an approved construction — and verify it under every build flag and simulated hardware failure.

What would move our confidence

Publishing unknowns is only useful if you say what would resolve them. These four inputs would let BTIX Research upgrade its assessments in a future revision.

What the industry should take from this

• An air gap describes a channel, not a guarantee

  Offline signing closes the paths through which a host can request or observe a signature. It says nothing about whether the key was unpredictable when it was made. Assurance should break "air-gapped" into transport, parsing, display, signing, storage and generation, and test each separately.

• Entropy provenance has to survive abstraction

  Libraries hide unsafe states behind friendly names, and few are friendlier than random. Every call that produces a secret should carry a documented chain from physical source through conditioning and DRBG state to the consumer, and the build should make a production fallback impossible. Entropy is also a budget: thirty-two bytes do not imply 256 bits, conditioning cannot expand the candidate space, and "mixed with secure-element entropy" means nothing until the full width and reseed semantics are shown.

• The linked binary is the product

  This failure lived at the seam between build configuration, two libraries and a board wrapper, and every component passed its own tests. Release assurance should inspect link maps, run the shipped binary on production-equivalent hardware, inject hardware-RNG failure, and confirm key generation halts rather than degrades.

• Recovery architecture must diversify failure domains

  Multisig defends against one compromised key only when the others were generated independently; several units of one model, or models sharing entropy code, concentrate the risk they appear to spread. Diversify vendors, code lineages, ceremonies and locations, and rehearse rotation without assembling the seeds on one machine. The advisory that follows has to match: "update now" produces relief without safety unless it also says the old seed stays compromised and gives a test-first migration order.

The boundary that mattered was not connectivity

A hardware wallet can keep a secret perfectly and still produce a secret worth nothing. A configuration assumption, a permissive fallback and a narrow reseed together dismantled controls that were otherwise working exactly as designed.

The evidence for the mechanism is strong, and so is the chain evidence for large automated theft — more than 1,778 BTC confirmed at our cutoff, with the sweeps quiet since 6 August. What it does not yet support is address-level reproduction, actor identity, real cracking cost, or the inclusion of every suspected wave.

For manufacturers the correction is architectural: entropy needs end-to-end provenance, explicit failure, and verification in the binary that ships. For investigators it is methodological: separate seed provenance from chain behaviour, restrain clustering claims, publish confidence tiers. For everyone holding coins it is operational: keep generation records, diversify trust domains, and accept that no firmware update reaches backwards to fix a seed that was weak when it was written down.

Evidence matrix

What BTIX knows, assesses, and does not know — claim by claim.

Source basis

This report draws on public firmware analysis, vendor advisories, on-chain investigator reporting, Bitcoin specifications, NIST guidance and the MITRE ATT&CK framework. BTIX Research provides the analytical reconstruction, confidence assessment, triage methodology and defensive recommendations.