40 bits: what the Coldcard failure reveals about trust in Bitcoin self-custody

Drafted on Friday evening (Pacific time), 31 July 2026. This incident is developing rapidly: loss totals, entropy estimates for later devices, and attacker attribution have all shifted materially within the first 48-hours and will continue shifting.

Introduction

Between 01:31 and 01:56 UTC on July 31, 2026, an attacker swept roughly 594 BTC – about USD $38 million – from approximately 500 single-signature Bitcoin wallets, compressing 1,324 separate outputs into 500 transactions across a three-block window before consolidating 562 BTC into a single address that has not moved since.

That opening sweep is no longer the whole event. Within 24-hours, on-chain analysts tracking the incident reported total losses above 1,100 BTC and climbing, with transaction fingerprinting indicating multiple distinct actors – possibly including self-described white hats sweeping vulnerable funds in order to return them – now racing through the same candidate seed space.

Every victim wallet traced so far shares one property: its seed was generated on a Coldcard hardware wallet running firmware released between March 2021 and the device line's final supported version.

Nothing about Bitcoin's cryptography failed. The mathematics that secures a properly generated seed remains intact and no amount of computing power available to any attacker threatened it.

What failed was an implementation's promise to deliver that mathematics: the failure was silent for more than five years in fully open-source code.

The questions raised by the incident are institutional, not just cryptographic, and they concern how trust is allocated in self-custody arrangements, how AI-assisted code analysis changes the economics of vulnerability discovery, and what storage architecture remains defensible when any single vendor's adequacy claim can turn out to be false.

I work through the mechanism, the scale of the entropy collapse, the attacker's observable behavior, and the design decisions beneath the bug. I close with specific guidance for Coldcard owners and a set of falsifiable propositions about where custody security is heading.

What broke

Coldcard devices contain a dedicated hardware random number generator (RNG), the component that justifies much of a hardware wallet's price premium. Seed words are supposed to be derived from that generator's output, which draws on physical noise sources and delivers the 128-bits of unpredictability that a 12-word seed phrase implies.

In March 2021, a firmware change rerouted the seed-generation call through a supporting library whose build configuration tested whether a hardware RNG flag was defined rather than whether it was enabled. The flag was defined and disabled, so the check passed and the code fell back to MicroPython's non-cryptographic software generator, seeded from the device's unique identifier, timer registers, and call history – values that are not secret and that a patient attacker can reconstruct or enumerate.

The consequence was an entropy collapse that no downstream process could repair.

On Mk3 devices, the population hit first, effective entropy fell to somewhere between 32- and 40-bits – the vendor's analysis says roughly 40, while independent analysts working the incident put it nearer 32; the difference is immaterial, since either space easily yields to consumer hardware. Whether end-of-life Mk2 units ever ran the affected firmware is disputed, with written advisories including them and some analysts excluding them - I just flag that rather than resolve the conflicting views.

The figures for later devices (Mk4, Mk5, and Q) diverge more consequentially. An independent Bitcoin Core developer reproduced key aspects of the flaw on a fresh Mk3 within a day of disclosure, confirming the Mk2/Mk3 vulnerability while expressing uncertainty about Mk4. The same broken generator fed Coldcard's paper wallet feature, where its output becomes the private key directly, along with seed-splitting masks, device-cloning keys, and Key Teleport transfers, so the exposure extends beyond seed phrases.

These later devices mixed in additional material from their secure elements and the vendor-linked accounting implies roughly 72-bits of effective entropy, because the reseed process truncated the secure-element contribution to about 32-bits; industry estimates circulating among incident responders run far lower, at 45- to 50-bits (see the 31 July 2026 What Bitcoin Did podcast with Rob Hamilton).

The gap between those numbers is the gap between a space no attacker can economically search and a space a well-funded GPU farm clears in days, Prudent guidance has to follow the lower bound.

Two properties of this failure deserve emphasis because they generalize. First, the failure was undetectable by any user-facing observation: the device worked, the seed words looked normal, and the firmware's own randomness health check was trivially passed by the degraded generator.

Second, the bug sat in public, auditable, open source code for over five years, through a period in which Coldcard was widely regarded as the security-maxi choice among hardware wallets (I own a Mk4 myself) and its codebase attracted more expert attention than most.

The scale problem

Communicating what "40-bits instead of 128-bits" means is harder than it sounds because human intuition treats exponents linearly. A layperson who encounters "72 versus 128" tends to register something like half the security. The reality is that each additional bit doubles the search space, so the difference between 72- and 128-bits is a factor of 2^56 (2 x 2 x 2... x 2, 56 times in total) and the difference between 40 and 128 bits is a factor of 2^88, a number without any useful human comparison.

