If you hold digital assets on a hardware wallet — or you advise clients who do — this is written for you.
What happened
On July 30, 2026, attackers drained 1,196 Bitcoin addresses in 41 minutes. 1,082.65 BTC — about $70.2 million at the time — gone before most victims knew anything was wrong. $30 million of it moved in the first ten minutes (BleepingComputer).
Two more waves followed on July 31 and August 1: 76.16 BTC, then 207.73 BTC (TechSpot; CybersecurityNews). By the time the bleeding stopped, the total stood at 1,367 BTC — roughly $88.6 million — pulled from 4,585 addresses (Infosecurity Magazine).
None of the victims lost a device. None of them clicked a phishing link. None of them approved a malicious transaction. They did everything a hardware wallet exists to make unnecessary to worry about — and lost their funds anyway.
The cause: a random number generator that had not been generating random numbers since March 2021.
The bug, in plain terms
Coldcard, made by Canadian manufacturer Coinkite, is one of the most trusted names in Bitcoin self-custody. Air-gapped, open-source firmware, a dedicated hardware RNG chip. On paper, exactly what a security-conscious holder should want.
The firmware was supposed to pull randomness from the device’s STM32 hardware RNG when generating a new seed. A code change on March 1, 2021 broke that, and it first shipped in firmware v4.0.0 on March 17, 2021. A faulty guard in the libngu library checked whether a configuration macro was defined, not whether it was actually enabled — the macro was present but set to (0), which was enough to pass the check anyway. In Coinkite’s own words: “The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build.” That silently routed key generation into Yasmarang, a non-cryptographic software fallback built into MicroPython, seeded from the device’s unique ID XOR’d with a free-running timer (Coinkite — technical backgrounder; Fystack; CybersecurityNews).
The practical effect: seeds that should have carried 128 to 256 bits of entropy carried somewhere between 40 bits (Mk3) and 72 bits (Mk4, Mk5, Q) (Fystack). An attacker who could pin down a device’s unique ID, timer state, and prior RNG calls could reproduce candidate seeds entirely offline and check them against known blockchain addresses — no phishing, no malware, no physical access to the wallet required (BleepingComputer).
⚠️ This wasn’t a zero-day someone had to reverse-engineer under pressure. It was one line of logic that had been silently wrong in shipping firmware for five years.
The response — and its limits
Coinkite disclosed the flaw roughly 30 hours after the first attack wave and shipped patched firmware within about two days (Fystack; TechSpot). Per Coinkite’s own advisory, affected releases were Mk2/Mk3 firmware 4.0.1–4.1.9, Mk4/Mk5 before 5.6.0, and Q before 1.5.0Q, with fixed firmware at 4.2.0, 5.6.0, and 1.5.0Q respectively (Coinkite — official advisory).
But patching the firmware does not patch the seed. Anyone who generated a wallet on vulnerable firmware is still carrying a low-entropy seed today — updating the device doesn’t retroactively fix a key that already exists. Galaxy Research’s advice was blunt: move funds off any Coldcard-generated single-sig seed immediately, generate a fresh seed on patched firmware, verify addresses on-device, and migrate (Fystack; CybersecurityNews).
That is a lot to ask of someone whose entire reason for buying a hardware wallet was to stop thinking about key security.
This is not a Coldcard problem. It’s a pattern.
Entropy failures are not a hardware wallet issue, or a Bitcoin issue, or a Coinkite issue. They are a recurring category of loss across the entire industry, because entropy quality is invisible until an attacker with capital at stake decides to test it.
| Incident | Year | Root cause | Impact |
|---|---|---|---|
Android SecureRandom | 2013 | Weak Java RNG on Android reused signing randomness | Bitcoin private keys recovered from reused values |
| Profanity vanity address tool | 2022 | 32-bit seed space in a GPU key generator | ~$160M drained, including Wintermute |
| Trust Wallet browser extension | 2023 | Insufficient entropy in key generation | User funds compromised |
| Libbitcoin Explorer (“Milk Sad”) | 2023 | Predictable Mersenne Twister seeding | Systematic wallet draining |
| Coldcard | 2026 | Hardware RNG silently bypassed for software fallback | $88.6M, 4,585 addresses |
(Sourced from Fystack’s analysis of historical entropy failures.)
The common thread across all five: a single implementation was trusted to get randomness right, nobody could verify that it did, and the flaw sat there — sometimes for years — until someone found it the hard way. As Fystack puts it, the failure mode is “assumed instead of verified.”
The real lesson: single points of failure don’t announce themselves
A hardware wallet concentrates trust in one place: one vendor, one firmware build, one RNG implementation, one moment of key generation. When that one thing is correct, it’s an excellent security model. When it’s silently wrong, everything built on top of it is wrong too — and there is no way to know until someone with an incentive to look, looks.
Notably, even coverage of this incident pointed at the fix that was hiding in plain sight: multi-signature setups spanning devices from different manufacturers would have been resilient against a vendor-specific RNG failure like this one (CybersecurityNews). If a Coldcard-generated key was only one of several independent keys required to move funds, a flaw in Coldcard’s RNG alone would not have been enough to drain a wallet.
That’s the principle worth generalizing, and it’s a governance principle before it’s a cryptography one: no single vendor, device, or implementation should be a single point of failure for control of an asset — no matter how trusted that vendor is. Multi-party computation, multisig across independent hardware, and threshold key generation all express the same underlying idea in different technical forms: split trust so that one silent bug, one compromised employee, or one bad firmware push cannot unilaterally compromise the funds.
To be clear, that alone doesn’t make an organization safe. Distributed key generation still needs to be paired with the operational discipline to catch this class of failure — independent audits of the code paths that generate entropy, monitoring for anomalous fund movement, a real incident-response process, and a documented answer to “how do we know our key generation is doing what we think it’s doing?” Coinkite is a serious, open-source vendor, and the bug still went undetected in production for five years. Verification has to be a process, not a one-time assumption made at purchase.
Questions worth asking about any wallet’s key generation
| Question | Why it matters |
|---|---|
| Is any single vendor’s implementation the sole source of entropy for this key? | A single-vendor RNG bug is a single point of failure, as Coldcard showed |
| Would a flaw in one device or one signer alone be enough to move funds? | Multisig / MPC across independent implementations limits blast radius |
| How would we detect a silent entropy or RNG regression before an attacker does? | Coinkite’s bug shipped in March 2021 and was found in July 2026 |
| If a vendor discloses a flaw, do we have a tested process to rotate keys and migrate funds fast? | Patching firmware does not fix seeds already generated on it |
| Who is accountable for verifying vendor security claims, and how often? | “Open source” and “hardware RNG” are marketing claims until someone checks the code path in production |
Where this is going
Hardware wallets solved a real problem: keeping keys off internet-connected devices. But the Coldcard incident is a reminder that “cold storage” answers where a key lives, not whether the process that created it was trustworthy — and that a single implementation, however well-regarded, is still a single point of failure.
The industry’s next step isn’t choosing a different hardware vendor and hoping its RNG is the one that never fails. It’s building custody around the assumption that any single implementation — vendor, device, or protocol — can fail silently, and designing governance so that no single failure is catastrophic: distributed key generation, independent verification, and an operational process that can respond fast when (not if) a flaw surfaces.
That is the governance layer Vastlink is building for digital asset custody — where control of an asset is never resting on the correctness of one vendor’s firmware, and recovery from a single point of failure is a designed capability, not a scramble.
