Critical Coldcard flaw: what happened, who is affected, and what to do

How to read this VERY LONG blog post:

• the first section covers Liana users, and is interesting to read to multisig users too. They cover risks and actions to take.
• the rest of the article is the technical analysis of the bugs and risks surrounding the attack, incuding in-depth educational content.

If you don’t care about Liana or Multisig and just want to learn everything we know about the attack, skip the first sections.

This blog post was written by 3 people in parallel. Any first person “I, me, myself” is from Kevin Loaec, and may reflect personal preference and opinion not shared by the rest of the team.

Additional images will be added over time, to add clarity

⚠️ Liana users: if you use Coldcard devices in your setup, such that Coldcard devices are sufficent to spend without other keys (for example, a 2-of-3 primary with 2 Coldcards, or even just a single sig Coldcard primay path), you need to move your funds to a new setup.

⚠️ Any Coldcard users: If you generated a seed on a Coldcard since 2021, including models MK2, MK3, MK4, MK5 and Q, you need to move your funds immediately. Wallets are being drained as you read this. Only wallets generated using 50+ fair dice rolls are safe but advanced features of the device are still broken. Wallets from before 2021 are safe.

⚠️ Even if you did not generate your seed on an affected Coldcard, multiple advanced features of the Coldcard devices are broken. Dice rolls do not protect you here.

This article tries to cover as much of the scale of the unfolding situation as possible, including risks that are not yet exploited but imminent (a matter of hours). 1000s of bitcoins have already been drained, and this is only the beginning.

Fixed firmware is out, it DOES NOT save your existing seed and wallets. Coinkite shipped emergency hotfixes on 31 July: version 4.2.0 for the Mk3, 5.6.0 for the Mk4 and Mk5, and 1.5.0Q for the Q. The Edge channel, the experimental builds carrying the X and QX suffixes, has been fixed as well. These correct entropy generation for seeds created from now on. They do not repair a seed that was already generated by affected firmware. A firmware update on its own changes nothing for the coins you hold today.

Section 1: Liana, Miniscript and Multisig - you are potentially at risk

If none of your key was generated on a Coldcard, you are safe. If any of your key was generated on a Coldcard, or coming from a mnemonic initially generated on a Coldcard, you may be at risk.

A Liana wallet spends through independent paths, the one thing that decides your risk is whether any single spending path can be satisfied with affected keys alone. A path falls the moment enough of its keys are weak to meet its threshold. A “primary path” is the non-timelocked spending condition of Liana.

If your primary path can be met with affected Coldcard keys alone, move your funds while following the migration steps below. If only a recovery path can, move quickly but the timelock protects you.

⚠️ Before moving funds, read the WHAT DO I DO AS A LIANA USER? at the end of this section. It’s important.

If you use the “Simple inheritance” setup

One key you use day to day, and a second key usable only after a delay, meant as a fallback or for an heir. Each path is a single key, so there is no threshold to protect you: one affected key breaks that path.

Because inheritance setups are often left untouched for long stretches, the recovery-key case is not hypothetical: it becomes a risk for dormant, long-untouched wallet. Every time the coins move, the delay resets, which keeps that path shut until you can migrate.

If you use the “Expanding multisig” setup

Two keys are needed to spend day to day, and any two of three keys (your two everyday keys plus a recovery key) after a delay.

In any case, if any Coldcard was used, plan to move to a new setup even if not at immediate risk.

The general rule, for any Liana setup

For a custom policy, apply the same test path by path: a path is spendable by an attacker when the number of affected keys in it reaches its threshold. Two things then decide where your keys fall.

First, a trap specific to Liana: an Mk3 cannot run miniscript, so it is easy to assume the Mk3 is irrelevant here. It is not. An Mk3-generated seed restored onto a Mk4 or a Q, which do support Liana, signs your Liana transactions while carrying the Mk3’s near-total lack of entropy, the worst case in this whole affair. So classify each key by the device that first generated its seed, not the one it signs on today.

