BIP 138: an encrypted backup for the map to your boxes

Updated September 2026

A seed phrase lets you sign. For a multisig or miniscript wallet, it does not tell you which scripts hold your coins: that is the descriptor's job. BIP 138 gives descriptors an encrypted, compact backup format whose key is the wallet's own list of xpubs, so every cosigner can open it and a stranger who finds it in a cloud folder learns nothing about your boxes.

What was merged, and when

BIP 138, titled "Compact Encryption Scheme for Non-seed Wallet Data", was merged into the bitcoin/bips repository on September 21, 2026, through pull request #1951. The author is Pyth, of Wizardsardine, who opened the pull request in September 2025. The BIP number was assigned on May 11, 2026. Its status is Draft and its type is Specification: it defines a file format, not a change to Bitcoin's rules.

The design grew out of a Delving Bitcoin post by bigspider proposing a simple backup scheme for wallet accounts. The BIP credits Sjors with extensive review and a proof-of-concept on top of Bitcoin Core. Review has not stopped at the merge: on September 23 Sjors opened three follow-up pull requests with clarifications, including one on exactly which keys can decrypt.

Why a descriptor backup matters

An output script descriptor is a short text description of which scripts a wallet uses: which keys, which derivation paths, which spending conditions. A wallet policy, defined in BIP 388, is a more compact template form of the same idea. The BIP's motivation section opens bluntly: "Losing the wallet descriptor (or wallet policy) is almost as catastrophic as losing the seed itself."

For a plain single-signature wallet, recovery software can usually rebuild the addresses by trying common derivation paths. For multisig and miniscript wallets it cannot. The BIP gives the reason: "keys alone are insufficient: without the descriptor, you can't reconstruct the script."

It also gives a less obvious trap. A wallet might be set up as a 3-of-3 MuSig2 key path with a 2-of-3 recovery script, precisely so that losing one seed is survivable. But the recovery script needs all three public keys to be rebuilt. Lose one seed and you may have lost the only copy of its public key too. The BIP calls this risk "not intuitive," and that is the case a descriptor backup is for.

Why descriptors are awkward to store

The BIP names two obstacles. Descriptors are long, much longer than 12 or 24 words, so paper and steel backups become impractical, while USB sticks degrade and do not survive fire or flood. And putting them online leaks. A plaintext descriptor in a cloud folder, the BIP says, exposes "your pubkeys and script details."

That second point connects straight to this site's theme. A descriptor contains extended public keys. From an xpub, anyone can derive the public key behind every address in that account, including the ones you have never spent from. On the chain, those addresses are closed boxes: only a hash is public. To whoever holds your descriptor, they are not. As our page on xpubs and watch-only wallets puts it, an xpub is a window onto every box you will ever put on the porch.

The exposure classification draft submitted in September explicitly left this kind of disclosure out of scope, because nothing on the chain records it. BIP 138 is the practical answer to it: keep the map, but lock it.

How the lock works

The clever part is where the key comes from. The wallet already has a set of secrets that every cosigner holds and no outsider does: the xpubs themselves. BIP 138 turns that list into the encryption key.

• Take the root public key of each eligible xpub in the descriptor, reduce each to its 32-byte x coordinate, and sort them.
• Hash the sorted list with a tagged SHA256 hash. That is the decryption secret.
• For each key separately, compute a second tagged hash and combine it with the decryption secret by XOR. Store these "individual secrets" in the backup.
• Encrypt the descriptor with ChaCha20-Poly1305, the same cipher Bitcoin Core uses for its encrypted peer-to-peer transport, using a random 96-bit nonce.

To decrypt, a cosigner hashes their own xpub, XORs it against each stored individual secret in turn, and tries each result as the key. One of them works if, and only if, their key was in the descriptor. The BIP spells it out: decryption "will succeed if and only if p was one of the keys." No password, no extra secret to lose, and no private key needed, which matters because, as the BIP notes, secure signing devices may not yield private key material at all.

