On July 31, 2026, between 01:31 and 01:56 UTC, roughly 594.48 BTC — over $38 million — was swept out of approximately 500 Bitcoin wallets in a twenty-five minute window. No phishing. No malware. No physical access to any device. The attacker simply calculated the private keys.
This is the event the cold storage industry has always feared, because it doesn't attack the user — it attacks the assumption the entire security model rests on. If the randomness behind a seed isn't actually random, every other layer — secure element, air gap, PIN, tamper-evidence — becomes decoration.
This is an analysis of what happened, why it happened, and what questions every cold wallet holder should be asking from today onward.
Overnight between July 30 and 31, 2026, an attacker executed a coordinated sweep across approximately 500 single-signature Bitcoin wallets. Per the on-chain reconstruction reported by CoinDesk, funds were drained across roughly 500 transactions; 562 BTC were subsequently consolidated into a single address, which has since remained stationary. Rob Hamilton, CEO of AnchorWatch, counted 1,324 spent outputs (UTXOs) involved in the sweep.
The total may not be final. Clay Garrett, an engineer at Block, identified an additional 695 transactions matching the same behavioral signature, moving 488.1 BTC. If linked to the same actor, the combined haul would rise to roughly 1,082 BTC. As of publication, that link is not confirmed.
The root cause was identified by Block's Bitcoin engineering and security teams, who published their technical analysis while the attack was still in progress — an explicit decision to ship incomplete testing because exploitation was already underway. Coinkite, Coldcard's manufacturer, confirmed the findings and published its own technical backgrounder alongside a customer advisory.
The verdict: for years, Coldcard devices generated seed phrases with dramatically less effective entropy than advertised.
The flaw is not a cryptographic error. It's a build error — which makes it far more interesting, and far more instructive.
Coldcard firmware is built on MicroPython. On the production board, the configuration macro MICROPY_HW_ENABLE_RNG is set to 0. That was deliberate: Coinkite didn't want MicroPython's generator, it wanted its own hardware wrapper around the chip's TRNG (True Random Number Generator).
The problem is that the cryptographic library libngu checked only whether the macro existed, not what value it held — an #ifndef MICROPY_HW_ENABLE_RNG where #if !MICROPY_HW_ENABLE_RNG was required. With the macro defined as zero, the check passed anyway, and the code fell back silently to MicroPython's software generator: the deterministic Yasmarang algorithm.
As Coinkite puts it in its own backgrounder, "the wrong version of a function called rng_get() was pulled into the source code and used almost everywhere we needed entropy." The two implementations — hardware and software — had identical signatures. No compile error, no warning, no visible difference under review.
This is where the flaw stops being theoretical. The software PRNG was seeded from:
c
pad = UID_low32 ^ SysTick->VAL;
n = RTC->TR; // time register
d = RTC->SSR; // sub-secondsTranslated: the chip serial number (factory-set, fixed, not secret) and clock registers (temporal state an attacker can narrow down or measure). Neither is a cryptographic source. They are metadata. Block further notes these values are initialized exactly once, on the first call to rng_get(), and no fresh entropy is ever collected afterward.
For a device whose UID is known and whose boot conditions can be estimated, wallet generation becomes fully deterministic.
Model | Firmware | Effective entropy | Source |
|---|---|---|---|
Mk2 / Mk3 | v4.0.0 – v4.1.9 | ~40 bits (instead of 128) — deterministic generation | Coinkite / Block |
Mk4 / Mk5 | before 5.6.0 | ~72 bits (Coinkite) / ~2³¹ average trials against the reseed (Block) | Coinkite / Block |
Q | before 1.5.0Q | as above | Coinkite |
Mk1, and Mk2/Mk3 through v3.2.2 | — | not affected | Block |
A note on the Mk3 range. Sources disagree on the upper bound. Coinkite's technical backgrounder and Block's analysis both point to v4.0.x–v4.1.9; Coinkite's Mk3-specific advisory, however, extends the risk through v5.0.3, the final release for that model. When in doubt, treat any seed generated on an Mk3 from 4.0.1 onward as affected. Note also that Coinkite's first advisory declared Mk4/Mk5/Q "not affected based on our early analysis" — a position later reversed by the technical backgrounder. This table reflects the more recent position.
For Mk2/Mk3, Block quantifies the search space at roughly 2⁴⁰·⁷, dropping as low as ~2¹⁶·³ if the RTC is stable during a cold boot — a figure within reach of a laptop. For Mk4, Q and Mk5, secure element entropy was present (40 bytes: 32 from SE1, 8 from SE2), but truncated to four bytes after the SHA256d hashing that fed the reseed — a reduction sufficient to make the search computationally tractable.
An often-overlooked detail: this doesn't only affect seeds. Per Block's analysis, the same RNG path also fed secp256k1 paper-wallet private keys, Seed XOR masks, ephemeral ECDH keys for cloning, USB encryption and Key Teleport, Secure Notes passwords, and Web2FA shared secrets and nonces.
May 2018 — the Yasmarang fallback lands in upstream MicroPython (commit f68e722, "stm32/rng: Use Yasmarang for rng_get() if MCU doesn't have HW RNG").
March 1, 2021 — commit b18723dd: the library migration that effectively activates the fallback in seed generation. Firmware v4.0.0 ships March 17, 2021; Coinkite pins user exposure to 4.0.1 and later.
July 30, 2026 — Block identifies the root cause.
July 31, 2026, 01:31 → 01:56 UTC — the sweep.
Over five years between the flaw's introduction and its public exploitation.
Coinkite has been transparent here: prior reviews verified that the TRNG code was present in the binary, but never traced which of the two implementations actually executed during seed generation. Identical signatures, build-time resolution, no signal.
The Bitcoin Core contributor known as instagibbs confirmed the flaw by reproducing it on a freshly initialized Mk3 — using nothing but button presses.
Coinkite stated it believes "someone used AI to review previous versions of our firmware."
Here is the detail that makes this emblematic: weeks before the attack, Coinkite ran its own AI-assisted security review using — by their own account — one of the best available models against their codebase. That analysis found neither this bug nor anything else serious.
The same tool, in the hands of defender and attacker, produced opposite outcomes. Not because the model was worse for the defender, but because the attacker held a structural advantage: they could afford to analyze years of historical firmware releases, hunting for a single discrepancy, with no constraint on time, scope, or cost.
The operational lesson isn't "AI is dangerous." It's that the complete firmware history of a closed device is an attack surface, and the marginal cost of mining it has just collapsed.
For completeness: the exact scope is still being established. Max Guise, who leads Bitkey development at Block, warned that the flaw touches a broader set of models than initially disclosed — Mk2, Mk3, Mk4, Q and Mk5 — with severity varying by model, and that the risk extends to multisig configurations where two or more key generation processes are affected. Guise confirmed Block products, including Bitkey, are unaffected. Coinkite separately clarified that TAPSIGNER, OPENDIME and SATSCARD use different codebases and are not affected.
Before any architectural discussion, the practical part. A firmware update does not repair an already-generated seed. The math has already been done; the addresses already exist.
Treat every seed generated on an Mk3 with firmware 4.0.1 or later as compromised. Coinkite is warning all users who generated a seed on an Mk3 running 4.0.1 (March 2021) or any subsequent version that their funds may be at risk.
Mk4 / Mk5 / Q: upgrade to 5.6.0+ (or 1.5.0Q+), then generate a completely new seed and move your funds.
Migrate — don't just regenerate an address. You need a new seed and new addresses. Moving the same seed phrase to a different wallet fixes nothing.
Verify the wallet fingerprint before moving funds.
Watch out for weak passphrases. Guise warned the risk persists even after transferring the recovery phrase, particularly for wallets protected by easily guessable passphrases.
Check paper backups and paper wallets generated on the same device — they share the same randomness source.
If you use multisig, audit the provenance of every key. Multisig only protects you when keys come from genuinely independent entropy sources.
It's tempting to treat this as an isolated bug. It isn't. It's the expression of three architectural choices the entire hardware cold storage sector has adopted as standard:
A single entropy source. When that source fails silently, there is no redundancy.
Closed, compiled embedded firmware with build-time symbol resolution. The flaw was invisible because the linker picked the wrong implementation without saying so.
No independent verification path for the user. No Coldcard owner had any way to check whether their seed was generated with real entropy.
XColdPro starts from different premises on all three. Not because it's immune — no software is, and we'll say so explicitly further down — but because the failure class that hit Coldcard meets a different structure here.
XColdPro does not rely on one generator. Every seed phrase draws from a pool fed by several independent classes of randomness — hardware, operating system, and human and environmental input — so that no single one of them determines the outcome. The exact set of sources, how they are weighted and how they are combined are implementation details we deliberately do not publish; what matters architecturally is the property they produce, stated in the manual in a line that reads rather differently in light of today:
"…compromise of any single entropy source doesn't compromise seed phrase security."
This is precisely the countermeasure to Coldcard's failure. In the Coldcard model, the silent fallback from TRNG to software PRNG collapsed the entire key space. In a multi-source pool, one source failing degrades entropy; it doesn't zero it. For the seed to become predictable, every class would have to fail simultaneously — sources that share neither implementation, nor vendor, nor failure surface.
The Coldcard flaw existed because two functions with identical signatures were resolved incorrectly at compile time, governed by a C preprocessor macro evaluated the wrong way.
XColdPro is written in Python, with no JavaScript or npm dependencies. That choice was made primarily against supply chain attacks — but it has a relevant consequence here too: there is no preprocessor, and symbol resolution does not happen at build time. Imports are explicit and evaluated at runtime. The specific failure mechanic — a macro defined as zero passing an existence check, and a linker silently selecting the wrong one of two identically-named implementations — has no direct equivalent in this execution model.
Said honestly: this does not make XColdPro immune to implementation errors. No language does. It eliminates this category of silent ambiguity, which is a smaller and more modest claim — but it happens to be precisely the category that cost $38 million.
Coldcard's TRNG was custom plumbing on closed hardware: internally reviewed, externally unverifiable, and — as it turned out — never traced through to the actual execution path.
XColdPro instead builds on the randomness primitives the operating system already provides, and on established, widely adopted open source cryptographic libraries rather than in-house cryptographic plumbing. These are among the most heavily scrutinized cryptographic components in existence — maintained by thousands of developers, continuously fuzzed, with public and documented vulnerability histories.
The reasoning is simple: a flaw in the Linux kernel CSPRNG would be found by an order of magnitude more eyes, in an order of magnitude less time, than a flaw in one hardware manufacturer's firmware RNG path.
No Coldcard owner could verify their seed's entropy. XColdPro implements exclusively open, published standards — BIP-39, BIP-44 — with a direct practical consequence:
Seeds generated by XColdPro import correctly into any BIP39-compatible wallet, and vice versa.
The implementation can be checked against BIP39 reference test vectors and NIST cryptographic test vectors.
Address derivation is verifiable against reference implementations.
This is not an absolute guarantee of correctness. But it is the difference between "trust our firmware" and "check the output against the standard yourself."
A Coldcard owner who could have compared their device's effective entropy against an independent reference would have had five years to spot the anomaly. They never had that tool.
The single most important observation from this whole affair: Coldcard users with a strong BIP-39 passphrase were largely protected, because the passphrase contributes entropy that never passed through the defective generator. Coinkite confirms this explicitly — if an affected Mk3 seed was used with a BIP-39 passphrase, early analysis indicates funds are at minimal risk. Coinkite now recommends strong passphrases or dice rolls as supplementary entropy.
XColdPro treats this layer as a first-class feature, not an advanced option:
Hidden & Decoy Wallets. The system implements hidden wallets through BIP-39's optional passphrase — the so-called "25th word." Technically it functions as additive entropy: the passphrase feeds the standard BIP-39 derivation, producing an entirely different derivation path. Seed A + password X yields wallet 1; seed A + password Y yields wallet 2; seed A with no password yields wallet 3. All three valid, all three functional, cryptographically unrelated.
The feature was designed for plausible deniability — coercion resistance, border crossings, the "$5 wrench attack." But the same mathematics delivers RNG-weakness resistance: an attacker who can compute your seed still doesn't reach your funds without the passphrase, which never went through the generator.
Tiered password generator. Passphrases are generated exclusively with cryptographic randomness — never generic pseudo-random generators — at several selectable strength levels, including a mnemonic-style option that is easy to transcribe by hand.
External seed import. XColdPro accepts any BIP39/BIP44-compatible seed. Anyone wanting entropy fully independent of software — dice rolls, coin flips, any verifiable physical process — can generate the seed externally and import it. The manual attaches an explicit caveat: XColdPro cannot verify the origin or handling history of a seed created elsewhere, and import is at the user's own risk.
SeedVault (Shamir Secret Sharing). Splits the seed into N shares with an M-of-N threshold: any M shares reconstruct the wallet, while M−1 shares reveal mathematically zero information in the information-theoretic sense. This is not a defense against weak RNG — no sharing scheme is — but it's the difference between "a compromised backup equals lost funds" and "a compromised backup is nothing."
Citadel Protocol. 100% air-gapped multi-party approval, with no online coordination and no smart contracts. And here is something the Coldcard incident makes obvious that too much marketing ignores: multisig does not protect you if every key comes from the same defective entropy source. That is exactly Guise's point. Multisig's value lies in the independence of its sources — different devices, different implementations, ideally different vendors. A software-based, vendor-independent architecture like XColdPro's makes that diversification practical rather than expensive.
There's a final point, and it isn't technical.
Anyone holding a Coldcard Mk3 in 2021 had no way to know the vendor had shipped a defect. No way to verify it. No way out without migrating their entire holdings.
XColdPro turns any USB drive or external SSD into a cryptographically sealed hardware wallet through the BootVault system. ColdGuardian devices exist, but the manual is explicit: they are "a convenience and craftsmanship choice, not a requirement." Entropy comes from your machine, your operating system, your input — not from the sealed firmware of a single manufacturer that nobody outside can inspect.
When trust is distributed across multiple independent sources, no single vendor can fail on your behalf, silently, for five years.
Stay Cold — Stay Secure.
XColdPro is developed by XdRiP Digital Management LLC. Turn any USB into a Hardware Wallet.
April 2026 reminded DeFi of a hard truth: the weakest point is no longer always the smart contract. From Drift to KelpDAO to Purrlend, attackers moved through people, permissions, bridges, and off-chain infrastructure. This is exactly why cold storage must move beyond hardware wallets and hot-wallet convenience.