Coldcard Hack Drains $130M in Bitcoin: Hardware Wallet Flaw Explained

The Coldcard incident is a useful security review because the device was designed to rely on a hardware random-number generator, yet a build and link integration error routed seed generation through a software pseudorandom-number generator. The failure appeared during the March 2021 libNgU migration. It was not a runtime hardware failure and it was not an intentional weak-entropy fallback, according to Coinkite’s technical explanation.

This distinction matters for developers. An offline wallet can remove network exposure while retaining software supply-chain, build-system, symbol-resolution, and release-management risk. The Coinkite security advisory, the Coinkite technical backgrounder, and Galaxy Research’s incident report support the analysis below.

The article separates three questions that are often mixed together. What code path created the weak seed? Which release tracks and models are in scope? What does a safe remediation sequence look like when firmware can stop future failures but cannot alter an existing seed?

What You'll Learn

• How a link-time integration error diverted Coldcard seed generation
• Which models and firmware release tracks Coinkite identifies as affected
• Why updating firmware does not repair an existing wallet seed
• How senior developers should review entropy, build, release, and migration controls

What the Coldcard Incident Actually Exposed

Coldcard hardware wallets are intended to keep private keys offline. That design reduces the attack surface created by network-connected computers, but it does not make every layer of the wallet trustworthy by default. A wallet seed is created before a private key can authorize a transaction. If the seed-generation process does not receive enough unpredictable input, an attacker can search candidate seeds without taking physical possession of the device.

Galaxy Research says attackers began draining wallets on July 30, 2026 across multiple escalating waves. Its August 7 report tracked roughly 1,082 BTC by August 1, approximately 284 BTC in the next two waves, at least 15 separate attackers, and losses near $130 million as of August 4. Those are Galaxy’s tracking figures and estimates. They are not an audited total supplied by an exchange, regulator, or court.

The protected headline uses $130M because that estimate is present in Galaxy’s report. The safer technical conclusion is narrower. The incident shows that key creation is part of the security boundary. An offline device can still produce a weak key if the firmware, build, or verification process does not deliver the randomness the design requires.

For adjacent context on security assumptions in digital assets, see the site’s Zcash vulnerability analysis. The incidents differ, so the link is context rather than evidence for the Coldcard root cause.

How the Seed-Generation Path Failed

Coinkite says Coldcard was designed to rely exclusively on its hardware TRNG for seed generation. During the libNgU migration in March 2021, seed generation moved from `ckcc.rng_bytes()` to `ngu.random.bytes()`. The new path exposed Bitcoin primitives through an embedded MicroPython library, but the `rng_get()` symbol resolved to MicroPython’s Yasmarang implementation instead of the board-specific hardware RNG implementation.

Yasmarang was introduced upstream as a general-purpose PRNG in May 2018. Its presence was not itself unusual. The failure was that a build and link integration error allowed that implementation to satisfy the symbol expected by the wallet code. Coinkite says the hardware TRNG did not fail and trigger a weaker fallback at runtime. The wrong software path was inherited through integration.

This is a different failure mode from a device that detects a hardware fault and intentionally chooses a reduced-security mode. It is also different from a claim that every random operation on the product was compromised. The source material identifies a specific seed-generation path and provides model and release boundaries. A technical postmortem should preserve those boundaries rather than turn a narrowly described defect into a blanket statement about every Coldcard operation.

Galaxy describes the consequence as a seed with a much smaller effective search space than the intended design. For affected Mk2 and Mk3 devices, Galaxy reports an estimate of about 40 bits. For newer Mk4, Q, and Mk5 devices, it reports about 72 bits. These estimates explain why offline candidate generation could become practical for attackers who knew enough about device state and seed-generation timing.

Which Models and Firmware Are in Scope

Coinkite’s advisory separates Standard and Edge release tracks. The model alone is not sufficient for a safe conclusion. A device on an Edge track must receive the fixed Edge release for that model. Coinkite specifically warns readers not to assume that an older Edge 6.x release is fixed simply because its version number is higher than a Standard release.

Coinkite says TAPSIGNER, OPENDIME, and SATSCARD are not affected by this bug because they use different codebases. That statement does not mean every product from every hardware-wallet manufacturer is safe. It means the published advisory draws a product boundary that should be respected.

The current Coldcard security status page lists Mk4 and Mk5 Standard 5.6.1 and Q Standard 1.5.1Q as the recommended Standard releases when the page was verified on August 17, 2026. A release check should compare model and track, verify the downloaded firmware, and follow the manufacturer’s migration guidance.

What Galaxy Reported About the Losses