Second, primary and recovery paths are not equally urgent. A broken primary path can be spent immediately, and no amount of security on your recovery keys helps, because the attacker never uses them. A broken recovery path is gated by its timelock: it is only useful once the coins have sat untouched for the full delay, and any movement resets that clock, so an actively used wallet keeps the path shut. The danger there is the dormant wallet, which is exactly what recovery paths are for. Taproot also impacts the urgency for compromised recovery paths. If your Liana setup uses Taproot, even an expired timelock won’t compromise the funds immediately, as long as you do not use that path and the descriptor is not public. With Segwit, an expired timelock means immediate risk.

The thief does NOT ALWAYS need the Descriptor

Which case do you fall into?

Assuming you have spent or refreshed a transaction in the past:

• If every device you use in your setup is a Coldcard, and your wallet is a Segwit wallet (default for many Liana wallets), your descriptor does not protect you. Your entire wallet is at immediate risk. Move funds immediately.

• If instead only some of the keys are Coldcard, or you use Taproot the attack is different. The descriptor partially protects you. If you are at risk, when you try to spend, an attacker can try to replace your transaction and steal its inputs. This is done by “replacing” the transaction by increasing its fee, before it gets mined. The attacker will not be able to take UTXOs that are not part of that transaction.
  Currently (1st Aug 2026) it seems this attack is not yet being performed, or still rare. We expect it to be common in the next few days, and automatic/guaranteed in the next weeks or earlier. Once these attacks are common, DO NOT BROADCAST your transactions. Your only protection will be to use an “out of band” service such as Slipstream from Mara.

Assuming you never spent nor refreshed from the wallet since its creation:

• Use an “out of band” service such as Slipstream. You are not at risk before you transact, assuming you never shared your descriptor.

The technical explanation

A SegWit wallet publishes the Script on the first spend. Before you have ever spent, a SegWit Liana output shows only a hash on the blockchain, and an attacker working from the chain alone sees nothing to match. But the first time you spend, the transaction reveals the complete policy: the public keys of every participant at that address, together with every threshold and timelock in the wallet. If all of those keys are affected, an attacker can recover each one’s extended public key, rebuild your entire descriptor, and derive every address you will ever use, past and future. One spend, and a chain-only attacker owns the whole wallet for good. If only some of the keys are affected, that same spend still lays the wallet’s structure bare and exposes the affected keys, but your addresses at large stay out of reach, because reconstructing them would need the extended keys of the strong signers too.

A Taproot wallet reveals far less, because it keeps each spending path in a separate branch and a spend touches only what it must. Spending through a multisig primary reveals the keys of that one path at that one address, never the rest of your wallet and never your other addresses, and because each address blends its own keys the values differ at every index, so there is no fixed target for an attacker’s table across your wallet. This compartmentalization is the real Taproot advantage: it contains the blast radius of a spend.

The table below is only about what the chain hands an attacker who does not have your descriptor. It is about blast radius, not about whether a weak key can ultimately be reached.

Taproot’s advantage has hard limits. If your descriptor leaks, the attacker can compute all of your addresses and match your weak keys directly. If every path has been used AND every key is Coldcard, the descriptor can be reconstructed too.

WHAT DO I DO AS A LIANA USER?

If you fall under the “immediate risk” categories above, timing is critical. You will have to do with what you have, don’t wait for a new signing device to be delivered.

Create a new Liana setup (click the + sign at the top of the Liana software), do not use broken Coldcard wallets. Either:

• other signing devices you own
• or install the new firmware on your Coldcard(s) and generate a fresh seed on it
• or generate a new seed with dice on the Coldcard(s)
• or generate a new seed on a separate signing device and import it to your Coldcard(s)

You have plenty of options. Using Taproot is a good idea, you can enable it at the top right corner of Liana. It does not work for Jade devices sadly, if Jade is in your setup, use Segwit.

Backup your new descriptor once it’s done.

⚠️ Before transfering your funds, assess the risks.

• If you transacted or refreshed in the past and use Segwit and only Coldcards in your setup, transfer normally, ASAP. Being too late will have your funds stolen, this is a race against the clock.
• In any other case (if you NEVER EVER transacted nor refreshed from your wallet, or you use taproot, or you don’t only use Coldcards) the safest option is to wait for a Slipstream tool we will provide soon.

You can craft the transactions from your old wallet (another tab at the top of Liana), to addresses generated in the new one. DO NOT broadcast them if the best option for you is the Slipstream tool.

