HostHostDeFi › Is Coldcard safe
Is Coldcard safe? The Bitcoin wallet whose seeds came out weak — and got stolen
Coldcard's file is the hardest in the hardware family right now: in July 2026 a seed-generation bug — an entropy path that silently fell back to a deterministic software RNG — let attackers regenerate users' private keys offline and drain real wallets. The devices were never hacked, remotely accessed, or taken over; the seeds themselves were born weak. The honest answer splits into the three years before the disclosure and everything after it.
What Coldcard is
COLDCARD is Coinkite's Bitcoin-only hardware wallet — the air-gapped, open-source-firmware device that defined the hardcore end of self-custody: no USB data path required (PSBTs move by microSD or NFC), dual secure elements on the Mk4 and later, a verifiable supply chain with numbered tamper-evident bags, and a feature set aimed at users who treat operational security as a discipline — duress PINs, brick-me PINs, seed XOR, BIP-85 child seeds, and an air-gapped signing flow that never touches a networked machine. It is the device long-time Bitcoiners mean when they say 'proper cold storage'.
Coinkite's public security record is also the most transparent in the hardware class: a documented Security Disclosure History spanning 2019–2026 with roughly thirty entries, reproducible builds, published audits, and a tradition of shipping fixes with CVE-grade writeups rather than changelogs. That transparency cuts both ways — it is why the July 2026 disclosure exists in detail at all, and it is what makes the contents of that disclosure impossible to wave away.
July 2026: the entropy bug
The incident file is unusually precise because Block's engineering team published the root cause. COLDCARD was designed to generate seeds exclusively from the STM32 hardware true-random-number generator, with the software path disabled. When the elliptic-curve stack moved to Bitcoin Core's libsecp256k1 in 2021, an embedded library called libNgU was added — and a build-integration error meant its randomness symbol resolved to MicroPython's default Yasmarang software generator instead of the hardware RNG. Seeds generated after that migration drew entropy from a generator seeded by the MCU's unique ID and timer registers.
The impact split by model. On Mk2 and Mk3 firmware 4.0.1 through 4.1.9, no cryptographic entropy was added at all — for a known chip UID, timer state, and call history, wallet generation was deterministic. On Mk4, Mk5, and Q, secure-element entropy was added at boot but hashed down to four bytes, and reseeding replaced only a 32-bit state word — roughly 72 bits of effective entropy instead of 128. Attackers exploited the weakness entirely offline: enumerate the plausible RNG states, regenerate the corresponding private keys, watch the derived addresses, and sweep the funds. Security researcher Praveen Perera's public Wave-1 reconstruction modeled the cold-start Mk3 path and recovered 328 wallet seeds behind 1,042 of 1,195 source addresses — the bug was not theoretical, and neither were the thefts.
What the fix actually covered
Fixed firmware shipped for every supported model and track: Mk2/Mk3 version 4.2.0, Mk4/Mk5 standard 5.6.0 and Edge 6.6.0X, Q standard 1.5.0Q and Edge 6.6.0QX — restoring the required user-entropy and fail-closed RNG controls, re-adding entropy inspection tools, and adding transaction, Virtual Disk, firmware, and policy checks. But the fix has a hard edge that the page owes you plainly: updating firmware does not repair an existing seed. A seed born under the weak path stays weak forever — the only remediation is generating a new seed on fixed firmware (or supplying the documented exception: at least 50 independent dice rolls, or a strong unique BIP-39 passphrase as partial mitigation) and moving funds on-chain.
Coinkite's disclosure posture was the strong version: the advisory named the affected version ranges per model, explained the mechanics in a technical backgrounder, preserved the fixed source in release tags with verifiable git ancestry, and refused the comforting simplification — its own security page states that the public record does not support claiming no Mk4/Mk5/Q wallet was robbed. That is what honest incident handling looks like: the vendor published the bad news at full resolution rather than the reassuring summary.
The honest read
Two things are true at once. First, the failure was the worst kind a hardware wallet can have: not a stolen key, not a phished user, but a device that generated breakable secrets — and the breakage was invisible to the user for years. The 'air-gapped, verifiable, Bitcoin-only' stack did exactly nothing against it, because the failure was inside the trusted boundary at the moment of seed creation. Second, the response was the best the industry produces: full technical disclosure, model-by-model affected ranges, migration guidance, fail-closed redesign, and a vendor that updated its own marketing claims to match the evidence.
The practical verdict: a Coldcard running fixed firmware with a migrated seed is arguably safer than before — the RNG path is now fail-closed and independently inspected by the researchers who broke the old one. But the incident reprices what 'safe' means for the brand: the residual risk is not theft of the device, it is trust in the entropy of anything the device ever generated. Anyone holding a pre-fix seed who has not migrated is carrying the live version of this incident right now.
What owners should actually do
The remediation ladder, in order of urgency: if the seed was generated on Mk2/Mk3 firmware 4.0.1–4.1.9 without 50+ private dice rolls, treat it as compromised-on-arrival — generate a new seed on fixed firmware and move the funds, because the deterministic path is the one attackers mined first. If the seed came from Mk4/Mk5/Q pre-fix firmware, the ~72-bit exposure is weaker but still below the 128-bit target — migrate as soon as practical. A strong unique BIP-39 passphrase layered on the seed reduces exposure but does not repair it; the passphrase buys time, not safety.
Second, verify the firmware itself the way the incident taught everyone to: check the release tag's git ancestry (Coinkite published the fixed tags with the remediation included), confirm the device reports a fixed version number, and use the restored entropy-inspection tools — View TRNG Words and the dice-roll verification — to look at what the RNG is producing rather than assuming. The bug's deepest lesson is that 'open source' is a property of the code, not a guarantee the artifact on the device was built from it correctly.
Where Coldcard stands
In the hardware tier, Coldcard is the disclosure-integrity pole: the only vendor whose incident file is detailed enough to audit end-to-end, because Coinkite and Block both published their versions. The counterweight is that the incident happened at all — a subtle integration bug survived five years of open-source availability, which says something uncomfortable about how many eyes actually verify entropy paths. Against the field: Ledger's SE has never been extracted remotely but its customer-data breach and closed firmware are the liabilities; Trezor's open firmware was physically extracted; BitBox02 pairs open firmware with a secure chip; Jade removes the SE for a blind oracle. Coldcard's answer after July 2026 is a new shape — proven-broken, proven-fixed, and the only wallet whose safety argument now includes a post-mortem strangers can verify.
Frequently asked questions
Were Coldcard devices hacked?
No — and the distinction matters. Coinkite's advisory is explicit: the devices were not hacked, remotely accessed, or taken over. A firmware bug produced weakened seed entropy, and attackers exploited those weak seeds offline — regenerating private keys and stealing funds without ever touching a device.
Which Coldcard models were affected?
Mk2/Mk3 firmware 4.0.1–4.1.9 had the severe path (deterministic generation for a known chip UID). Mk4, Mk5, and Q seeds generated before the fixed releases were also affected but less severely — about 72 bits of entropy instead of 128. Mk1 and pre-v4.0.0 firmware were outside the regression.
Does updating the firmware fix my seed?
No. Updating stops new seeds from being generated weakly, but it does not change an existing seed's entropy. If your seed was created on affected firmware, the remediation is migrating funds to a new seed — unless you supplied at least 50 independent dice rolls at generation, and even a strong passphrase is only partial mitigation.
Did anyone actually lose funds?
Yes — real thefts occurred and are what forced the disclosure. Researchers reconstructed hundreds of weak seeds publicly; Praveen Perera's Wave-1 reconstruction alone recovered 328 seeds behind 1,042 of 1,195 victim source addresses. The public record does not support the claim that no newer-model wallet was robbed.
Is a fixed-firmware Coldcard safe now?
The entropy path is now fail-closed with restored user-entropy requirements and independent post-mortem verification — a stronger state than the years when the bug sat undetected. The residual risk is not the new firmware; it is any seed generated before it that was never migrated.
How does this compare to the Trezor extraction?
Different failure shapes. Trezor's 2020 Kraken voltage-glitch required physical possession of a specific device. Coldcard's July-2026 bug required no device at all — weak seeds were attackable purely on-chain, at scale, which is why it produced mass thefts rather than a lab demonstration.