Note what the secrecy rests on. The cipher is symmetric and the key is a hash. What keeps the backup private is that the xpubs stay private, the same condition that keeps your unspent addresses' public keys off the table.

Why a public key seen on the chain cannot open it

A backup keyed to public keys would be useless if the same public keys appeared on the chain every time you spent. BIP 138 closes that door with a rule about which keys count.

Only xpubs followed by at least one more derivation step, or a wildcard, are allowed into the key list. The key that signs on the chain is always a child of the xpub, never the xpub's root key itself, so watching your spends reveals child keys and nothing that recomputes the secret. Literal public keys and bare xpubs are excluded for the reason the BIP gives in a footnote: "the literal value is exactly what goes on-chain." Implementations must also exclude the well-known unspendable NUMS point from BIP 341, which Taproot wallets use as a placeholder internal key, since everyone already knows it.

If excluding keys leaves the list empty, the wallet must refuse to create the backup. If it excludes a cosigner's key, it must tell the user, because that cosigner will not be able to decrypt.

The warning about xpubs you already gave away

The whole scheme assumes the xpubs are not public. The BIP includes a warning that deserves a place in every multisig setup guide. Some single-signature wallets, and it names the Ledger and Trezor desktop apps, send the account xpub to a server so the server can find your addresses. For a single-signature wallet that "leaks little the server does not already know." But reuse that same account xpub as one key of a multisig, and that server can "decrypt every backup of the multisig."

The advice is specific: build multisig wallets from accounts whose xpub was never sent to such a server, such as BIP 48 or BIP 87 accounts. It is the same principle as address reuse, one level up. A key used in one context carries its history into the next.

What the backup hides, and what it does not

An encrypted file can still leak through its shape. BIP 138 tries to limit that.

• Number of cosigners: encoders should add random decoy individual secrets, rounding the count up to 5, 10, 20 and so on, so a 2-of-3 and a single-signature backup can look alike.
• Derivation paths: optional. Recovery software should try common paths automatically, including BIP 44, 49, 84, 86, 87 and 48 accounts 0 to 9.
• Size over time: for backups that change, like address labels, encoders can pad the payload to fixed buckets starting at 10 KiB, so a cloud provider cannot watch your activity through file sizes.
• Fingerprints: none in the clear, because they would identify participants.

What it does not do is protect secrets. The specification is explicit that private key material must be removed before encrypting, because the scheme is unlocked with public information. A BIP 138 file sits next to your seed backup. It never replaces it. And anyone who holds any one of the wallet's xpubs, including a cosigner you later fall out with, can read it.

Key facts, with dates

• September 2025: pull request #1951 opened by Pyth (Wizardsardine).
• May 11, 2026: number 138 assigned.
• September 21, 2026: merged into bitcoin/bips as a Draft specification.
• September 23, 2026: three follow-up pull requests opened with clarifications and extra test vectors.
• Covers: BIP 380 descriptors, BIP 388 wallet policies, and metadata such as BIP 329 labels.
• Format: binary with the magic bytes "BIP138", a .bip138 file extension, or Base64 text in a .txt file.
• Compatibility: the Liana wallet uses an early version that is not compatible; its files start with "BEB" instead.

What to do now

Nothing changes on the chain, and nothing about your coins changes. For your backups, a few points follow from the BIP:

• If you run a multisig or miniscript wallet, make sure the descriptor or wallet policy is backed up somewhere, not only the seeds. Without it, recovery can fail even with enough keys.
• Do not keep a plaintext descriptor in cloud storage or email. It hands out the public keys behind your closed boxes.
• When your wallet software offers a BIP 138 export, a .bip138 or Base64 file can safely live in several places, which is the whole point.
• Keep seeds and descriptors separate. The seed stays offline, as described in hardware wallets and the box.
• Check where your xpubs have already gone before reusing an account in a multisig.