Of course, if your wallet does not fall under immediate risk, you can transfer normally.

Section 2: What exactly happened

A quick refresher on randomness

Your Bitcoin secret key rests entirely on a single number, drawn at random once and for all on the day it is created. That 128 or 256 bit number is encoded as 12 or 24 words, then derived into a full tree of keys and addresses. Nothing protects your bitcoins but the statistical impossibility of guessing that number.

To produce that number, a signing device (a.k.a. hardware wallet) has a TRNG, a hardware generator that measures real physical noise, such as the thermal noise of a circuit or the phase jitter between two oscillators. This is genuine randomness, impossible to reproduce.

A PRNG is the opposite: a purely deterministic algorithm. You give it a starting value and it spins out a long sequence of numbers with all the statistical appearance of randomness. But the same starting value always produces exactly the same sequence. A PRNG creates no entropy; it merely spreads the entropy of its seed over a longer output.

Hold on to that distinction, because everything else follows from it: a TRNG harvests randomness, a PRNG only spins out the randomness it was handed at the start. If its seed is worth 32 bits, its output will never be worth more than 32 bits, however long that output is.

The TRNG was there all along, but nobody was calling it

This is the heart of the matter. The STM32 chip in the Coldcard does contain a TRNG, and it works perfectly. It is just that, by the time the seed was generated, nothing was talking to it any more.

To see how you end up there, you have to follow the call chain one step at a time.

Where this code comes from. Three public repositories are involved: the firmware itself, Coldcard/firmware; the cryptographic library it calls into, switck/libngu; and the MicroPython fork it runs on, Coldcard/micropython. Everything quoted below is taken from firmware commit bcc2c382, the last state of master before the hotfixes of 31 July, which pins libngu at 537519a8 and MicroPython at 4107246f.

It all starts in shared/seed.py, with the function that builds a new seed:

def generate_seed():
    # Generate 32 bytes of best-quality high entropy TRNG bytes.

    seed = ngu.random.bytes(32)
    assert len(set(seed)) > 4       # TRNG failure

    # hash to mitigate any possible bias in TRNG
    return ngu.hash.sha256d(seed)

The comment promises best-quality bytes straight from the TRNG. Let’s go one level down. ngu.random.bytes is implemented in C, inside an in-house cryptographic library called libngu:

void my_random_bytes(uint8_t *dest, uint32_t count)
{
    uint32_t last = 0;

    while(count) {
        uint32_t chip = CHIP_TRNG_32();

        if(chip == last) {
            // maybe TRNG is not clocked? Fail hard
            mp_raise_OSError(MP_EFAULT);
        }
        last = chip;

        chip ^= my_yasmarang();

        int here = MIN(4, count);

        memcpy(dest, &chip, here);
        dest += here;
        count -= here;
    }
}

The logic is sound: take a value from the chip’s hardware generator and XOR it with the output of an internal PRNG, a standard hardening practice. The question is what CHIP_TRNG_32() actually resolves to. Still in libngu:

#ifdef MICROPY_PY_STM
// ports/stm32/rng.c
extern uint32_t rng_get(void);
# define CHIP_TRNG_SETUP()      
# define CHIP_TRNG_32()         rng_get()

# ifndef MICROPY_HW_ENABLE_RNG
# error "get a HW TRNG plz"
# endif
#endif

So it comes down to rng_get(), a function libngu does not define itself but pulls in from MicroPython, the system the firmware runs on. And this is where it all falls apart.

The Coldcard replaces MicroPython’s randomness module with its own, deemed more conservative. To do so, it disables the original one in stm32/COLDCARD/mpconfigboard.h:

// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG       (0)

The catch is that MicroPython does not remove rng_get() when that flag is 0. It replaces it with a software imitation:

#if MICROPY_HW_ENABLE_RNG
uint32_t rng_get(void) { ... return RNG->DR; }         // real physical noise
#else
// For MCUs that don't have an RNG we still need to provide a rng_get()
// function... A pseudo-RNG is not really ideal but we go with it for now
uint32_t rng_get(void) { return pyb_rng_yasmarang(); } // a software PRNG
#endif

