The Coldcard Hack: When an Air-Gapped Wallet Generated Predictable Keys

For years, the safest advice in Bitcoin sounded almost too simple:

Take your coins off the exchange. Put them on a hardware wallet. Keep the seed phrase offline.

Then Coldcard—an air-gapped, Bitcoin-only hardware wallet built for people who take self-custody seriously—became the center of a nightmare.

Beginning on July 30, 2026, attackers started sweeping funds from wallets whose owners had done exactly what the security community told them to do. Early reports described more than 1,000 BTC disappearing in the first wave alone, followed by additional thefts over the weekend. The total remains fluid as researchers continue tracing addresses and separating related attacks.

There was no malware on the victims' laptops. No fake support agent. No phishing link. No attacker standing over anyone with a lead pipe.

The weakness was already inside the wallet.

More precisely, it was inside the process that created the wallet's seed phrase.

The Seed Phrase Is the Wallet

A Bitcoin wallet does not really hold coins. It holds the private keys that authorize spending them.

Most hardware wallets derive those keys from a recovery phrase—usually 12 or 24 words generated when the device is initialized. Anyone who knows that phrase can recreate the wallet and spend its funds from somewhere else.

That is why randomness matters.

A properly generated 12-word BIP-39 phrase starts with 128 bits of entropy. The number of possible phrases is so large that brute-force guessing is not merely inconvenient; it is functionally impossible with today's computers.

But that security guarantee depends on one condition:

The wallet must actually generate unpredictable entropy.

Hardware wallets normally use a true random-number generator built into the chip. Rather than inventing numbers through a repeatable formula, the hardware samples physical noise from the real world and turns it into cryptographic randomness.

Coldcard had that hardware.

The vulnerable code path did not use it.

One Macro, Two Meanings

The failure came from an integration mistake between Coldcard's firmware, MicroPython, and a cryptographic library called libngu.

Coldcard provided its own wrapper for the chip's hardware random-number generator. Because of that, its board configuration set MicroPython's built-in hardware-RNG option to zero:

#define MICROPY_HW_ENABLE_RNG (0)

The intention was reasonable: disable one implementation because the firmware supplied another.

The problem was how libngu checked the setting.

It effectively asked whether MICROPY_HW_ENABLE_RNG was defined. The macro was defined, so the check passed—even though its value was zero.

MicroPython, meanwhile, checked the value. Seeing zero, it compiled a software fallback instead of the STM32 hardware implementation.

Both paths exposed the function name the cryptographic library expected. The firmware built successfully. Nothing crashed. Seed phrases appeared normal.

But calls that were supposed to reach genuine hardware randomness were resolving to MicroPython's deterministic Yasmarang generator.

The distinction between “defined” and “enabled” became the difference between an astronomical search space and a tractable attack.

Random-Looking Is Not Random

A pseudorandom generator can produce output that looks chaotic while remaining completely predictable to anyone who knows its starting state.

That is acceptable for simulations, games, randomized tests, and plenty of ordinary software. It is catastrophic when generating private keys.

The MicroPython fallback initialized itself from values such as the microcontroller's unique ID and timer registers. Those inputs change the output, but they are not secret, high-quality cryptographic entropy. If an attacker can determine or narrow the device ID, timing state, and number of earlier RNG calls, the same output stream can be reproduced offline.

The effect differed across Coldcard generations, according to Block's early technical analysis:

On affected Mk2 and Mk3 firmware, no cryptographically secure entropy was added to this path. With the relevant device state known, wallet generation became deterministic.
On Mk4, Q, and Mk5 devices, secure-element data was mixed in, but the reseed retained only 32 bits. Once the remaining state was constrained, that left at most roughly 4.3 billion securely distinct streams—not remotely close to the expected 128-bit minimum for a 12-word phrase.

Hashing the final output does not repair the problem. A hash can scramble weak input, but it cannot create possibilities that were never present.

If a generator can produce only a few billion candidate seeds, hashing those candidates still leaves only a few billion candidate seeds.

How the Theft Worked

The attacker did not need to touch each Coldcard.

They could generate candidate seed phrases from the reduced state space, derive the corresponding Bitcoin addresses, and compare them with addresses visible on the blockchain. A matching address confirms that the candidate is correct. From there, the attacker has the private keys and can sign a transaction moving the funds.

