# Threat model

This vault reduces three common ways people lose bitcoin in
self-custody: remote compromise of keys (including keys that never
touched the internet), physical theft of a single backup, and loss
of a single backup.

It is not a hardware-wallet product. It is not a regulated custodian.
It is Bitcoin Core on dedicated computers, with keys on archival discs.

Advisors: the risks this vault is for are in “What the design is
trying to stop.” Operator effort is not one of those risks. See
[CONTEXT_FOR_ADVISORS.md](CONTEXT_FOR_ADVISORS.md).

Read this with the [FAQ](FAQ.md). The [README](README.md) is the
procedure. Follow the README as written.

## Assets

- The 3-of-7 multisig coins
- Seven key backups on archival discs
- The watch-only descriptor
- The online node and the offline signer

## What the design is trying to stop

**Remote theft of keys.**
Keys can be stolen without anyone touching a backup and without the
owner sending a transaction. A wallet is not “cold” if the software
in the stack that created or used the keys was wrong.

This guide treats an unverifiable blob in the key-generation or
signing chain as malware. That includes vendor firmware, vendor
apps, coordinators, and libraries the owner cannot inspect or rebuild
in practice. Any one of those binaries can steal. A coordinator can
build a bad PSBT or serve a malicious descriptor. It can bias nonces
or other signing input and exfiltrate key material. A single bad
crypto library can steal on its own. Vendors and coordinators already
ship as pairs. Assume they can act as a pair.

Any Bitcoin-specific signer can ship that class of failure. The 2026
Coldcard default-seed incident is the public case, not a unique one:
guessable keys from the device’s normal new-seed path, coins swept
from the public chain, no phishing, no stolen device, and a firmware
update that did not repair old seeds. Public source did not help if
the path that actually ran was not the path people thought they had
audited.

This is not a nation-state story. It is what happens when a product
built to hold bearer bitcoin ships software nobody sufficiently
reviewed. The owner has no recourse. “It was a bug” is enough cover
whether the failure was sloppy or not. Shipping and support databases
leak. Do not reserve this class of failure for rare attackers.

This vault creates and uses keys on a dedicated offline computer
running a clean Ubuntu install and Bitcoin Core. Keys are not stored
on the online node. Extra wallet apps and vendor firmware are out of
the stack on purpose.

Industry copy overweights physical extraction and underweights
remote theft. A well-funded attacker can eventually break an
extraction barrier. Remote malware is cheaper and scales across
many devices at once. The 2026 sweeps did not need the device.

Dice kits and offline entropy pages are not a competing vault.
They sit on top of some other stack. You still need a machine,
an import path, backups, and a signer. The mapping code is
extra software with less review than Core. Watching rolls does
not attest that program. Dice-first is not a smaller key-birth
surface than Guix-attested Core. It is Core’s surface plus the
converter. A person cannot be the whole entropy pool and cannot
audit Core’s generator with a calculator.

Roll-your-own entropy makes the operator the single point of
failure for that execution. Paper is not in Core’s test set.
You cannot publish the sheet and keep the secret. Libsecp and
Core’s generator are the reviewed function, shipped as an
attested binary. A side calculator is not that function. An
xpub match against Core does not bind the rolls.

This guide does not mix them in. Keys are generated by Bitcoin
Core on the clean offline machine.

Extra tools sold as a check of Core are the same class. A
coordinator, a seed utility, or a dice page is not a second
audit of Core. Checks of Core happen in Core.
A mapper is another program that can steal or leak.
A pinned page still computes after the last roll. That is a
second hidden draw, not a smaller one.
A hashed HTML or WASM file still runs under a browser engine.
Signatures do not attest that engine.
This guide does not treat Core’s generator as a hole for a kit
to close.

The root of trust is the software you run, not the dice. A kit
that maps rolls is an unauditable root unless it clears Core’s
review. Watching rolls does not make it one.

**Physical theft of one or two backups.**
Spending needs any 3 of 7 geographically split discs. One stolen disc
cannot spend. It can reveal the watch-only descriptor. That is a
balance oracle, not a spend.

3-of-7 is the savings quorum: three discs to spend, four can be
lost. 2-of-3 fails if two keys are gone, and an attacker with
one key needs one more. 2-of-5 still spends on two keys.

A hardware wallet plus the paper slip is one key copied twice,
not a quorum. A seed plus a separately stored passphrase is a
2-of-2 with no spare.

A mnemonic is designed to be typed. That invites phishing and
insecure copies. This vault recovers by reading a disc on the
offline machine. That is the accepted path. It shrinks that
input surface. It does not make physical copies of a disc
impossible.

Each disc is an independent key plus what you need to rebuild
the wallet. Find any three. The split across places is part
of the quorum. Seven discs in one box are not this design.
Other stacks often omit both instructions. 

**Loss or destruction of backups.**
Four discs can fail and the vault still spends. That is the point of
3-of-7.

**A supply chain aimed at Bitcoin-specific devices.**
The computers are generic. The signer is Bitcoin Core.

A mailed gadget whose only job is holding bitcoin is a richer
backdoor target than commodity hardware. The device can only
enforce the code it actually runs.