That fallback exists for chips with no TRNG. The Coldcard has one. It disabled the flag for an unrelated reason, and silently inherited a backup mechanism designed for hardware it is not.

The result: the operation meant to mix physical noise with a PRNG was in fact mixing two software PRNGs together. In other words, a Coldcard seed no longer held a single bit of physical randomness.

The safeguard that was supposed to be working

The libngu developers had anticipated this scenario. They had added a compile-time check, meant to refuse to build the firmware if the hardware TRNG was unavailable:

# ifndef MICROPY_HW_ENABLE_RNG
# error "get a HW TRNG plz"
# endif

Unfortunately, #ifndef tests whether the macro exists, not whether it is true. And it does exist, with the value 0. So the check passed without a word, on every single build, for more than 5 years. One character stood between that safeguard and its purpose: #if instead of #ifndef.

What was actually feeding the generator

Since everything rested on two PRNGs, the question becomes: what did they start from?

The first, libngu’s, starts from constants hard-coded in the source, identical on every device in the world:

static uint32_t yasmarang_pad = 0x0a8ce26f, yasmarang_n = 69, yasmarang_d = 233;
static uint8_t yasmarang_dat = 0;

Entropy contributed: zero.

The second, MicroPython’s, initialises like this:

pad = *(uint32_t *)MP_HAL_UNIQUE_ID_ADDRESS ^ SysTick->VAL;
n = RTC->TR;
d = RTC->SSR;

So: the chip’s unique identifier, combined with the boot counter, plus the time and sub-second value of the internal clock at the moment of generation. The chip ID was never designed to be a secret. It is readable, and above all it is structured, since it encodes lot and wafer numbers along with coordinates on the silicon wafer. This is not 96 bits of randomness, nowhere close.

On the Mk3, the search space therefore shrinks to a few dozen bits instead of 256. In practice, that means an attacker can enumerate every possible seed, compute the matching addresses, and check them against the blockchain to spot the ones holding funds. No access to your device is required.

The advertised design, and the real code

On paper, the Mk3’s randomness came from one source: the microcontroller’s TRNG, XORed with an internal PRNG and conditioned through SHA-256. That is a reasonable design, and it has one defining property. There is a single place the entropy can come from, so the whole thing rests on that one call actually happening.

It did not. And the Mk3 has nothing to fall back on: it carries a single secure element, and the firmware of that era has no function to read randomness from it at all.

There is a documentation angle to why this went unnoticed for so long. The main design document of the Mk3 era, the paper covering PIN security, does not discuss entropy or the TRNG anywhere. The only randomness it describes is the secure element generating nonces for the challenge and response protocol, as an anti-replay measure. Seed entropy never appears as a design property with stated guarantees. It was left as an implementation detail.

The TRNG does show up elsewhere in the documentation of the time, but only in passing, and never as a specification of the seed path. One of those mentions was quietly contradicted by the code: the Seed XOR page states that the random split mode draws its bytes from “the Coldcard’s True Random Number Generator”, which stopped being true in 2021 and stayed that way. The three-TRNG framing people quote today belongs to the Mk4 documentation.

Either way the consequence is the same. No written requirement said where seed entropy had to come from, so the implementation had nothing to visibly contradict, and anyone auditing the code had nothing to check it against.

Coinkite’s post-mortem confirms this chain point for point, and its author put it more bluntly than we would have dared: the bulk of the randomness was coming from a PRNG he did not know was in the codebase at all, since it arrived through a submodule, while the carefully written TRNG code was still being used, but only by chance and only for less important things. On the guard itself, he explains that he set the macro to zero thinking it meant neither implementation would be built, which is not what it does.

When the regression was introduced

The switch can be dated precisely. It comes from commit b18723dd, dated 1 March 2021 and tersely titled “First pass w/ libNgU”. Moving to the libngu library is what shifted seed generation from a direct hardware call to this new chain.

Before that, in 3.2.2 and every earlier version, the code was:

seed = bytearray(32)
rng_bytes(seed)

That rng_bytes function read the hardware generator’s register directly. It is in fact still used elsewhere in the firmware, for backup encryption for instance, and it has always worked correctly. So the TRNG did not break down: seed generation, and seed generation alone, stopped talking to it.

