
Stage 2 — the starfield. Art by Douglas John Brownfield.
Everything in this part can be done today, with tools that exist today, and none of it depends on a roadmap. These are the complete solutions the Introduction promised.
A Bitcoin address is not a public key. For most address types, it is a hash of a public key — a fingerprint that hides the key itself. That distinction is the whole of this chapter, because a quantum attacker needs the public key. What is hidden behind a hash is, for now, hidden from the machine as well.
So exposure has a precise moment: the first spend.
the start. Coins sitting in it — including the roughly 1.1 million early coins attributed to Bitcoin's creator — have had their keys public for over a decade.
public key only when you spend. Receive all you like; the key stays hidden. Spend once, and the key is on the chain forever.
visible in the output itself, so Taproot addresses are exposed at rest even before any spend.
attached to every later payment to that address. This is why the oldest advice in Bitcoin — a fresh address for every receipt, which the whitepaper itself recommends in its privacy section — turns out to be quantum advice too.
The practice is simple to state: receive at fresh addresses; treat any address you have spent from as retired for long-term storage; and know which of your addresses are which. Tools now exist that will tell you — public datasets walk the whole chain weekly and will show a holder exactly which of their addresses have a revealed key, and the spend that revealed it. The counters disagree on the global total (their methods differ, and the totals move when the methods are revised), but for a single address the answer is a fact, not an estimate.
A seed phrase is only as safe as the machine that first held it. If the words are generated on, typed into, or restored to a device that is connected to the internet — or ever will be again — then the holder is trusting every network that device has met.
The documented practice of the air-gapped wallet makers is a rule with a strict order of operations:
maker shipped it to be trusted in. AirGap's own FAQ recommends the factory reset before a phone is used as an offline vault, and allows exactly one brief connection — to fetch the app — or none at all, loading the app from an SD card instead.
"usually offline." Offline as a property of the device, the way a safe is heavy as a property of the safe.
device, never shown to any other screen.
Other makers arrive at the same place by different roads: the Coldcard generates and keeps its seed inside a device that has no radio at all; the SeedSigner holds the seed in memory only, for the session only, and forgets it at power-off — stateless by design. The details differ. The principle is one: the words are born offline and live offline. A device is not made trustworthy by the seed it holds; the seed is made trustworthy by the device never having been anywhere else.
If the signing device never connects, how does anything get signed? By light.
The flow, which is standardised (the transaction format is BIP-174, the Partially Signed Bitcoin Transaction, extended by BIP-370) and shipped interoperably by the major air-gapped makers and the coordinator software holders already use:
your addresses and balances — through your public keys — but it cannot sign. It has nothing to steal.
code — animated, in frames, when it is large (the UR standard exists for exactly this).
the address, the amount, the fee. You check it on the device that holds the keys — the one screen in the flow that cannot be lying to you on behalf of a network.
own.
it. The keys never left the offline device. No cable, no Bluetooth pairing with a connected machine, no moment in which the seed and the internet were in the same room.
This is not a proposal. It is the daily practice of holders using Coldcard with Sparrow, SeedSigner, Keystone, and AirGap, and it is the same shape on other chains wherever an offline signer and an online companion are paired.
Devices die, get lost, get sold, get doubted. The seed phrase makes the device replaceable — but there are two different moves, and using the wrong one is the most common quiet mistake in self-custody. The definitions here follow the wallet documentation holders have used for years (Electrum's FAQ states them plainly):
Restore recreates the same wallet from the seed. You enter the words on the new device — offline first, per the previous chapter — and the wallet reappears: same keys, same addresses, same history. Nothing moves on the chain, because nothing needs to. Restore is the answer to a device problem: the hardware failed, but the seed was never in doubt.
Sweep moves the money. You create a brand-new seed on the new device, and then send all the funds from the old wallet to the new wallet's addresses in an ordinary transaction. The old seed is retired — not restored, not kept as a spare, retired. Sweep is the answer to a seed problem: the old device was lost or sold, the words may have been seen, the generation of the old seed is in doubt for any reason. A new device restored from a doubtful seed is a doubtful wallet in a clean box; sweeping is what actually closes the question. (A swept key does not join the new wallet — the funds land on keys derived from the new seed only.)
Rule of thumb, stated once: device in doubt → restore is not enough if the seed shared the doubt; seed in doubt → sweep. And note what the sweep is, because Part Four will return to it: a move of funds from old keys to new keys, in one ordinary transaction, costing one ordinary fee. Hold that shape in mind.
This book's method is not theoretical. It is the practice of the author's own setup, kept small on purpose, and it is offered as a worked example — one holder's arrangement, every part of it rehearsed, rather than a product to buy.
fresh, inexpensive Android phone, factory-reset, taken permanently offline before anything else happened to it. The vault app went on during one brief connection (it can also be loaded by card, with no connection at all). The seed was created on that phone, after it went offline, and has never existed on any other device.
connected machine, never photographed, never spoken to an assistant, never entered anywhere except the offline device and its successor. The author's rule for everyone who helps him — human or otherwise — is absolute: helpers may build anything around the wallet; the signing itself is never delegated. No helper ever sees a key. Signing is the holder's act, done on the holder's hardware, at the holder's prompt.
wallet builds; the offline phone scans, shows, signs, answers in light; the online wallet broadcasts.
seed restored if the old seed is sound; a new seed and a sweep the moment it isn't.
nothing parked long-term in an address already spent from.
first signing this setup ever did was a small test transaction, on a test network, whose only job was to prove the flow worked before anything real rode on it. The rule generalises: recovery, too, is rehearsed before it is needed, because the day it is needed is the wrong day to learn it.
hardware was evaluated for this setup, the questions were asked in a fixed order: Where was it made, and by whom? Is it truly air-gapped, or does it merely sign offline between connections? (One well-known candidate, for all its quality, is not air-gapped at all.) Is the chain support you need named by the maker, or hidden inside the phrase "all EVM chains"? What do the maker's own pages say today — not the reviews, not the memory of last year's model? The cheapest option on the table turned out to be the phone above; the vetting is what made it a decision instead of a guess.
None of this required wealth, expertise, or exotic equipment. It required deciding that the device is replaceable and the words are the wallet — and then behaving that way on ordinary days, so that the behaviour is already there on the extraordinary ones.