This GitHub repo is not that target. A bad README is a visible
diff. The signer is attested Core. Quiet theft at scale prefers
a vendor updater and a “bug” story. That is the 2026 pattern.

Todd (2018): a mailed Bitcoin gadget advertises guaranteed coins to anyone who 
backdoors the package. A small computer used only for Bitcoin is less obvious. 
Hardware wallets are still software running on a computer.

Attackers who want coins know exactly what they are looking at. That
supply chain is cheaper to hit than the commodity PC market. The firmware 
on those devices is usually shipped by a small team.

**The security standard is Bitcoin Core with independent Guix
attestations.**

Bitcoin Core’s release is a full, reproducible build. Multiple
independent builders reproduce that binary and sign the result.
That is the review this guide treats as acceptable for software
that can touch keys.

A competitor that ships a non-reproducible application binary, or
a non-reproducible blob anywhere in its dependency chain, fails
that test. This guide classes those blobs as malware in
security-critical infrastructure.

Reproducible source is not enough either. If almost no independent
builders attest the actual bits people run, the attestation is
negligible. “We published the repo” is not Guix.

Diversifying across more Bitcoin implementations is not more
review. It is more code and fewer eyeballs on each program.
This guide concentrates review on Core. That is the assurance.
Adding wallets and firmwares spends that assurance down.

The problem is verification. A device can lie about its firmware.
A reproducible wallet app can still depend on an upstream blob that
cannot be checked. Vendor stacks also lack independent attestation
of the full build chain.

The device can only enforce the code it actually runs.

## What you are trusting

- Ubuntu and Bitcoin Core, installed and verified as the README says
- One offline machine as the key-generation environment
- Your handling of the seven discs after setup
- The public Bitcoin ledger

Software is written by humans. Bitcoin Core and Linux are used
because they are the most reviewed tools available for this job,
not because they are incapable of bugs.

This guide uses Bitcoin Core’s wallet, descriptors, and PSBT
in the same attested binary as the node. That code is in the
Core tree. It is not an unreviewed extra app. Consensus
review is stricter. That is not a reason to generate keys
somewhere else.

Core has had consensus defects. CVE-2018-17144 is the example:
found, patched, not known to have been exploited on mainnet.
It has not had a published key-generation entropy wipe of the
2026 vendor class. That class is why vendor firmware is out of
this stack.

The review standard is Bitcoin Core with independent Guix
attestations of a bootstrappable full build. Vendor firmware
does not provide that path. Vendor “reproducible firmware” is
usually an unsigned application image inside Docker. That is
not the same scoreboard.

A bug in the generator or the signer can leak keys from
signatures on the public chain. It can also hand you an
address that is not yours. Physical split and an air gap do
not contain that.

The question is what makes each signing stack hard to
backdoor. Open source is not enough. XZ was caught by an
unrelated observer with a different incentive. Core and Linux
have that kind of crowd. A small firmware tree generally does
not. Insertion is not impossible. It is expensive here.

One dedicated offline machine running Ubuntu and Bitcoin Core
is a chosen tradeoff. More offline Core machines for key generation would
remove a “this one box was wrong” failure. That would be an
improvement. This guide treats one inspected Core box as sufficient
inside the README’s $10k–$5M comfort zone. The upgrade path is more
Core boxes, not more vendors.

Each extra vendor in the stack usually means an extra coordinator,
extra libraries, and extra firmware. Each of those is more attack
surface.

You cannot run multi-vendor hardware multisig on Bitcoin Core without
adding extra libraries and a non-Core coordinator.A coordinator can 
serve a malicious descriptor. It can bias nonces or other signing 
input and exfiltrate key material. It can conspire with a vendor.

A coordinator or signer that imports coincurve, embit, or
another unreproducible binding has added an unattested blob
to the key path. This stack does not.

A coordinator that also holds a hot key is a signer. USB
hardware on that computer can extract that key and the
descriptor. In a 2-of-3, vendor firmware plus the hot key is
enough to spend. This guide does not put a key in the online
coordinator.

A device can lie about its firmware. A reproducible app can still
depend on an uncheck-able blob. Independent attestation of that full
build chain is missing.

The common line is that generating keys across several vendors makes
the vault safer. This guide assumes the opposite. “One vendor bug
only burns one key” only holds if every other binary is honest and
is the binary the user thinks it is. This guide does not assume that.
The coordinator and the libraries are part of the quorum in practice,
even when they are not a key on chain.

“Survives if the threshold is not met by that vendor” is the same
slogan. It fails as soon as a second vendor, a coordinator, or a
shared library is in on it. Collusion across the stack is in
scope here. Vendor count is not a substitute for that.

There is one acceptable key-generation path here: Bitcoin Core.
Dice, coin flips, and entropy-lab pages are not a second path.
They are extra software.

Multi-vendor multisig is not the reference implementation with more
brands. It is a different program.