Why the Mk4, Mk5 and Q fare a little better

On 11 March 2022, two commits add a function to the firmware:

def rng_seeding():
    # seed our RNG with entropy from secure elements
    import callgate, ngu, ustruct

    a = callgate.read_rng(1)        # SE1
    b = callgate.read_rng(2)        # SE2

    n = ngu.hash.sha256d(a+b)
    n, = ustruct.unpack('I', n[0:4])

    ngu.random.reseed(n)

At boot, the device queries its two secure elements, hashes their outputs, and feeds the result back into the PRNG. That is real hardware randomness, and it changes everything compared with the Mk3.

Three caveats are worth setting out, though.

First, ustruct.unpack('I', ...) takes only 4 bytes. The injection is worth exactly 32 bits, and reseed() overwrites just one of the generator’s four state variables.

Second, the function sits behind a test, if version.mk_num >= 4, and that gate is deliberate. rng_seeding() reads both SE1 and SE2, and the Mk3 has no SE2, so the call could not work there at all. This was never a fix held back from the Mk3. It was an extra layer that only the newer hardware could physically carry.

Third, the commit messages are neutral, “Seed RNG with RNG from both SE’s”, and no security fix entry appears in the changelog. Everything points to opportunistic hardening rather than a fix for an identified flaw, and Coinkite has since confirmed exactly that, writing that they “were unaware of the bug until today” and describing the SE1 and SE2 mixing as “a backup to a backup”. The root cause itself was never touched, on any model, which is why the Mk3 went on shipping with a single dead entropy source through 4 more releases, up to June 2023. That accidental extra layer masked the problem for 4 years.

What does this mean for these models? Coinkite’s post-mortem puts the effective search space at about 40 bits on the Mk3 and about 72 bits on the Mk4, Mk5 and Q, both figures explicitly preliminary. To put that in perspective, 40 bits is swept in a matter of hours on ordinary hardware, and 72 bits is out of reach of a hobbyist but not of a funded attacker, while the design target was 128.

Block’s engineering team reads the Mk4 case more harshly. Their analysis notes that the reseed does not accept the full digest, does not initialise a cryptographic DRBG, does not reseed MicroPython’s own fallback and does not reset the other Yasmarang state words. On their model, the secure-element contribution is capped at 2^32 possibilities, averaging roughly 2^31 trials.

The 72-bit figure assumes an attacker who knows neither the chip ID nor the boot timing. An attacker who can pin those down, which is far from absurd for a targeted victim, is left with the 32-bit reseed alone, and 2^32 is trivially enumerable. So the honest statement is that the Mk4, Mk5 and Q sit somewhere between “expensive” and “cheap” depending on what the attacker already knows about your device, and nowhere near 128 bits in either case.

Who exactly is affected

Here is where things stand, by model and by version:

The Mk1 is not affected, and cannot be. Its last compatible firmware is 3.0.6, from December 2019, and installing anything newer bricks the device. The regression only arrived 15 months later, in 4.0.0. A Mk1 is therefore stuck on a version that still read the hardware TRNG directly.

Version 4.0.0 was tagged on 17 March 2021 and already contains the regression, but it does not appear in the signed manifest, so it was never distributed. The first affected public release is therefore 4.0.1. The very first 5.0.0 tag from January 2022 did not yet contain the reseed, but it was never shipped either. The first Mk4 actually delivered, in March 2022, has always had it.

Do not read the Mk4, Mk5 and Q as three separate cases. They all share the same firmware for the core logic, seed generation included, so what is true of one is true of the others.

TAPSIGNER, OPENDIME and SATSCARD are not affected, because they run on entirely different codebases.

Critically, installing a firmware fix will NOT secure your existing mnemonic. It will make new mnemonic generated on the device after installing the fix, secure.

The special cases

The firmware version alone does not tell you where you stand. Five things change everything.

If you generated your seed on a Coldcard and then imported it elsewhere, onto any other hardware wallet of any brand, you are affected in exactly the same way. It is the seed that is at fault, not the device it lives on today.