A chessboard helps make the scale tractable. Imagine that recovering a wallet's seed means finding one marked square on a board, where every square is a candidate seed and the attacker can check squares mechanically. A standard 8 x 8 board holds 64 squares in total.

The exploited Mk3 seed space – at most 40 bits, and by some estimates as few as 32 – requires a board no more than about one million squares on each side. At standard tournament dimensions of roughly six centimeters per square, that board measures at most about 60 x 60 kilometers square (for Americans, about 1370 square miles), roughly the footprint of a large metropolitan area. The lower estimate shrinks to the footprint of a small town. The challenge seems enormous to a human but is no obstacle at all to a computer checking a billion squares per second. That laptop clears the city-sized board in under 20 minutes and the town-sized one in seconds.

The 128-bit board that users believed they held requires about 18 quintillion squares per side; at the same square size, each edge runs roughly 100 light-years, a board extending past hundreds of neighboring star systems. No machine, and no fleet of traditional (non-quantum) machines running for the lifetime of the universe, searches that board.

Coldcard's firmware bug replaced the light-years board with the city-sized one, yet both boards produce identical-looking seed words.

The board occupied by pre-fix Mk4, Mk5, and Q seeds sits between these and its true size is the incident's most consequential open question. The vendor-linked accounting implies a 72-bit board whose edge runs about 70-million kilometers, roughly half the distance from Earth to the sun – beyond any current attacker's economic reach.

Independent estimates of 45- to 50-effective bits imply a board whose edge runs a few hundred to a couple of thousand kilometers: the scale of a country rather than a solar system, and a space that a funded GPU farm clears in days once the seeding inputs are understood. The first attacker skipped these devices, which tells us only that the Mk3 board was easier, not that the more recent wallets are safe. Either way, the middle board is at least 2^56 times smaller than the board the product promised (and boards do not grow while compute gets cheaper).

Precision on this point matters because much of the commentary has blurred it in both directions. The wallets drained in the opening sweep held Mk3 seeds at the bottom of the range; the later devices were not touched in that wave. But the early framing that treated Mk4-generation seeds as safely out of reach depends on the higher entropy estimate holding, and the incident-response community's lower estimates place those seeds within reach of well-capitalized attackers who are now likely active at scale.

The defensible statement is narrower than either extreme: the middle-board devices were not the low-hanging fruit and no owner of a pre-fix seed on any Coldcard model should treat that as more than a head start.

The attack as economic behavior

The first attacker's observable conduct is consistent with a straightforward workflow, though not an especially polished one. Once the degraded generator's seeding inputs were understood, the candidate seed space could be enumerated offline; standard derivation paths convert each candidate seed into addresses; and the public blockchain converts each address into a balance.

Investigators confirmed that the attacker used a paid account at a commercial blockchain data service, presumably because checking millions of candidate addresses efficiently requires bulk indexed access. The batch execution – 500 transactions in three blocks – confirms a precomputed target list rather than sequential discovery.

The on-chain heuristics, however, point to an amateur rather than a nation state-grade operation: the sweep applied a crude floor of roughly 0.15 BTC per address, leaving smaller balances untouched at no saving in cost; and the address-scanning logic stopped at the first unused address in a derivation sequence, so some victims retained funds sitting beyond the scanner's gap limit. A disciplined operator would have taken everything.

That sloppiness matters because the first actor no longer has the space to themselves. Within a day, transaction fingerprinting distinguished multiple attackers running the same enumeration with different wallets, different floors, and progressively better scanning – alongside self-described white hats sweeping vulnerable funds in order to return them to owners.

The correct model is no longer a single perpetrator whose identity is in question but an open race through a published search space, in which the residual funds the first attacker's crude filters missed are being collected by followers with better code. This is also why the disclosure changes little for victims: the starting gun fired when the sweep became visible and every subsequent actor's marginal cost is falling as tooling circulates.

The multi-actor reality reframes the identity question. My initial analysis - not online - treated criminal, white-hat, and autonomous-AI hypotheses as competing explanations of one actor; they are, however, better read as descriptions of different actors now operating in parallel, and the key questions attach to the largest consolidated haul from the opening sweep.

For that actor, 'the ordinary criminal' hypothesis predicts long dormancy followed by fragmentation through mixing services and low-visibility venues, on a timescale of months to years; under this reading the paid data-service account may be a significant operational error, since commercial services retain payment and access records that now constitute the most promising investigative thread.

The white-hat hypothesis predicts prompt contact with the vendor or a public commitment to return funds – behavior that may already have been observed for some smaller sweep clusters, which raises hope for benign explanations generally while every day of silence lowers it for the opening actor specifically.

