Your seed phrase is not a backup. It is a fragment of a backup.
That sentence makes people angry, and I understand why. Twelve or twenty-four words are the closest thing this industry has to a religious object. We stamp them into steel plates, tuck them into safe-deposit boxes, write them on the back pages of notebooks we swear we will never lose. We are told they are the ultimate form of sovereignty.
It is still literally true. A seed phrase restores keys. It does not restore the instructions that tell a wallet which keys matter, in what combination, under what delay, and under whose supervision. In a simple single-key wallet, nobody notices the difference. In a four-of-six multisig vault with a timelocked recovery path, that difference is your entire balance.
In a commit that most price-chart accounts never noticed, BIP138 was merged into the Bitcoin Improvement Proposals repository. Its status line still reads Draft. There is no soft fork here, no consensus change, no node to upgrade, no exchange listing to watch. There is a specification, a Rust reference implementation, and a proposal to encrypt the wallet structure your mnemonic never held in the first place.
And there is a catch, sitting right at the center of the design. The encryption key comes from an extended public key — the same class of data your watch-only wallet, your portfolio tracker, and a surprising number of browser extensions have been quietly collecting for years.
Verify first. Share second.
What BIP138 Actually Proposes
Strip away the jargon and BIP138 says something narrow. A wallet should be able to produce a single encrypted file containing everything needed to rebuild the wallet's structure — except the private key material itself.
That file carries descriptors. It carries the spending policy. It carries the public keys and derivation paths of every cosigner in a multisig arrangement, the relative timelocks embedded in a miniscript policy, the master fingerprint of each hardware device in the quorum. In plain language, it carries the blueprint.
The blueprint gets encrypted. The encryption key is derived from a qualifying extended public key. Anyone holding that xpub, and holding a copy of the file, can decrypt it. Anyone holding neither cannot.
Private key material — seed phrases, standalone private keys, anything that could directly move coins — must be removed before encryption happens. That is a hard rule in the design, not an optional hygiene step. The backup is meant to describe a wallet, never to unlock it. A stolen descriptor file does not let an attacker spend. It lets them understand.
There is no token attached to this. There is no protocol revenue, no incentive curve, no yield. That is worth saying plainly, because the crypto news cycle has trained readers to ask one question first: what does this do to price? The honest answer is nothing measurable. BIP138 is plumbing. But plumbing is where the industry's real fragility hides, and I have spent enough of my career watching keys become unrecoverable to know that plumbing failures are the ones people never forgive.
The Gap: A Seed Phrase Restores Keys, Not Policies
Bitcoin's proposal process is older than most of the assets people argue about on social media. BIP32 gave us hierarchical deterministic wallets. BIP39 gave us the mnemonic, the human-readable representation of a seed. BIP44 and its descendants gave us derivation paths so that two different wallets could agree on which address belongs to which account.
That stack solved one problem completely: getting from a single secret to many keys, reproducibly, across software written by strangers.
It never solved the reverse problem. Getting from many keys back to a working wallet.
Descriptors entered the picture to patch part of that gap. A descriptor is a compact, standard description of how a wallet manages keys and conditions. Instead of hoping a recovery tool guesses your derivation path correctly, a descriptor states it. Instead of guessing whether your multisig used sorted keys or preserved order, a descriptor says which.
Miniscript goes further, expressing composable spending conditions — this key after six months, these two keys together at any time, this key only with a hash preimage — in a form that software can reason about and verify.
The moment you accept those tools, you accept a consequence almost nobody writes down. The wallet exists in two halves. Half of it is secret material. Half of it is structural metadata. A seed phrase gives you the first half and nothing of the second.
So consider a two-of-three multisig. You recover one seed from a fireproof safe. You now hold one key out of three, which is mathematically worthless on its own. To rebuild the wallet you also need the xpubs of the other two cosigners, the exact ordering of keys in the script, the derivation path, and the policy template. If you wrote that down, congratulations. If it lived in a Telegram group with two people who have since changed phones, you have a very secure way to lock yourself out of your own money forever.
I have watched that failure mode up close, and it does not look like a hack. It looks like a person sitting very still.
During the Terra collapse in 2022, I ran a community initiative aggregating verified loss stories while debunking viral misinformation on Discord. I personally answered more than a thousand queries. The ones that stayed with me were not from people who had been liquidated. They were from people who could not explain their own wallet structure to me, and who therefore could not prove to anyone — including themselves — what they still controlled. Some of them held assets they had never truly been able to move since the day they set the wallet up.
That is the market BIP138 is addressing. Not speculation. Not yield. The quiet, permanent, unglamorous category of coins that exist and can never move again.
We protect each other by explaining, not by panicking.
How the Encryption Works, Step by Step
Here is the mechanism, laid out the way I would explain it to a reader who has never opened a descriptor file.
Step one. The wallet assembles its structural data: descriptors, policy, cosigner xpubs, fingerprints, derivation paths. Everything that describes the wallet without being able to spend from it.
Step two. The wallet verifies that no private key material has leaked into that payload. This is the checkpoint that worries me most, because it depends entirely on implementation discipline. The spec can require it. Only code review and testing can prove it happened.
Step three. An encryption key is derived from a qualifying extended public key.
Step four. The payload is encrypted and written to a file.
Recovery runs in reverse. Present the file and the qualifying xpub, derive the key, decrypt, reconstruct the wallet descriptors, then combine with the seed phrases or hardware devices you still control. At that point the wallet reconstitutes and your coins are spendable again.
The elegance is real. The file is small. Recovery is fast once you have the right inputs. There is no server in the loop, no identity verification, no third party holding a shard of anything. Compared with commercial recovery products, the trust surface is dramatically smaller.
The fragility is also real, and it sits in a single word: qualifying. Which xpub counts? What does the spec accept and refuse? That question is where the security model lives or dies, and it deserves far more attention than the headlines gave it.
The xpub Is the Key, and That Is the Whole Story
Most readers treat an extended public key as harmless. That instinct comes from one correct fact — an xpub cannot spend — and one incorrect assumption, which is that an xpub reveals nothing worth protecting.
An xpub reveals everything about the shape of a wallet. It lets software derive every receiving address, every change address, every future address. It lets anyone holding it watch the full balance and the full transaction history without ever touching a private key. That is precisely why watch-only wallets are useful. It is also precisely why watch-only wallets are dangerous in the wrong hands.
BIP138's confidentiality guarantee is therefore not a cryptographic guarantee at all. It is an assumption about secrecy. If the xpub stays secret, the backup file is secret. If the xpub has already been disclosed, the backup file is effectively public to whoever received it.
The reporting on this has been directionally correct and I want to give credit where it is due: the privacy tradeoff here is disclosed, not hidden. Any holder of a qualifying xpub who can access the backup file can decrypt and read the wallet structure and public keys. That is stated plainly. And to be equally fair, the same design note points out the boundary of the damage — an xpub alone cannot spend. This is a privacy compromise, not a funds compromise.
But I keep coming back to how thin the secrecy assumption is in practice. Where do xpubs actually travel? They get imported into portfolio trackers so a chart can show your cold storage. They get typed into block explorers to confirm an address belongs to you. They get shared with multisig coordinators so cosigners can build the same script. They get exported to tax software. They get pasted into group chats so a business partner can verify a receiving address. In 2017, during the EOS airdrop verification blitz, my team manually audited more than fifty thousand wallet addresses to separate genuine community holders from sybil attackers, and we published a live trust score dashboard. Every one of those checks ran on public key data. We never needed a private key once. We reconstructed holder behavior, clustering, and distribution patterns from public material alone, and we broke the story of inflated EOS token distribution three days before the mainstream press caught up.
That experience taught me something that generalizes directly to BIP138. The information you can extract from public key material is not trivial. It is a map. And a map of a vault is exactly what a well-prepared attacker wants, because social engineering a human being is far cheaper than breaking encryption.
The most uncomfortable detail in this entire proposal is also the simplest. If an xpub was already disclosed before the backup was created, the server or party that knows it may be able to decrypt that backup. Not in theory. As a direct consequence of how the key is derived.
What the Spec Refuses to Use, and Why That Matters
There is a defensive rule in BIP138 that deserves more credit than it gets, and it shows the designers were thinking about the right threat.
Public keys that appear directly in scripts — visible on-chain — are excluded from being recovery keys. If a pubkey has already been revealed in an output script, or as a taproot internal key, or through a revealed script path, it cannot serve as the qualifying xpub for a backup.
The reasoning is clean. On-chain data is permanent and globally readable. If anyone could take a pubkey visible on the blockchain and use it to decrypt an off-chain backup, the backup would be public by construction. Excluding those keys removes an entire attack surface.
The cost of that protection is complexity. Key management gets harder when some keys are disqualified because of how they were used. Wallet developers now need logic to check whether a candidate key has ever been exposed on-chain, and they need to handle the case where the only convenient key is ineligible. Complexity in key management is where implementation bugs live, and this spec adds a genuinely new class of it.
Still, I would rather have the rule than not. It is the kind of unglamorous design decision that prevents a catastrophe nobody would have predicted in advance, and it is evidence that the proposal's authors understood the difference between a privacy leak and a structural leak.
One Rust Implementation Is Not a Safety Certificate
There is a public Rust reference implementation. That is genuinely good news, and I want to be precise about what it proves.
It proves the design compiles. It proves someone with real skill cared enough to write working code against the specification. It proves the proposal is not a thought experiment scrawled in a GitHub issue.
It does not prove the cryptography is correct.
Reference implementations have historically been where subtle flaws hide: key derivation functions with inadequate parameters, nonce reuse that undermines a symmetric cipher, file format versioning that breaks forward compatibility, and — most relevant here — cases where the requirement to strip private key material is enforced in the happy path but not in error handling. I have audited enough code in this industry to know that the private-key-leak bug in a backup tool will not appear in the demo. It will appear in the edge case where a malformed descriptor triggers a fallback branch that was never reviewed.
There is no independent security audit attached to BIP138 as far as the public record shows. There are no widely circulated test vectors I can point a reader to. There is a draft specification and a reference implementation. That combination is a starting line, not a finish line, and anyone treating it as the latter is borrowing against a safety margin that has not been paid for yet.
Liana Already Ships a Different Backup Format
The most concrete adoption signal in this entire story is also the most inconvenient one. Liana, the wallet built around timelocked multisig recovery, already uses a backup format of its own. That format is not compatible with BIP138.
Read that again, because it reframes the whole narrative. The wallet most aligned with this proposal's purpose is currently shipping something that does not match it.
On one hand, this is evidence of real demand. Liana exists because people genuinely need to back up wallet structure, not just keys. Someone built a product around that pain, and people use it. That is the strongest possible argument that BIP138 addresses a real problem rather than an imagined one.
On the other hand, it is a warning about how standards actually arrive. They arrive late, they arrive fragmented, and they arrive with an installed base that has to be migrated. Existing users hold backup files in a format that BIP138 does not read. Do they regenerate? Do they run both formats in parallel? Does Liana ship a converter, and if so, does the converter handle every historical variant correctly? None of the answers are in the proposal, because proposals do not answer operational questions. Implementations do.
Merging into the BIPs repository guarantees none of this. It does not change the network. It does not obligate a single wallet to support the format.
Ledger Recover, Threshold Signatures, and Three Answers to One Question
Step back and the whole debate collapses into one question. When a cosigner's device dies, or a seed phrase goes missing, or a company dissolves, who or what puts the wallet back together?
Three philosophies compete.
The commercial answer is custodial recovery. Ledger Recover is the reference example: encrypted shards of your seed held by separate third parties, released after identity verification. The user experience is excellent. The trust requirement is enormous. You are asking a company, and the identity documents you supplied to it, to be available and honest at the worst possible moment.
The cryptographic answer is threshold signatures — FROST, ROAST, and their relatives. Here the key itself never exists in one place. Signing is a distributed computation. Recovery becomes a matter of reconstituting a quorum of participants rather than a file. It is beautiful, it is trust-minimized, and it is operationally heavy. Coordination, session management, and participant availability become the new failure modes.
The BIP138 answer is the metadata answer. Do not solve the key problem at all — solve the description problem. Encrypt the blueprint. Derive the key from public material. Hand the user a file.
Here is the tradeoff table as I see it, stated without decoration. Threshold signatures do not depend on off-chain metadata staying quiet, which makes them structurally stronger. BIP138 depends entirely on xpub confidentiality, which makes it structurally more fragile. But BIP138 requires no coordination and no counterparty, which makes it operationally simpler than either alternative. It is the most trust-minimized option if the secrecy assumption holds, and the most exposed option if it does not.
Neither side of that sentence gets to be omitted. That is the whole finding.
What This Does to Multisig, and to Bitcoin DeFi Built on Top of It
Trace the transmission and the picture gets clearer, and smaller, than the headlines suggest.
Miners are unaffected. Exchanges are unaffected. Ordinals and inscription activity are unaffected. There is no token, no television liquidity, no mechanism by which this news reaches a price chart.
Wallet infrastructure is where everything lands. Wallet teams need to implement export and import. Hardware wallet vendors may need to support encrypted backup files in companion software, which raises development cost but also gives them a genuine security story to sell. Multisig coordinators need to decide whether the descriptor file becomes the default recovery artifact or a supplementary one.
Longer term, the second-order effects matter more. If recovery reliability for complex wallets improves, the practical argument against multisig weakens. Multisig sits underneath a meaningful share of Bitcoin's custody arrangements, its lending desks, and its escrow tooling. Make those wallets less terrifying to operate and you modestly expand the population willing to run them. That is a slow, compounding benefit — and it is genuinely small in any single quarter.
I would also note who this is not for. Institutions custodying bitcoin at scale do not resolve their recovery problem with a descriptor file in a safe. They use qualified custodians, insurance policies, and legal recourse, because their risk model is legal and operational rather than cryptographic. That is not a criticism of BIP138. It is a reminder that the self-custody world and the institutional world keep solving the same problem with tools the other side cannot use. Anyone suggesting this proposal brings institutions onto public rails is describing a bridge that does not connect two landmasses.
Trust is built in public, one disclosure at a time.
The Contrarian Angle: The Industry Has No Culture of xpub Secrecy
Nearly every write-up frames BIP138 as a privacy-versus-convenience tradeoff, and that framing is correct but shallow. It implies the privacy cost is a known, bounded quantity that users can weigh. It is not, because the variable is not under the spec's control.
The unreported blind spot is cultural. This industry has spent a decade teaching people that seed phrases are sacred and everything else is shareable. We built an entire ecosystem of watch-only wallets, portfolio dashboards, tax aggregators, and block explorers on the premise that an xpub is safe to hand around. We never built the corresponding taboo. There is no equivalent of never share your seed phrase for extended public keys. There is no cultural instinct that says this string of characters is sensitive.
BIP138 assumes that taboo exists. Its entire confidentiality model rests on an xpub remaining private, at a moment when the practical norm is that xpubs get pasted into websites to generate a nice chart.
That mismatch is the real story, and it cuts deeper than a technical footnote. A backup standard whose security depends on a norm the industry never established is a standard that will be deployed incorrectly at scale, by well-meaning wallets serving users who believe they followed every rule.
And there is a sharper consequence than simple privacy loss. When descriptor structure leaks, the leak is not generic. It reveals how many cosigners exist, which hardware devices are involved, whether timelocks are present, and how the recovery path is configured. That is a targeting brief. An attacker who knows your vault is a two-of-three with a one-year timelock and one device that has not signed in eight months knows exactly who to call and exactly what to say. The threat is not theft through mathematics. It is theft through a phone call made by someone holding an accurate map.
Which leads to the counterintuitive conclusion I keep arriving at. The most dangerous version of BIP138 is not the one with a slightly weaker cipher. It is the one that ships quietly, earns a BIP number, and gets treated as safe by association. A BIP number signals peer review, consensus, and permanence to most readers. Draft status with no audit and no wallet adoption signals none of those things. The gap between those perceptions is where a generation of misconfigured backups will live.
What to Watch Next
The way to track this is not to watch the price of anything. It is to watch three signals, in order of importance.
First, the status line on the BIP itself. A move from Draft toward a last call or final status would indicate the developer community believes the design is stable enough to build against. Until then, treat everything about the format as provisional, and treat early adoption as a compatibility risk rather than a forward-looking bet.
Second, the first serious wallet integration. Watch release notes from Sparrow, Specter, and Liana specifically. Any one of them shipping official BIP138 backup support changes the conversation from proposal to practice. Liana is the most interesting case, because it already has users holding an incompatible format and a migration path to figure out.
Third, an independent audit of the Rust implementation. No amount of specification quality substitutes for a cryptographic review of the derivation scheme, the key handling, and the guarantee that private key material never enters the encrypted payload. That audit is the single most valuable thing that could happen to this proposal.
A draft is a promise to keep thinking. It is not a guarantee that anyone will.
Speed without clarity is just noise.
So here is where I land, and I want to be measured about it, because the temptation in this industry is always to swing between euphoria and dismissal. BIP138 is a serious, well-reasoned attempt at a real problem. The problem is real. The design is thoughtful, and the decision to exclude on-chain-revealed public keys shows the authors understood the threat model rather than merely describing it. There is working code. There is a genuine recovery gap in complex wallets that seed phrases simply do not close.
But it is a draft, the security model rests on a secrecy norm our culture never built, the file format is likely to change, the cryptography is unaudited, and the wallet ecosystem is already split across incompatible formats. Anyone building production recovery workflows on top of it today is taking on risk that has not been priced, measured, or disclosed to their own users.
The right posture is attention without urgency. Watch the audit. Watch the first real integration. Watch the status line.
And ask yourself one question, because it is the question the entire proposal turns on: what is a backup actually worth if it opens for anyone still holding the public data you handed out for free?