If you generated your seed from fair dice alone, you are safe. The function that processes the rolls takes a SHA-256 of the rolls only, never touching the faulty generator. Each roll of a perfectly fair 6-sided die is worth 2.585 bits, so 50 rolls reach 128 bits and 99 rolls reach 256 bits.

Coinkite sets the exception at at least 50 fair, independent and private rolls, and considers such a seed not at risk from this RNG issue alone. Those three adjectives carry real weight. Fair means a die that is not loaded. Independent means you actually rerolled each time rather than reusing a pattern. Private means nobody watched, filmed or logged the rolls, because entropy that someone else saw is not entropy any more.

If you are somewhere below 50, treat yourself as affected.

If you used the option that mixes dice with the device’s randomness, your rolls added real entropy on top. That is precisely what saved some Mk3 users. This is the whole point of that option: if the device’s generator is broken, your own entropy makes up for it, and if your dice are loaded or you mistype a roll, the device’s generator has your back.

If you have a strong BIP-39 passphrase, meaning long and randomly generated, you are protected. Be careful not to overestimate that protection, though: BIP-39 derivation relies on PBKDF2-HMAC-SHA512 with only 2,048 iterations. Once the seed is known, testing a candidate passphrase costs next to nothing.

As an average user, consider your passphrase not secure. Even if your funds aren’t stolen yet, low entropy passphrases will be broken quickly, at scale.

Finally, if your seed exists only as words on paper or steel, and you cannot say with certainty which device produced those words, you have to assume they could have come from an affected Coldcard. The same applies if you restored that backup onto some other wallet, of any brand. The device holding the seed today tells you nothing about where the number originally came from. This catches inherited seeds, wallets someone else set up for you, backups written years ago, and devices you have since sold or discarded, which you can no longer check.

There is no way to settle it after the fact. 24 words drawn from 256 bits of physical noise and 24 words drawn from a counter look exactly alike, and no test you can run on the phrase itself will tell them apart. So doubt is not a middle position here. A seed whose origin you cannot establish should be treated as affected, and migrated like the rest.

What to do now

THIS SECTION DOES NOT APPLY TO LIANA USERS, and is more complex for other multisig users. Refer to the Section 1 above for information on how to deal with the situation as a Liana user.

Step 1: work out how urgent your case is

You need to act right now, not tomorrow, if your seed was generated on a Mk2 or a Mk3 running firmware later than 3.2.2 without at least 50 private dice rolls. The same goes for a multisig whose spending threshold can be met with those keys alone, and for a seed born on one of those devices and later moved elsewhere. For the sake of safety, we consider passphrases are insecure, buying you only hours or days at most to react.

You should also immediately migrate if you use a Mk4 or Mk5 below 5.6.0, or a Q below 1.5.0Q, in single sig or in a multisig whose threshold can be reached with Coldcards alone. The 72 bits entropy is possibly a much lower number due to the determinism of the PRNG (multiple estimates place it between 50 and 60 bits). While it is hard to know how quickly these mnemonics will be found, we assume a sweep is possible in a matter of hours given the very high availability of fast compute, at scale. It’s a matter of funding or direct access to compute resources for the attacker(s).

There is nothing you need to do right now if your seed comes entirely from dice rolls, or if it is protected by a long truly random passphrase, or if it was never generated on a Coldcard.

Step 2: choose where the funds go

Coinkite’s own instructions are to update the device to the fixed firmware, generate a completely new seed on the updated Coldcard, and migrate the funds across. That route is legitimate and, on the fixed firmware, the device-generated seed is sound again. Dice rolls are optional at that point rather than a requirement, and a passphrase is a separate decision about wallet security, not a patch for this bug.

Moving your funds is urgent, so the simplest options are, in order of our preference:

1- Move your coins to another signing device, of another brand, that you have already set up properly in the past

2- Set up a Liana wallet if you have multiple signing devices

3- Rolling dice on your Coldcard to generate a new mnemonic, if you have nothing else

4- Software wallet with hot keys. Possibly multisig between a couple of phones or computer + phone. This is unsafe, but might still save your coins

We do not recommend custodians, unless you already use them regularly.

Timing is important, use devices you already have set up, preferably.

Step 3: don’t trip yourself up in the rush

