A programming flaw in Coldcard devices: $70 million in bitcoin stolen

The flaw, present for over five years, made the keys generated by Coinkite’s hardware wallets vulnerable and allowed funds to be withdrawn without ever touching the devices. The attack does not appear to depend on users’ operational errors. CheckSig: custody security must be verifiable by independent third parties.

Milan, July 31, 2026 - On July 30, in a 41-minute window, an attacker drained 1,196 Bitcoin addresses holding 1,082.65 BTC (approximately $70 million) protected by Coldcard hardware wallets, without resorting to phishing, malware, or physical access to the devices. A firmware flaw present since March 2021 weakened the randomness with which the devices generated the seed, the cryptographic secret from which private keys are derived, making those keys reconstructable remotely. Coinkite, the Canadian manufacturer, published a security advisory, acknowledging the flaw and distributing corrective firmware, but had to clarify that the update does not remedy seeds and keys already generated.

Ledger, the leading hardware wallet manufacturer, stated that it is not impacted by the problem, pointing to the certified random number generator embedded in its secure element; similar clarifications were issued by Trezor, Block, and other manufacturers.

The incident

The cause is not a cryptographic attack but an implementation error: seed generation drew randomness from a software fallback function instead of the device’s hardware random number generator. Sources diverge on the origin of the regression. Coinkite’s advisory identifies as vulnerable the Mk3 from version 4.0.1 to 4.1.9; Block’s independent analysis traces it back to version 4.0.0, released on March 17, 2021, and also includes in its scope the Mk2, which the manufacturer’s advisory does not mention.

The stolen bitcoin were consolidated within minutes into four addresses. Clay Garrett, of Block, stated that he had identified the paid account at a well-known blockchain data provider used by the attacker to query the source addresses during the withdrawals; the provider’s internal logs match the hypothesized workflow in the number, timing, and sequence of requests, and the evidence has been handed over to the authorities.

”It will be interesting to follow on the blockchain the traces of what was stolen: laundering those bitcoin will not be easy. These are significant sums of documented origin, associated with a known event, on addresses the entire industry is monitoring; any attempt to put them into circulation through regulated operators will run into anti-money-laundering controls”, observes Ferdinando Ametrano, CEO of CheckSig.

Guidance for Coldcard owners

Anyone who generated their keys on vulnerable firmware must necessarily transfer their funds to a secure destination. Unfortunately, no test exists that, by examining the seed alone, can certify after the fact the randomness (more properly, entropy) used during setup: for this reason, all affected or at-risk users must make this transfer. Updating the device is not enough, and transferring a weak seed to any other device, even from another manufacturer, does not fix its weakness.

CheckSig can offer its services to anyone facing difficulties on this point.

The limits of self-custody

The incident reopens the debate on the limits of self-custody. ”Self-custody transfers control to the investor, but also the technical and operational risks the investor is often in no position to manage: ‘your keys, your coins’ then becomes ‘your keys, your problems’. The problem is not self-custody, which must always remain possible, but the idea that holding the keys automatically equals security. The affected users did nothing wrong: they have our solidarity, as do all savers forced to assess what they lack the technical expertise to assess. Better, then, to rely on professional custody with no single points of failure, with documented controls, independently verified, contractual liability and insurance coverage: it cannot eliminate every risk, but it governs them effectively”, comments Ametrano.

Entropy must be independent of the device

Coinkite noted that users who had added at least fifty independent dice rolls during setup would have obtained robust seeds despite the flaw: randomness of external origin would have compensated for the device’s weakness.

”The entropy used to generate a seed should not depend on the device that holds it. If the device’s internal generator is the only source of randomness, it becomes a single point of failure: a flaw weakens its output without any subsequent check being able to reveal it, because a weak key is indistinguishable from a strong one until the moment someone takes advantage of it. A sound procedure combines entropy from sources independent of the device, within formalized procedures, with segregation of duties and independent controls over the related processes, as we do at CheckSig”, explains Paolo Mazzocchi, chief operating officer of CheckSig.

The CheckSig custody setup

In CheckSig’s custody setup, every device is initialized with external, independent entropy: precisely the condition that, in this incident, would have protected users who had added dice rolls. The infrastructure also employs devices from different manufacturers and combines manufacturers’ firmware with proprietary firmware: a flaw in a single implementation cannot compromise the keys as a whole.

Moreover, in CheckSig’s custody protocol, public and documented, no single key allows disposal of the funds: transaction signing requires three distinct multi-signature authorization stages, for a total of eleven keys. Unlike single signature, multi-signature eliminates the on-chain exposure of the cryptographic information an attacker would in any case need to collect to work back to the private keys. All the addresses hit in the incident were in fact single-signature.

In addition, the two-tier architecture forces an initial transfer from the frozen tier to the cold tier and imposes time locks on the cold tier that prevent the immediate transfer of funds, leaving time to detect an attempted theft and intervene.

Finally, the public proof-of-reserves demonstrates control of on-chain assets and their consistency with the declared evidence; the SOC 1 and SOC 2 Type II attestations are issued following independent audits of the controls and of their operation over the period examined; insurance coverage adds guarantees of restitution.

In any event, CheckSig does not use Coldcard: none of the keys in custody was generated on a device made by Coinkite. Even in that case, however, the safeguards described would have secured the funds independently of the firmware flaw.

”We do not promise the infallibility of a device, a key, or a person: we build custody in which none of these elements, on its own, is sufficient to move funds, in which the failure of any one of them can be detected and in which controls are carried out by independent parties. Ours is a verifiable promise”, concludes Ametrano.

Sources

• Coinkite, security advisory on seed generation: blog.coinkite.com
• Block, Predictable RNG fallback and 32-bit reseed in Coldcard firmware: engineering.block.xyz
• Galaxy Research, on-chain reconstruction of the flows: x.com/glxyresearch
• Clay Garrett (Block), tracing of the operator: x.com/clay_garrett
• Ledger, statement on its devices: x.com/Ledger
• Chainalysis, on-chain analysis of July 31: x.com/chainalysis
• Trezor, statement to its users of July 31: x.com/trezor
• K33 Research, Funds at risk: Coldcard’s randomness flaw: k33.com
• CheckSig: custody protocol, proof-of-reserves, SOC attestations

Download the press release