Galaxy’s report is useful because it ties the technical defect to on-chain observations without claiming that every reported loss has been independently proven. The report says roughly 1,082 BTC had been drained by August 1, followed by approximately 284 BTC in the next two waves. It also says at least 15 separate attackers were exploiting the bug independently and that tracked losses were near $130 million as of August 4.

The numbers should be read as a dated incident snapshot. On-chain attribution can evolve as investigators cluster addresses, identify additional waves, or separate related transfers. A value near $130 million is therefore a measured research estimate at a stated point in time, not a permanent accounting result.

Galaxy also reports that physical access to the wallet was not required under its described attack model. The relevant exposure came from the ability to generate candidate seeds offline and compare derived addresses against public blockchain data. That observation explains why a device’s offline operating model did not prevent the attack once a weak seed had already been created.

For a separate view of crypto infrastructure and custody questions, readers can review the site’s Tether Gold analysis. It is not evidence for the Coldcard loss estimate, which remains attributed to Galaxy.

Why an Offline Wallet Could Still Be Attacked

Offline storage protects a private key from many remote attacks, but it does not protect the key-creation process from a defective implementation. The distinction is architectural. A wallet has at least four security-relevant stages: entropy collection, seed derivation, backup and recovery, and transaction signing. A strong signing device cannot compensate for a seed that was predictable at creation.

The Coldcard case also demonstrates why “hardware” is not a single trust property. Hardware can supply entropy. Firmware can select or combine that entropy. A linker can resolve symbols. A build system can accept the result. A release process can distribute it. A user can install and verify the package. Each stage needs an explicit control and an observable failure mode.

In a senior-developer review, the question should not be whether a product is hardware or software. The question should be whether the intended security invariant is preserved from source code to shipped binary to runtime call path. The Franken-core architecture analysis makes a similar systems point in another domain. Accumulated layers are manageable only when ownership and boundaries remain testable.

Why the Firmware Fix Is Not a Seed Migration

Coinkite is explicit that updating firmware corrects future seed generation but does not change or repair an existing seed. The patch changes the code that creates new wallet material. It cannot retroactively add entropy to words that were already generated and backed up.

This is a state-management problem as much as a cryptography problem. The old seed remains an existing security object. The new firmware is a new code state. Installing the patch moves the device into a safer state for future generation, but it does not transform the old state. A migration must create a new seed, verify it, and move funds only after the new wallet is known to work.

A strong, unique BIP-39 passphrase can add a barrier because an attacker who finds the underlying seed must also discover the passphrase. Coinkite says a passphrase does not repair the affected seed. A short, reused, exposed, or uncertain passphrase should not be treated as a reliable exception.

The safest documentation therefore treats firmware installation and seed migration as separate change records. A release ticket can prove that the binary was updated. It cannot prove that the old balance was moved to a verified replacement wallet.

What the Independent Dice Exception Means

Coinkite’s advisory says the issue affects device-generated entropy and does not remove independent entropy supplied through the Add Dice Rolls workflow. It states that 50 to 98 independent, private rolls contribute at least 128 bits of entropy from the dice input alone. It says 99 or more such rolls contribute approximately 256 bits.

The exception is conditional. The rolls must be fair, independent, private, and not recorded or exposed. If the user entered fewer than 50 rolls, does not remember the count, or cannot establish that the sequence remained private, the advisory says to follow the migration guidance. The purpose of this condition is not to create a shortcut. It is to identify whether an independent source supplied enough uncertainty despite the defective device path.

Developers should model this as an input provenance question. The wallet should be able to explain which entropy sources were used, what assumptions apply to each source, and what evidence a recovery decision depends on. A user’s memory is not the same as a machine-verifiable log, so uncertainty should be handled conservatively.

Coinkite also describes an advanced dice-only workflow on fixed Mk2 or Mk3 firmware that uses at least 99 rolls. That workflow is separate from the normal corrected New Wallet path and should not be presented as a general instruction for readers who have not studied the manufacturer’s procedure.

How to Design a Safe Migration Sequence

The manufacturer’s migration guidance is a useful control sequence for any security-sensitive wallet replacement. First confirm the fixed release for the exact model and track. Then generate the replacement seed on updated firmware. Record and verify the backup, wallet fingerprint, and a receive address. Send a small test transaction. Move the remaining funds only after the test succeeds. Keep the old backup until the migration is complete and confirmed.

This sequence creates checkpoints around the two most dangerous transitions: generating new key material and sending value to an address that may not have been verified. It also preserves a recovery path during the move. A migration tool should make each checkpoint explicit and should stop rather than silently continue when a fingerprint, address, or balance check fails.