Panic is how people lose their bitcoins, often more reliably than the flaw itself. Take the time to follow good practice, even under pressure.

Back up your new seed phrase properly, along with your passphrase if you set one, on a durable medium and in a place you control.

Run a recovery drill on your new wallet before sending it anything. Wipe the device, restore from your backup, and check that you land on the same addresses. That is the only way to know your backup actually works.

When you make the transfer, verify the receiving address on the screen of the Coldcard doing the sending, and confirm beforehand that this address really belongs to your new device by displaying it on that device’s screen. Never trust an address shown only on a computer screen.

Keep your old backup until the migration is complete and verified. The old seed is compromised, but it is still the only thing that controls the coins until they have actually moved.

Finally, watch out for scams, which will multiply in the coming days. Some people will exploit the panic to extract your seed phrase. Do not install software you found in a hurry, do not buy a device from an unknown seller, and never listen to anyone who reaches out to you unprompted in a DM to help. No legitimate support team will ever ask for your 24 words. Expect fake “recovery services” too, offering to get your stolen coins back for a fee. They cannot.

If you have already been robbed

Coinkite has said they will work with affected users who want to file a police report, make an insurance claim or run their own investigation, and that they will provide a written incident summary specific to your loss along with whatever transaction data they can share. They have also said they are cooperating with on-chain investigators and with any law enforcement agency that opens a case.

Record everything on your side before it gets lost: the transaction IDs of the theft, the affected addresses, your device model and firmware version, and roughly when and how the seed was originally created.

Section 3: The knock-on consequences

The flaw is not limited to the outright theft of your bitcoins.

What falls because the seed falls

Everything derived from your master seed inherits its compromise automatically.

BIP-85 keys are a case in point, since they are derived deterministically. And from them the device can produce 12-, 18- or 24-word phrases, WIF keys, XPRVs, as well as 32- or 64-byte blocks and passwords. In practice, that means your Nostr keys, your Lightning node seeds, your SSH keys and your email or exchange account passwords generated this way all need to be replaced.

The same goes for the duress wallets tied to trick PINs, derived through the standard BIP-85 process, and for microSD card 2FA, whose file is encrypted with a key derived from the seed.

What is broken regardless of your seed

This family is nastier, because it hits even the users who did things right, with a seed generated from dice or imported from another device. These features draw straight from the faulty generator, without going through your seed at all.

Paper wallets are the most worrying case. The function that creates them asks for a key pair without supplying a seed, which makes it pull its bytes directly from the broken generator. The paper wallet’s private key is therefore literally the PRNG’s output. It bears no relation to your seed, and every paper wallet created on a Coldcard since 2021 has an enumerable private key, unless it was generated through the dice option. These keys stand alone, often printed and then given away or forgotten in a safe, and whoever holds them today may not even know where they came from.

The clone-to-another-device function is broken too. The mechanism relies on an ephemeral key exchange between the two Coldcards, over the SD card, from which the transfer’s encryption key is derived. Since those ephemeral keys come from the faulty generator, anyone who gets hold of the clone file can recompute them, redo the exchange and decrypt everything, and so recover the seed in the clear. Even if that seed was generated with dice.

The encrypted USB session between the Coldcard and your computer relies on the same kind of ephemeral key. This one isn’t signifiant.

The C key of Coldcard’s co-signing feature, the 12 words the device keeps in order to enforce a spending policy, also comes from the broken generator.

The password generator built into Secure Notes & Passwords is affected in two of its modes. The mode that produces words is built on the same function as seed generation. The mode meant for sites with strict requirements states its own entropy budget in a code comment, 49 bits, which was already tight before this problem was even taken into account. Here again, these passwords protect accounts that have nothing to do with Bitcoin.

Both secret teleport mechanisms are affected. The password used to transfer a seed between two devices is 40 bits by design, and it is drawn from the broken generator. The exchange between multisig co-signers relies on a 28-bit derivation index, predictable as well.

In HSM mode, used by organisations that automate signing, the second factor’s shared secret and the local confirmation codes come from the same generator. The second factor therefore no longer blocks an attacker, and the proof of physical presence becomes remotely predictable.

