Airgap doesn't fix a wallet seed that was born weak, and how multi-sig can help or worsen the case

A seed is a birth event

CTO — GreyBound, Aug 2026

The story we sold ourselves was simple.
Buy a brick.
Generate words on the brick.
Never plug it in anywhere.
Sleep peacefully.

That story just failed in public, at scale, without anyone touching a button, a USB cable, or a backup plate.

The coins moved because the words were never as random as the box implied.

Once that is true, the backup is not a secret. It is a searchable object. The chain already publishes the addresses. The rest is arithmetic.

Bitcoin did not break. Consensus did not refund.
Airgap is not a random-number generator.

What actually went wrong (the class, not the gossip)

In late July 2026, Coinkite disclosed a firmware defect on some Coldcard devices: seed generation could silently use a weak software generator instead of the hardware RNG the product was designed around.

Their advisory is the source of truth for models, versions, and exceptions. Read that. Not a thread. Not us.

We are not reconstructing the bug. We are naming the class, because this class is older than one vendor and it will happen again.

The class is:

1. Entropy is supposed to come from a hardware source.
2. A fallback exists “just in case.”
3. The fallback is weak, and the UI does not scream.
4. The 12 or 24 words look like every other backup.
5. Years later, someone searches the small space, matches funded addresses on the public chain, and sweeps.

No physical access. No phishing. No “I clicked Approve on a fake site.”
The seed was born small. The spend path was fine.

Firmware updates protect future births. They do not travel backward into words you already wrote on steel. That is the sentence most coverage keeps missing.

Three myths that will empty another round of wallets

Myth 1. “I updated. I’m safe.”

An update can stop new seeds from being born the same way.

It cannot un-birth the old ones.

The weakness is in the words. The words are the wallet. Changing the program that sits next to them does not change the math of those words.

If your seed was generated on affected firmware, treat it as permanently compromised unless the vendor’s own exception clearly applies to your generation method. Coinkite’s public exception is independent, private dice entropy at birth, not “I rolled a few times later for luck.”

Myth 2. “I’ll just create and send to a new address.”

A new receive address is another leaf on the same tree.

Whoever can search the seed can derive the old addresses, the new ones, and the ones you have not used yet.

Moving coins to a fresh address on the same backup is rearranging furniture in a house whose key is already public.

Myth 3. “It never connected to the internet, so nobody could have my seed.”

They never needed your seed as an object in your house. All they needed was:

• a generation method with a small search space
• the public list of funded addresses
• time and computation power

Airgap stops a thief from extracting a good key off the device.

It does not stop someone from guessing a bad key that the device printed as if it were good. That is a different threat. Mix them up and you will take the wrong medicine.

What to do if you’re afraid you might be in the window

Normal path. Do this slowly. Do not skip the test send. Do not panic.

1. Read the vendor advisory. Decide if your seed was born in the window. Generation date and firmware at generation, not the firmware you run today.
2. If yes, generate a new seed on a device whose entropy path is actually fixed. Use another device you can trust, or other safe standard methods. Or generate with a method the advisory treats as independent (for Coldcard: sufficient private dice at birth, as they specify, not a vibe). High-entropy seeds are safe.
3. Verify a receive address on the device screen. Not on a phone screenshot. Not on a coordinator preview you cannot reconcile.
4. Send a small test. Wait. Then the rest. A wrong address on a “migration” is how people finish the attacker’s job for them.
5. The old seed stays toxic. Do not reuse it as a “watch-only.” Do not keep it as a backup “just in case.” Do not import it into a new app to “check the balance.” The balance check is how you confirm the attacker still has a map.
6. A BIP-39 passphrase is an extra secret. It is not a time machine. A strong, unique passphrase that never lived next to the seed can raise the cost of a weak seed. A short, reused, quoted, or family-password passphrase does not. Even a good one does not repair the birth. Plan to replace the seed anyway.

If you are not in that vendor window: still steal the lesson. Ask how your wallet was born. Software wallets fail this class too: Math.random, clock seeds, device IDs as salt. Hardware is not magic. It is a factory with a firmware story.

Multisig is the architecture. It is not a sticker.

Recent news brought up discussions around multi-signature wallets. A few things to clarify.

Single-sig means one birth event can move everything. That is the product most people bought: one brick, one set of words, one failure domain.

2-of-3 across two manufacturers is how you survive a vendor mistake without pretending vendors never make mistakes.

The picture:

• Key A: vendor 1, hardware, its own entropy at birth
• Key B: vendor 2, different maker, its own entropy at birth
• Key C: recovery key, born a third way (dice, or a third device), stored like it can bury you

Threshold: two signatures to spend.

One vendor can vanish, brick, or disclose a birth defect. The coins still move when you want. They do not move when one factory was wrong.

The trap even skilled people will still walk into

Multisig does not invent randomness.