The autonomous-AI hypothesis remains the weakest: whatever role AI tooling played in finding the bug, the execution chain required purchasing an API account, funding fees, constructing and broadcasting valid transactions, and consolidating proceeds to a controlled destination, and each step implies an operator with intent and a wallet. The realistic AI story is mundane – humans using AI-assisted analysis as a force multiplier – and the more exotic version should be treated as unsupported until someone produces evidence that survives scrutiny.

Movement of the consolidated funds toward mixing infrastructure would confirm the first hypothesis; a verifiable return announcement confirms the second; and the subpoena trail through the commercial data service bears on all three. As of this writing, the coins from the first sweep have not moved. Stillness is equally consistent with patience and with conscience. Only the next move distinguishes them.

The institutional layer

One second-order effect deserves flagging before the design analysis: commentary since the sweep has framed the incident as evidence that self-custody's technical burden will push ordinary holders toward exchanges, custodians, and ETFs.

That trade – custodial convenience purchased at the price of exit capacity and governance agency – is the subject of Chapter 5 of my book draft, and the Coldcard failure will serve as a recruiting event for the custodial side of that paradox regardless of whether the inference is sound.

The design decision beneath the bug matters more than the bug. Coldcard's RNG subsystem was built to fail open: when the hardware generator's output stopped reaching the seed-generation path, the system substituted weaker randomness and continued, rather than halting. Security-critical systems should fail loudly or fail closed because a randomness subsystem that can degrade silently converts a component fault into a total security failure with no observable symptom.

Block's engineering analysis, published within hours of the sweep, characterized the later devices' entropy construction in exactly these terms, and the criterion it implies goes well beyond this incident. When evaluating any custody tool, the question worth asking alongside "is the design sound" is "if a critical component fails, does the system halt or does it lie?"

The five-year audit failure carries its own lesson about open source. The many-eyes argument for open source security has always depended on scrutiny actually occurring but expert code review is expensive enough that scrutiny is rationed toward new code, popular attack surfaces, and known bug classes. A macro misconfiguration in an already-build path, producing no functional difference in observable behavior, sat below that threshold for half a decade.

Coinkite itself reports having run a leading AI model over the code weeks before the incident without the bug being flagged and it now assumes an attacker's AI-assisted review found what its own review missed. Both claims are plausible and neither is verified but the vendor's framing deserves the skepticism it has received, since attributing the discovery to a new AI paradigm partially mitigates a 5-year failure of conventional review.

What is not in dispute is the direction of travel:

• the cost of systematically scanning every open-source wallet codebase for known error classes is collapsing;
• the scanning is asymmetric because an attacker needs one exploitable flaw across the ecosystem while each defender needs to find every flaw in their own code; and
• any latent bug of this class in any wallet should be assigned a much shorter life expectancy than the five years this one enjoyed.

The five-year gap between the bug's introduction and its recognition is a clean instance of what I call institutional latency in Chapter 2 of my book draft. The AI-driven compression of that gap – for attackers and defenders – is the new normal for Bitcoin.

On vendor accountability, the documented record supports specific criticism and does not support the conspiratorial version circulating on X. Coinkite's disclosure was fast, its CEO took direct personal responsibility in plain language, and emergency firmware shipped within a day. Those are better crisis responses than one might expect in the Bitcoin industry.

The record also shows that the Mk4 redesign added secure-element mixing that happened to partially mask the underlying flaw while truncating the added entropy to 32-bits, that the company's own advisory concedes the later devices never restored the 128-bit target, and that the recommended backstop against RNG failure – 50 or more user-supplied dice rolls – is a procedure most users predictably skip, a point competitors have made sharply and fairly.

Claims that the vendor knowingly shipped weak entropy rest, so far as I can tell, on resurfaced social media fragments whose content and dating I have not verified. The design-philosophy critique stands on its own and needs no foreknowledge claim to carry weight.

This is a genus, not a species

The Coldcard failure is the newest member of a well-populated family. Android's 2013 RNG weakness compromised Bitcoin wallets generated on affected handsets, and the Trust Wallet browser extension generated seeds from roughly 32 bits of entropy in a browser environment whose randomness source was inadequate. The Libbitcoin Explorer tool seeded wallets from a 32-bit timestamp, a flaw discovered in 2023 after years of silent exposure and millions in losses. The Profanity vanity-address generator's weak seeding was exploited for nine figures in 2022.

In every case the anatomy is identical:

• the code calls a randomization function;
• the call succeeds;
• the output looks normal;
• nothing downstream can detect the deficiency; and
• discovery arrives through audit or through theft.

