Your cold wallet policy rests on someone else’s engineering

A firmware flaw in Coldcard let an attacker reproduce private keys offline and sweep the coins those keys controlled. No phishing, no physical access to any device, no mistake in normal use.

Coldcard is a Bitcoin-only hardware wallet made by Coinkite, designed for air-gapped use and bought by holders seeking the most conservative custody option on the market. On the affected firmware, the flaw sat in seed generation, the step every other protection on the device depends on.

By August 3, Galaxy Research’s running estimate had exceeded 1,800 BTC across more than 5,200 addresses, worth roughly $115 million. Transactions were still moving through the mempool when the estimate was published, and the total continued to climb.

The loss traced back to vendor engineering. The firmware defect that made the attack possible had been shipping for more than five years.

Detection would not have prevented this

Range is not a custodian and does not hold keys. As Galaxy Research noted, the attack looked the same as if the owner had chosen to move the coins. The nature of the vulnerability also means that future attacks could target any address generated by an affected Coldcard, and they would not need to follow the same transaction pattern.

The attacker reproduced valid private keys and used them to sign valid transactions. From the network’s perspective, there was no unauthorized instruction to block. The transaction carried the same cryptographic proof as any legitimate transfer from the wallet.

That distinction matters. Monitoring cannot correct a compromised seed or stop a transfer signed with a valid key. What it changes is when the company learns that funds moved, how quickly it can determine which accounts are affected and how soon the response process begins.

Without continuous monitoring, the first signal may arrive during reconciliation, after a custodian review or when someone notices a balance discrepancy. With it, the company can see the outflow while the incident is still unfolding and move from discovery to escalation immediately.

Detection does not turn this failure into a preventable one. It determines whether the company responds in minutes, hours or days.

Cold wallet risk begins in firmware

On affected Coldcard devices, seed generation silently fell back from the dedicated hardware random-number generator to a software-based one. That fallback collected no fresh entropy after initialization, which made its output reproducible once an attacker identified the underlying inputs.

CoinDesk reported on August 1, citing Galaxy Research, that the number of possible keys had fallen to roughly 4 billion. That is small enough to search systematically. The attacker generated candidate seeds on separate hardware, derived the addresses associated with each seed and compared them with addresses on the public blockchain, which anyone can download.

The defect entered the codebase in March 2021 and shipped in released firmware that same month, according to Block’s engineering disclosure. The losses began on July 30, 2026. Affected devices included Mk2 and Mk3 units running vulnerable v4 firmware, along with weaker but still searchable variants affecting Mk4, Mk5 and Q devices.

The default seed-generation process is what produced the vulnerable keys. Coinkite said owners who had added at least 50 private dice rolls were not exposed because the device incorporated those rolls into the final output. Owners who followed the standard setup process did nothing wrong.

And unfortunately, there is also no test owners can run to determine whether their seed fell inside the reproducible range. A third-party checker released during the incident could only show whether an address already appeared among those that had been drained. It could identify known impact after the fact, but it could not confirm that an unaffected address was safe.

Coinkite’s CEO accepted responsibility for the firmware bug and said the company’s review process had failed to catch it. The company released emergency firmware for every affected model on July 31, halted shipments, destroyed remaining inventory manufactured with vulnerable firmware and committed to publishing a technical postmortem.

The patch protects seeds generated after the update. It cannot restore the security of a seed created on vulnerable firmware. Owners seeking incident guidance should follow Coinkite’s official advisory.

Crypto treasury vendor risk does not stop at self-custody

The reported scope expanded within a day. Early reporting focused on Mk3 devices, while Block’s engineering disclosure later identified affected versions across Mk2, Mk3, Mk4, Mk5 and Q models.

That widening scope shows the limit of vendor diligence. A questionnaire can establish how a vendor reviews code, responds to incidents and documents its controls. It cannot prove that every line of firmware is correct or that every hardware component behaves as intended.

Cold storage keeps the key offline, while seed generation still runs on vendor code the owner never sees.

The same dependency runs through every custody model. A key held by a custodian or an exchange sits inside another company's prevention system, and a finance team cannot inspect the components that generate and hold it.

Hybrid custody changes how responsibilities are distributed. It does not remove the underlying dependence on third-party engineering.

Treasury policies leave detection underdefined

Internal-control frameworks separate preventive controls from detective controls. Preventive controls are designed to stop an event. Detective controls reveal that an event has occurred.

Digital-asset treasury policies usually describe prevention in detail. They specify:

• air-gapped key storage
• multisig thresholds and signer counts
• passphrase and key-ceremony requirements
• hardware vendors and device models
  

Each decision depends on software or hardware you did not build. Selecting a reputable vendor can reduce risk, but the control still rests on the vendor’s engineering.

The detective side is usually less developed, even though the company controls it directly. A working detection policy has to answer five questions:

• Which addresses and accounts are in scope?
• What qualifies as an authorized outflow?
• Who receives the alert?
• What action must that person take?
• How quickly must they respond?

Monitoring software cannot answer those questions for the company. The finance team still has to define the rules, assign ownership and decide what happens after an alert.

This gap is structural. Preventive controls are often tied to a purchase, so the policy records the vendor, device and configuration. Detective controls depend more heavily on internal decisions, which makes them easier to leave vague.

What detection changes in practice

The first confirmed wave moved 1,082.65 BTC from 1,196 addresses between 01:10 and 01:51 UTC on July 30, a window of roughly 41 minutes, according to The Block’s report on Galaxy’s findings.

The reported total changed quickly as researchers identified more waves. CoinDesk estimated the loss at nearly $38 million on July 31. Later that day, The Block reported more than 1,000 BTC worth approximately $70 million. By August 2, CoinDesk reported that the observed total had reached 1,367 BTC across 4,585 addresses, worth nearly $89 million. A separate chain-analysis tracker, coldcard.rip, counted ten waves in its August 3 snapshot. It recorded 1,433 BTC taken from 5,477 addresses, worth close to $91 million.

The changing figures matter because the first published total did not describe a completed incident. Later waves reached thousands of additional addresses, collected smaller balances and used different transaction patterns. An address did not need to appear in the first wave to be vulnerable. The same flaw could enable future attacks with entirely different transaction patterns.

Some holders had a response window measured in minutes while sweep transactions remained unconfirmed. That window existed only before settlement and only for an owner who was already monitoring the address.

Detection could not prevent the seed from being reproduced or invalidate a transaction signed with the resulting key. It could determine whether the owner saw the outflow while the incident was still unfolding or discovered it later through reconciliation.

Four treasury controls a finance team owns outright

A finance team can define and operate the following controls under any custody model. None depends on a specific device, chain or provider.

1. Maintain a complete account inventory

Record every self-custodied wallet, custodian sub-account, exchange deposit address and bank account. The inventory should be current and available before an incident begins.

2. Monitor every account continuously

Treasury activity should surface when it happens. A monthly reconciliation or periodic dashboard review is too slow for an incident that develops over minutes or hours.

3. Define authorized outflows in writing

Specify the approved amount, destination, signer and time window. A transfer outside those conditions should generate an alert immediately. For example, a large treasury outflow at 9pm on a Sunday should be evaluated when it occurs rather than during the next close.

4. Screen destinations

As of August 2, Galaxy Research had reported roughly 600 suspected attacker addresses to federal investigators, compliance companies and cross-industry cyber investigators. That information only becomes useful when destination checks are part of the payment process.

These controls become a functioning system when each rule is documented, assigned to an owner and connected to a response procedure.

Where Range fits

Range is the platform for companies operating across stablecoins and fiat. The parts of this problem Range addresses are account inventory, continuous monitoring, outflow rules, destination screening and escalation.

Range is not a custodian and does not hold private keys. Its controls would not have corrected the firmware defect or prevented an attacker from signing transactions with reproduced keys.

Unify connects wallets, custodians, exchanges and bank accounts into one real-time ledger. That gives finance teams a complete inventory before they need to investigate an incident.

Protect continuously monitors custody, FX, chain and counterparty exposure through more than 500 configurable rules. It also applies policy-aware controls based on a company’s governing documents. Onchain controls can run before execution, while bank-account activity can trigger alerts when it falls outside policy.

Transaction Screening checks payment destinations against sanctions lists, blacklists and fraud signals before a transfer is approved.

Range also integrates with the compliance tools a company already uses, adding the treasury context required to connect account activity, counterparty risk and internal policy.

These controls do not remove vendor risk. They reduce the time between an unauthorized outflow and the company’s response.

What remains your responsibility

Your custody vendor's bug becomes your loss. You experience the incident, you answer for it internally, and you have to find it yourself, even though a vendor caused it.

Detection is the one layer a finance team controls from definition through escalation, which is why it cannot be a single line in the policy.

If your policy names a device model, a signer count and a storage location but does not say which outflows would raise an alert tonight, it specifies prevention without specifying detection. Get in touch, and we will go through your address inventory and your outflow rules with you.