This is what makes the incident so brutal: the devices themselves did not need to be remotely compromised at the moment of theft. The vulnerable seed had been compromised in principle from the moment it was created.

The first large sweep reportedly prioritized valuable wallets and moved through more than a thousand addresses in less than an hour. Further waves followed as attackers searched the same weak-key space and owners rushed to move anything that remained.

The public blockchain made the damage visible.

It also made the rescue attempts visible.

Victims Had to Race Their Own Keys

A firmware update can correct future seed generation. It cannot make an existing weak seed unpredictable.

Bitcoin also has no “rotate key” button. To escape a compromised seed, the owner must create a new wallet and send the funds to a new address in an on-chain transaction.

But normal Bitcoin transactions are broadcast into a public waiting area called the mempool before a miner confirms them. If an attacker already knows the same private keys, they can watch for a victim's rescue transaction and publish a conflicting transaction that pays a higher fee.

Both transactions spend the same coins. Only one can win.

In practice, victims could find themselves bidding against the thief for their own Bitcoin.

One defensive option is to send the rescue transaction privately to a mining pool instead of broadcasting it across the public peer-to-peer network. If the attacker's bot never sees the transaction in the public mempool, it cannot automatically respond with a higher-fee conflict before the pool mines it.

That creates a painful irony: protecting “trustless” money may temporarily require trusting a centralized mining operator to keep a transaction private and include it in a block.

Updating the Firmware Is Not Enough

This point matters more than anything else in the story:

If a seed was generated through the vulnerable path, installing fixed firmware does not make that seed safe.

The weakness belongs to the seed, not only to the device currently holding it. Importing the same phrase into another hardware wallet changes nothing. The new device will faithfully recreate the same compromised keys.

Owners of potentially affected devices should follow the latest guidance from Coldcard and independent security researchers. In general, remediation means:

Treat the old seed as compromised.
Update to firmware confirmed to fix the generation path.
Generate a completely new seed using a verified-safe process.
Move funds to addresses derived from that new seed.
Verify the destination address on trusted hardware before signing.

Anyone with funds currently at risk should get expert help before broadcasting a rescue transaction. Improvised recovery steps can reveal information, create a public race in the mempool, or move funds to another unsafe setup.

Never enter a real seed phrase into a website, support chat, shared computer, or “checking tool.” A wave of recovery scams almost always follows a wallet incident.

The Real Engineering Failure

It is tempting to describe this as a random-number-generator bug. That is true, but incomplete.

The deeper failure was that a security-critical guarantee existed only as an assumption across multiple software layers.

Coldcard had a hardware RNG. Its firmware had a custom wrapper. MicroPython had a fallback. libngu expected a function with a particular name. Each piece made sense in isolation. Their interaction silently selected the least secure path while still producing valid-looking output.

That is the most dangerous kind of cryptographic failure:

The product still boots.
The wallet still creates addresses.
The seed words still look random.
Transactions still sign correctly.
Every normal functional test still passes.

The system fails only at the property that matters most: whether someone else can predict the key.

A robust design needs more than a secure component. It needs evidence that the production binary actually calls that component, tests that fail when entropy falls below the required threshold, and independent review of the built artifact—not only the source code engineers intended to run.

Air-Gapped Does Not Mean Invulnerable

Air gaps protect against an important class of remote attacks. Open-source firmware makes inspection possible. Secure elements make physical extraction harder.

None of those properties can rescue a predictable private key.

Security is compositional: the final system is only safe if every critical boundary connects correctly. One preprocessor check can bypass an expensive hardware defense. One weak fallback can undermine years of careful operational security. One seed-generation mistake can remain dormant until an attacker finally enumerates the search space.

The lesson is not that self-custody is pointless or that exchanges are automatically safer. It is that self-custody moves responsibility into a stack of hardware, firmware, build systems, wallet software, backup procedures, and human decisions.

“Not your keys, not your coins” remains true.

But after this incident, it needs a second line:

If your keys were predictable, they were never only yours.

Sources and Further Reading

This article reflects information available on August 5, 2026. The investigation and loss estimates may change as additional wallets and transactions are attributed.