Entropy generation is the single point in the custody stack where a silent failure is both catastrophic and invisible, and the historical base rate says the appropriate prior on "some other major wallet currently has an equivalent live flaw" is not low.

Bitcoin's public ledger gives this failure class a property that distinguishes it from most security vulnerabilities: weak keys never expire. A patch closes the generation-time flaw for new seeds and does nothing for existing ones, and the attacker's precomputed table of funded addresses is a standing harvest list.

Coins migrated to sound seeds today are safe; coins whose owners never hear the news remain at risk indefinitely and can be targeted at the attacker's leisure. Storage security must therefore be evaluated against the strongest attacker over the coin's entire dormancy period rather than against current capability, which for cold storage measured in decades is a demanding standard.

The Coldcard sweep is, in this respect, a small-scale rehearsal of the migration problem I analyze in Chapter 6 for the quantum threat: in both cases key material becomes retroactively unsafe, protection requires holders to act on information many will never receive, and the unreachable tail of dormant coins sets a floor on eventual losses that no patch can lower.

Some falsifiable propositions

Given the current state of affairs, I offer four propositions about the next several years that the record can confirm or refute.

1. The interval between a wallet vulnerability's introduction and its discovery will compress sharply. The Coldcard bug survived five years; the combination of AI-assisted review by attackers and, in response, continuous automated auditing by vendors and researchers should cut comparable intervals to weeks-to-months.
2. At least one additional entropy-class vulnerability will be disclosed in a widely used wallet, hardware or software, found by audit rather than by theft.
3. The consolidated Coldcard funds will move toward obfuscation infrastructure rather than restitution. This is the 'ordinary criminal' hypothesis stated as a prediction and it fails cleanly if the funds are returned or if a credible white-hat claim with proof of address control emerges.
4. The incident will shift observable custody behavior toward architectures robust to single-vendor failure – measurable in multisig adoption rates among self-custody users, in vendor support for user-supplied entropy as a default rather than an option, and in explicit fail-closed commitments in security documentation.

I regard this fourth proposition as the least likely to hold because convenience defaults have repeatedly beaten security recommendations in every prior cycle, and that track record is itself the strongest argument for building storage that does not depend on users behaving unusually.

What Coldcard owners should do now

Triage turns on seed provenance rather than on the device currently holding the seed. The flaw travels with the seed: what matters is the device and firmware version at the moment of generation, including seeds generated on a Coldcard and later imported into other wallets or devices.

• If your seed was generated on a Mk2 or Mk3 running firmware 4.0.x through 5.0.3, without dice rolls and without a BIP-39 passphrase, treat it as actively compromised and migrate immediately! Follow the vendor's published sequence: update firmware first, generate a new seed on fixed firmware, back it up, power-cycle and verify the wallet fingerprint and a receive address, send a small test transaction, and then move the balance.
• If your seed was generated on a Mk4, Mk5, or Q before the emergency firmware (5.6.0 for Mk4/Mk5; 1.5.0Q for Q), it carries roughly 72-bits of entropy. It was not swept and it may not yet be practically searchable today (but check out today's What Bitcoin Did interview with Rob Hamilton - if there is 45- to 50-bits of entropy, as he argues, it could be vulnerable within days). If it indeed carries 72-bits of entropy, it is still far below specification for storage intended to outlast falling compute costs and is subject to possible attack in the next few years. Migrate on a prompt, unpanicked timeline to a seed generated on fixed firmware (August 1 update: there have been some losses reported from Mk4 devices - prudence would suggest getting all Bitcoin should be migrated asap).
• If your seed was generated with 50 or more independent dice rolls, or is protected by a strong, unique BIP-39 passphrase, you are substantially protected against this specific flaw. Migration remains cheap insurance.
• TAPSIGNER, OPENDIME, and SATSCARD run different codebases and are unaffected.

Whatever your device, treat the migration process itself as a risk surface. Incidents like this one attract fake firmware, phishing disguised as help, and pressure to act fast; use official sources only, verify firmware signatures, never enter seed words into any internet-connected device, and prefer careful execution over speed.

The structural lessons apply beyond this vendor. User-supplied entropy at generation removes the device's RNG from the trust base entirely. A strong passphrase adds an independent secret that survives full recovery of the base seed. Multisig with wallets from different vendors removes any single codebase from the set of single points of failure; throughout this incident, multisig arrangements containing one sound key were sufficient protection.

For anyone that may be thinking about estate planning, make sure your family does rehersals and knows how to use the somewhat more complex security practices that will become the new normal.

The question this hack answered was never whether a particular device was safe. It was what happens when a device you trusted turns out not to be; the correct architecture has always been the one in which that question does not matter.