If you generated key A, B, and C on the same affected firmware, same product, same silent fallback, you built a 2-of-3 out of one search space. An attacker who can reconstruct two of those births meets the threshold without stealing a steel plate from a second continent.

Same trap, smaller: two keys on vendor 1, “backup” key on vendor 1 again because the other brick was on backorder.

Keys in a quorum must be born independently. Different devices. Prefer different vendors. Prefer one key that never shared a firmware tree with the others.

What 2-of-3 does not buy you: skipping address verification, skipping a descriptor backup, or treating a laptop coordinator as a signer. It is even more complex to manage for non-technical users.

How to live with it (normal)

You do not need to become a protocol engineer.

• Use a watch-only coordinator (Sparrow-class desktop, or the vendor’s coordinator) that cannot spend alone.
• On every receive: show the address on signing device A and signing device B. They must match each other and the coordinator.
• Backup the output descriptor (the script policy: which keys, what threshold, what derivation) and the seeds. Seeds without the policy is a future locked-funds story. Policy without independent seeds is the 2026 story.
• Practice a spend with a tiny amount before you park life savings in the quorum. The first real spend should not be the first time two devices have to agree.

How to build it (getting technical)

• Native SegWit P2WSH wsh(sortedmulti(2,...)) or a Taproot policy you can actually verify on-device. Do not mix script types because a UI offered a dropdown.
• BIP32 origin on each key (fingerprint + path). If a device cannot show origin, you cannot prove which seed you imported. Prefer BIP48 script paths for the vault, not “whatever account 0 the app felt like.”
• Each signer verifies the PSBT: every output, change back to the same descriptor, fee, locktime. This is the WYSIWYS article’s job, applied to a quorum.
• Do not generate all three keys in one afternoon on one desk from one shipping box. That is a single supply chain with extra plastic.
• If one cosigner is later disclosed as a weak birth: replace that key in the policy (a new 2-of-3 with a fresh key) and migrate. Do not “keep using it, we still have 2-of-3.” You may already be 2-of-2 against an attacker who searched that vendor.

Passphrase on a single-sig is a poor man’s second factor. It is not multisig. It lives in your head (or in a second backup you will mishandle). Use it as belt on top of a good birth, or as extra cost on a seed you are already replacing, not as the architecture.

Steal this: two checklists

Before you trust a backup (everyone)

1. Where did the entropy come from at generation, not at spend? Hardware RNG, OS CSPRNG, dice the vendor specifies, or “the box looked serious”?
2. If that source silently fell back, would anything on the screen have said so? If the answer is “probably not,” you are in the class.
3. Does “update” create a new secret, or only change future births? If you cannot answer, do not assume the coins moved to safety.
4. Is there a second factor the chain cannot brute-force by itself? Independent passphrase, or a second key born somewhere else. Not a new address. Not a new app import of the same words.

Before you call it multisig (everyone who is about to)

1. Were at least two keys born on different vendors (or dice + a vendor)? Same SKU three times is not diversification.
2. Can I explain the spend rule in one sentence? “Two of these three devices must sign.” If you cannot, you do not have a policy. You have three wallets.
3. Can each signer show the receive address and the change address? If only the laptop shows them, the laptop is the narrator. We already wrote what happens when narrators win.
4. Do I have the descriptor written down with the seeds? You will need it when a device dies in five years. The chain will not remind you of the script.

If you cannot pass both lists, you are not “advanced.” You are single-sig with extra steps, or worse, single-bug with extra steps.

Builders: this is where professionalism shows

Stop implying that “generated on device” is a complete sentence.

• Fail the build if the hardware RNG symbol is missing. Do not ship a software fallback that still presents as hardware entropy.
• If a fallback exists, the generation screen must refuse, or must use language a frightened human cannot miss. A log line is not a control.
• Document: update does not rewrite existing seeds. Put it next to the update button.
• For coordinators: refuse to assemble a quorum whose keys share a fingerprint origin you cannot explain.
• Show birth policy in settings: RNG source, dice used, firmware version at generation, persisted with the wallet record, not only in a support PDF after a press cycle.

Theater is a metal case and a skull sticker.
Craft is a seed whose search space is actually what the brochure claimed, and a spend policy that survives the brochure being wrong.

The reframe that sticks

Self-custody is not “the device is offline.” Self-custody is:

• a birth you can defend
• a backup that is actually a secret
• a spend path whose screen matches the bytes
• a policy that does not die with one factory

The 2026 hardware event was a birth failure. The Approve article we published is a spend-path failure. They are not the same bug. People will keep mixing them because both look like “I lost coins from a wallet I trusted.”

One is: the words were never strong.

The other is: the package was never what the screen said. Fix the one you actually have.

If you are storing more than you can watch go to zero, stop being single-sig on a single vendor. Not because hardware wallets failed as an idea. Because one birth event is not a security model.

GreyBound works on Bitcoin software where entropy, keys, and spend policy have to be true, not merely displayed.

When the keys are independent, one vendor’s worst week is a rotation, not a funeral.