The Attack That Never Touched a Device

On July 30, 2026, roughly 594 BTC moved out of approximately 500 single-signature Bitcoin addresses in under half an hour. By August 2, after a third attack wave, on-chain researchers at Galaxy were tracking 1,367 BTC, approximately 88.6 million dollars, drained from 4,585 addresses. Every affected address was created after the vulnerable firmware shipped in March 2021, and every stolen coin still sits unspent under the attacker’s control. The same day, Coinkite published a security advisory warning that seeds generated on Coldcard Mk3 devices running firmware 4.0.1 through 5.0.3 may be at risk, and Block’s engineering team published an independent root-cause analysis.

The technical failure is now well documented: a macro check in a firmware dependency silently routed seed generation to a deterministic software fallback instead of the hardware random number generator. Seeds that should have carried 128 bits of entropy became computationally enumerable. The attacker reconstructed private keys offline. No device was touched. No user was phished. No storage was breached.

Coinkite responded with an advisory, emergency firmware, and migration guidance within hours; by July 31 the company had taken full responsibility for the flaw, and its updated advisory extends the risk to seeds generated on Mk4, Mk5 and Q devices before the patched firmware. This piece is not about the vendor. It is about what the incident structure reveals, because the structure will repeat.

The failure lived in the key’s birth, not in its storage

Every custody framework we review treats key storage as the center of gravity: which device, which vault, which geography. This incident compromised none of those layers. The wallets were cold. The devices were offline. The seeds were never exposed.

The vulnerability lived in the key’s provenance: the firmware version running at the moment the seed was generated, years before the theft. Exposure was determined by an event in the past that most holders never recorded and cannot reconstruct. Upgrading firmware afterwards neither repaired nor weakened an existing seed.

This is the first governance lesson. Key provenance is auditable metadata: which device family, which firmware version, which generation method, at which date. A custody policy that does not record provenance cannot answer the only question that mattered on July 30: “was this seed generated inside the vulnerable window?”

What survived was policy, not hardware

Look at who was not draining coins that morning. Per the advisories, holders who applied a BIP-39 passphrase face limited exposure. Holders who generated entropy with dice bypassed the vulnerable code path entirely. And holders whose funds sat behind a multisignature quorum that included at least one device from a different vendor were protected by construction: as Block’s analysis notes, a quorum composed exclusively of vulnerable devices inherits the vulnerability, while a quorum of heterogeneous devices does not.

None of these are hardware properties. All three are policy decisions: an extra entropy factor, an independent entropy source, and vendor diversity inside the quorum. The holders who survived did not pick a better device. They picked a policy that did not depend on any single device being correct.

This is the doctrine we build on: hardware fails silently, policy fails loudly. A well-composed policy converts a catastrophic single-vendor failure into a non-event.

The measurability gap

The most uncomfortable sentence in the entire disclosure cycle is this one: there is no test an owner can run against their own wallet to determine whether their seed sits inside the reproducible range. Affected holders must assume the worst rather than verify it.

That is the real crisis, and it is larger than any one firmware bug. Self-custody as commonly practiced is unmeasurable. Holders cannot score their own exposure to vendor concentration, cannot prove their inheritance policy survives a key loss, and cannot demonstrate to a spouse, an heir, or an auditor that the setup works. Security that cannot be measured can only be believed, and July 30 is what belief looks like when the assumption underneath it fails.

What a governance layer does with this

A governance layer above the vault, holding no keys and favoring no vendor, treats this incident as a scenario class rather than a news item:

Quorum composition scoring. How many distinct vendors, firmware lineages, and entropy sources participate in the spending policy? A 2-of-3 across one vendor is one failure away from a 0-of-3.

Key provenance as first-class metadata. Generation date, device family, firmware version, and entropy method recorded per key, so that when the next advisory lands, exposure is a query, not a panic.

Policy validation under compromise scenarios. The question “is this policy still satisfiable if every key from vendor X is presumed compromised?” is a deterministic, answerable question. It should be answered before the advisory, not after.

None of this requires trusting a platform with keys. It requires treating custody as a governed system with measurable properties instead of a collection of devices with reputations.

The pattern will repeat

This is not the first silent device-integrity failure in Bitcoin custody, and the disclosure history of the hardware wallet industry as a whole says it will not be the last. The vendors are not the problem. Concentration is. Any security model whose failure mode is “one vendor’s firmware was wrong for five years” is carrying a risk it has never priced.

The holders who were fine on July 30 were fine for a reason they could have written down in advance. That is the standard: custody governance means being able to write the reason down before the incident, and prove it after.