If only one device is available, the operational risk increases because the user must switch between the old and new seeds. Coinkite describes a one-device sequence that verifies backups, installs fixed firmware, creates the new seed, restores the affected seed for a test transfer, restores the new seed to verify the receipt, and retains the old backup until the full balance arrives. The exact device procedure belongs in the manufacturer’s guide, not in an improvised script.

The site’s crypto compliance analysis provides adjacent context on why custody and transfer records matter. It does not replace the Coldcard migration sequence or create a claim about the affected user’s legal obligations.

How the Remediation Changes New Seed Generation

The current Coldcard security status page describes additional controls in the current Standard releases. New Standard seed generation combines fresh device entropy with one required user method: at least 65 key presses with unpredictable timing, 50 physical six-sided-die rolls, or 128 physical coin flips. The page says Dice Rolls Only remains a separate advanced workflow.

The technical backgrounder also describes a boot-time linkage check for the hardware RNG path and a build-time check intended to reject the wrong implementation. Coinkite reports targeted independent checks that included a real-device test on Mk4 firmware 5.6.0, source review across fixed release lines, and a reproducible build and dice-path trace for Mk4 and Mk5 5.6.0.

These controls improve assurance, but the source itself sets limits. The published evidence is not a complete independent audit of every fixed firmware binary. A real-device test, source review, and reproducible build check validate stated scopes. They do not prove that all possible defects have been excluded.

That wording is important for security communication. A release can have a documented fix and targeted independent validation without becoming risk-free. The correct claim is bounded: the published remediation addresses the described seed-generation failure and adds related checks within the stated scope.

What the Incident Says About Hardware-Wallet Assurance

Hardware wallets are often evaluated through product labels, secure elements, offline use, and open-source claims. The Coldcard incident shows why those labels are incomplete without a path-level review. A system can have public source, a hardware TRNG, reproducible builds, and experienced reviewers while still missing the actual implementation reached by a wallet seed call.

The issue was not that cryptographic primitives suddenly became weak. It was that the integration selected the wrong source of randomness for a security-sensitive operation. This is the kind of defect that can survive a review focused on the presence of the intended code rather than end-to-end symbol resolution and call reachability.

For product teams, the lesson is not to promise that a hardware wallet is unbreakable. It is to publish the security boundary, the release matrix, the migration consequence of each fix, and the evidence limits. For users, the practical lesson is to verify the exact release track and to treat a seed-generation advisory differently from an ordinary feature update.

What Senior Developers Should Audit in Firmware

A senior-developer audit should start with the invariant. If a seed is intended to contain entropy from a hardware TRNG, the build must make it impossible for the wallet path to call a software substitute without failing visibly. That invariant should be checked at source level, link level, binary level, and runtime level.

The build should reject duplicate or ambiguous symbols. The linker map should be reviewed for the resolved implementation. A negative test should intentionally include the wrong object and verify that the build fails. A runtime test should observe that the device reaches the hardware source for a known seed request. Release verification should confirm the signed length, hash, version, and model track before installation.

The site’s technology-market coverage illustrates a different kind of source-based analysis. Here the focus is not market reaction. It is whether the security claim can be traced through the shipped implementation and the user-facing recovery process.

Security reviews should also track negative space. What did the test not cover? Which model and release tracks were excluded? Was the firmware verified on a real device or only inspected in source? Were migration steps tested with a small transaction and a recovery restore? A precise limitation is more useful than a broad assurance label.

Conclusion: Treat Key Creation as a Security Boundary

The Coldcard incident is best understood as a failure in the path that creates wallet seeds. Galaxy’s loss estimate gives the event financial scale, while Coinkite’s advisory and technical backgrounder explain the firmware and migration boundary. Neither source supports a claim that every Coldcard device or every seed is compromised.

The durable engineering lesson is simple. Offline operation does not remove build and release risk. Hardware entropy is valuable only if the shipped wallet code reaches it. A firmware fix is valuable only for the state it can change. An existing seed remains a separate security object until its funds have been moved to a verified replacement wallet.

For senior developers, the review agenda is concrete: trace the security-sensitive call path, make the wrong link fail, verify the released binary, test the runtime source, publish model-specific release guidance, and design migration as a stateful workflow with checkpoints. That approach is more reliable than treating a product category as a guarantee.

Readers comparing digital-asset infrastructure topics can also review the site’s Bitcoin custody and risk analysis. The source and topic differ, but the same evidence rule applies: separate verified facts, dated estimates, and technical interpretation.