That risk is the vendor-firmware model, not one brand. In the Coldcard
case, the library on the failing path was written under a pseudonym
later tied by GPG signatures to the vendor’s own CTO, and release
notes thanked that handle as an outside contributor. That is evidence
about who shipped the code, not a claim about who later swept the
coins. The same shape is available to any small team that writes the
generator, signs the firmware, and tells the market to trust the
device.

The bad generator sat in a public repository from 2021 until the
2026 thefts. Public source is not public review. Coldcard was, for
most of that period, the vendor product this market trusted most
for cold storage. A widely recommended device still ran the wrong
code for years. That is the review standard this guide is unwilling
to accept for key generation.

## What this does not try to hide

Bitcoin amounts on chain are public. When you spend, the
network can see the script type. That is true of every wallet,
not only a 3-of-7 and not only this guide.
An unencrypted disc that includes the descriptor lets whoever
holds it watch the wallet if they know what they are looking
at.

That leak is not unique to this guide. Any multisig that can be
restored needs a descriptor backup. Encrypting it recreates a key
to manage. Encrypting it with the same 3-of-7 is the coherent fix
and needs software Core does not ship yet. See the FAQ.

None of those, by themselves, move coins. They are accepted in scope
for this design.

3-of-7 is not weakened because the seven keys were born on one
Core machine. The quorum is for loss and theft of discs. Key
generation is a separate choice: Core, not seven vendor RNGs.

## Signing

The online computer builds the PSBT. The offline computer signs.

The online machine is a dedicated clean box. It is trusted as part
of this stack. It is not the signer. Keys are not stored on it.

Decoding the PSBT and checking `"ismine": true` on change is a
sanity check. It is not the load-bearing control. An air gap
would not stop a motivated attacker who already owned that path.
Malware in the software you run is the larger concern.

## Day-to-day vs catastrophe

Normal spends use sneakernet between the two computers.

Recovery does not depend on sneakernet, on a particular disc drive,
or on this repository. Setup uses an optical drive. If that drive
is lost or broken later, get another. Anyone who can read the discs
and run Bitcoin Core can reconstruct the wallet and spend.

## Other products

These fail differently. Do not collapse them into one ranking.
Bitcoin is a bearer instrument on a push network with final
settlement. Anyone who holds keys accepts operational risk.
This guide does not create that fact. Hardware wallets and
collaborative custody do not erase it. A brokerage is a claim
on an institution, not the absence of operations.

**Hardware wallets** concentrate key generation, display, and often
the coordinator relationship in vendor software and a Bitcoin-specific
supply chain. Users who followed default setup instructions have lost
funds when that software was wrong. A screen does not help if the
generator that created the seed was weak, and it does not help if
another binary in the stack is the thief. The failure is the model.
Coldcard 2026 is the exhibit. 

The architectural case is older than Coldcard 2026. Maxwell (2020)
called the devices opaque, hard to review, and a supply-chain
target, and would not recommend them for serious amounts. Spigler
(2020) is the long form.

Multi-coin firmware adds networks and libraries on the same
device that holds the Bitcoin key. That is more attack surface
and less review. Bitcoin-only vendor firmware is smaller. It
is still not Core.

**Multi-vendor hardware multisig** adds more of that stack, then a
non-Core coordinator. It cannot be built from the reference
implementation. Vendor diversity does not create Guix attestations
and does not stop a device from lying about its firmware.

**Collaborative custody** is usually a 2-of-3 sold as self-custody.
The user holds one key. The company holds one. A third key is
picked by the company. The company picks the software. Those two 
keys can move or freeze coins. A terms-of-use page is not a map 
of that relationship.

A company in the policy is also a name attackers can impersonate:
fake support, fake recovery, compromised help channels. That
surface does not exist when every key is a disc you placed.

Two hardware wallets plus a BitGo-style HSM (Swan and similar)
is the same class, not a Core vault with a helper. The HSM is
vendor firmware you cannot attest. It does not become Core
because it sits in a trust.


A brokerage, ETF, or trust is a legal claim on bitcoin or a
bitcoin-linked product. You are trusting that institution’s people,
its software, and the law around the account. That software is not
Bitcoin Core, and you cannot inspect it. Recourse is the product.
It does not give you bearer coins, and it does not remove operational
risk. It relocates the risk into a named custodian.

Use it when the person wants that contract: someone to call, a
regulator, an estate process. That is not self-custody, and it is
not this guide.

## Operator duty

Follow the steps as they are written. Do not improvise the
vault. The procedure is closed because the audience is not
meant to design it. Some changes can stay inside this threat
model or improve it. They are still a different design, and
the assurances here apply to the README as written.

Historical self-custody losses often came from novel setups
nobody else reviewed. This guide makes those choices in the
open so the operator does not invent them.

The load-bearing steps are a clean dedicated pair of machines,
Guix-attested Bitcoin Core, the air gap for keys, seven discs,
and the test spends.

## Amount

The README’s $10k–$5M range is a design comfort zone, not a law.
Vendor products do not publish an equivalent ceiling. Naming the
band is not a concession that brands are stronger inside it.

Design disagreements belong in the FAQ or a public issue, not in a
private vulnerability report. See [SECURITY.md](SECURITY.md).