Two minor points round out the picture. The randomised keypad layout used when entering the PIN, meant to protect against shoulder surfing and fingerprints on the screen, can be reconstructed. And the masking the cryptography library uses as a side-channel countermeasure is predictable too, and therefore useless. These last two weaknesses require physical access, which puts them far down the list of priorities.

Finally, a word on Seed XOR. By default the feature is deterministic and unaffected. There is, however, an optional random mode that the user has to select explicitly, and that one does call the broken generator. In that case, with a 2-way split, the first share is the mask drawn from the generator and the second is your seed combined with that mask. An attacker who gets hold of that second share can recompute the mask and rebuild the seed, even though the whole promise of Seed XOR is that you need to bring both shares together. The irony is that the screen presents this option as a split “using the TRNG”, and it is precisely the one that does not use the TRNG. That said, this only concerns unaffected seeds split in that specific mode, which remains a narrow set of cases.

Privacy

Any seed created on a Coldcard since 2021 has to be treated as public. And if the seed is public, so is the entire transaction history that flows from it, retroactively and permanently.

The point that deserves the most attention is a second-order effect, one that hits people who have never owned a Coldcard. In a coinjoin round or a payjoin, your anonymity depends on the number of participants who are indistinguishable from one another. If some of them become identifiable, your own anonymity set shrinks accordingly. And that shrinkage is retroactive: it applies to every mix performed since 2021, and there is nothing you can do about it today.

Coldcard does not natively support any coinjoin implementation, but many users send their funds from their Coldcard to coinjoin software and then bring them back, and in that case anonymity drops for everyone.

Two further effects are worth adding. Chain analysis firms gain a considerable set of addresses they can label once and for all. And your counterparties, the people who sent you funds or received funds from you, see part of their own transaction graph exposed by association.

Section 4: How to stop being exposed to this kind of flaw

Once your funds are safe, the real question becomes: how do you avoid going through this again with another brand in the future? There are not that many options.

Add your own entropy

The first is to supply part of the randomness yourself, typically with dice rolls. That is exactly what saved some Mk3 users, and the mixing option the Coldcard offers remains, in principle, a good idea: if the device’s generator is broken, your entropy makes up for it, and if your dice are loaded or you make a mistake, the device’s generator makes up for that.

Unfortunately, very few devices offer this option. And one thing still holds today: generating your seed entirely on your own is a bad idea for most people, because it is far too easy to get it wrong. A vendor’s generator failing is not a reason to do everything by hand. If you do, do it properly, with a real die and the required number of rolls. And obviously, never pick your own words.

The BIP-39 passphrase (not recommended)

The second option is to stay in single sig and add a BIP-39 passphrase. It adds entropy on top of the seed, provided it is genuinely strong, meaning long and drawn at random. This is what protected some Mk3 users.

The trouble with passphrases lies in backing them up and in how awkward they are to use. Storing one safely is not straightforward, and it is very easy to make a mistake that costs you every last coin, especially when you do not fully grasp the mechanism, and all the more so during a panic like the one we are living through. A poorly understood passphrase loses more bitcoins than it protects.

Multi-vendor multisig, the real answer

The principle comes from safety-critical systems engineering, where it is called dissimilar redundancy. To tolerate a design error, duplicating a component is not enough; it also has to be designed differently. That is why the flight controls of a modern airliner rely on several computers developed by separate teams, with different processors and different software, so that a single defect cannot strike them all at once.

A multisig built from devices of different brands applies exactly that logic to entropy generation. In a 2-of-3, each key is born from a generator built on distinct principles: a certified secure element in one, several chips from different foundries combined in another, a multi-source entropy pool with no secure element in the third. These devices share little to no hardware, no firmware and no supply chain.

An entropy generation flaw in one of them therefore exposes a single key, which is not enough to reach the spending threshold. That is exactly the situation we are in today: users whose threshold could not be met with their Coldcards alone have not lost their funds.

This is why we recommend a multisig with recovery paths, of the kind you can build with Liana, combining several brands of signing device. You get both resilience to this kind of defect and a recovery mechanism if you lose a key. Just make sure no spending path can be satisfied with the keys of a single brand.

If you are an organization or HNWI with more than 10 BTC, consider using Liana Business, our purpose built institutional infrastructure.