BIP-85 is a deterministic mechanism for deriving fresh seed phrases (and other secrets) from an existing master seed. The child seeds are cryptographically independent — leaking one tells you nothing about the others or the master — but all are recoverable from the master plus an index. The typical use case is one cold-storage master backed up to the highest available standard, with child seeds derived for specific operational purposes (mobile hot wallet, Lightning node, separate wallets per family member, a passphrase factory); the pattern reduces irreplaceable backups from N to 1. The trade-off is sharp: the master becomes a single point of failure for everything downstream and must be protected at the level appropriate to total downstream exposure — a child key can only be as secure as its parent. BIP-85 is an operational convenience, not a security improvement: it does not harden the master, it just reduces what must be backed up. Whether the trade is right depends on master-backup hygiene and on whether multiple wallets genuinely need separate operational identities.
Why this note matters
BIP-85 is a feature most newcomers do not need and most intermediate holders do not engage clearly. The note matters because:
- It establishes BIP-85 as a backup-simplifier, not a security primitive. Holders who adopt it expecting “more security” are misreading the technology.
- It surfaces the concentrated single-point-of-failure that BIP-85 introduces — and the discipline required to live with it safely.
- It clarifies where BIP-85 fits in the configuration ladder: orthogonal to all rungs, useful for some holders, neutral or harmful for others.
The configuration ladder treats BIP-85 as Configuration 7, but the framing is misleading: BIP-85 is not a custody scheme of its own. It is a layer on top of whichever scheme the holder has chosen.
What this is
BIP-85 (Deterministic Entropy From BIP-32 Keychains, published 2020, Ethan Kosakovsky) specifies how a BIP-32 hierarchical-deterministic wallet can derive arbitrary new entropy values at specific derivation paths. The output formats include:
- BIP-39 mnemonics of 12, 18, or 24 words — fully-fledged child seed phrases
- HD-seed entropy of arbitrary length
- WIF private keys for single addresses
- PSBT random nonces for transaction-time entropy
- Arbitrary hex output for other applications
The most common use is BIP-39 mnemonic derivation. From one master mnemonic, the holder can derive an unlimited number of independent child mnemonics (in practice, limited by implementation conventions — Coldcard caps at 9,999 indexes).
How the derivation works
Each child derivation uses a specific path under the BIP-85 root (m/83696968'/). The path includes:
- The output type (BIP-39, hex, etc.)
- The output length (number of words, bytes)
- The index (a number distinguishing one child from another)
Example: m/83696968'/39'/0'/12'/0' derives a 12-word English BIP-39 mnemonic at index 0. m/83696968'/39'/0'/12'/1' derives a different 12-word mnemonic at index 1. The two are cryptographically independent — leaking one tells nothing about the other — but both are recoverable from the master seed plus knowledge of their indexes.
The “child seed is a real seed” property
A BIP-85-derived child seed is operationally a normal BIP-39 mnemonic. It can be restored to any compatible wallet without that wallet knowing it came from a BIP-85 derivation. The child is the seed; the BIP-85 derivation is just how it was generated.
This means a child seed, once derived, can be moved to a different device and used independently. The holder can derive a child mnemonic on their Coldcard for use on a phone wallet; the phone wallet doesn’t need to know about the master or about BIP-85 — it just imports a 12-word seed.
When to use this
BIP-85 is appropriate when:
- The holder runs multiple wallets for different purposes (hot, cold, Lightning, family-member, business) and wants to reduce backup count
- The holder has rigorous master-backup discipline that they can sustain across decades
- The holder understands that compromise of the master compromises every child
BIP-85 is not appropriate when:
- The holder has only one wallet — there is nothing to simplify
- The holder cannot articulate a master-backup standard equal to the total downstream exposure
- The holder wants more security — BIP-85 does not provide more security at the master level
The typical sensible pattern: BIP-85 for operational wallets (hot, Lightning, family spending) while keeping the savings wallet in a separate, non-BIP-85 setup. This bounds the BIP-85 master’s blast radius to wallets the holder is willing to lose entirely.
How it works in practice
Setup
The holder selects a master seed (12 or 24 words, generated normally on a hardware wallet). The master is backed up to the highest standard the holder can sustain — typically a 24-word seed on multiple metal backups in geographically distributed locations, because the master is now the single point of failure for the entire derivation tree.
The holder then derives child seeds at specific indexes for specific purposes:
- Index 0: 12-word mobile hot wallet
- Index 1: 12-word Lightning node seed
- Index 2: 12-word seed given to a partner
- Index 3: 12-word seed for a Lightning operational wallet
Each child seed is then used in its respective wallet. The hot wallet on the phone is initialized with the index-0 mnemonic; the Lightning node with the index-1 mnemonic; and so on.
The index discipline
The critical operational element: the holder must remember which index was used for which purpose. Lose the index, and even with the master, the holder cannot easily reconstruct a specific child — they face a search problem (try each index, see if it matches the wallet’s known balance or addresses).
The search is bounded: Coldcard caps at 9,999, so the search space is tractable. But the experience is unpleasant, particularly during recovery from a stress event. The defence: document the index assignments alongside the master backup.
The hardware-wallet UX
Coldcard, Trezor, BitBox, and some others support BIP-85 natively. The holder selects “derive child seed,” picks the type (BIP-39, etc.), specifies the length and index, and the device displays the child mnemonic. The holder records the mnemonic and uses it in the target wallet.
Some hardware wallets allow live use of a child seed without separately restoring — Coldcard can switch into “BIP-85 child wallet” mode on the fly. This is convenient but introduces a subtle exposure: the device is now operating with the child seed, and a compromise of the device exposes both the master and the active child.
Passphrase factory
A common BIP-85 use case: derive a child seed, then use the first few words of that mnemonic as the BIP-39 passphrase for a separate wallet. The passphrase is now deterministically derivable from the master plus a known index, eliminating the “passphrase only in my head” problem while preserving the passphrase’s exposure-protection benefit.
The pattern combines BIP-85 (which makes the passphrase recoverable from the master) with a passphrase-protected wallet (which makes the seed alone insufficient for exposure attacks). The result is a setup where:
- Compromise of the seed alone → useless (passphrase is missing)
- Compromise of the master + knowledge of the BIP-85 index → can reconstruct the passphrase and the seed → wallet is exposed
- Compromise of nothing → wallet is safe
This is a clean trade for some threat models. It centralizes loss risk on the master and exposure risk on the master-plus-indexes-knowledge.
Tradeoffs and considerations
The master is everything
BIP-85’s central trade: the master seed becomes a single point of failure for every child wallet. If the master is lost, every child is lost. If the master is compromised, every child is compromised.
This concentrates risk in a way that demands higher backup discipline than a standalone seed would. A holder who would normally back up a single 12-word seed in a home safe should, with a BIP-85 master used to derive operational wallets, treat the master at the level appropriate to the total downstream exposure. This typically means:
- 24 words rather than 12 (more entropy, partial-loss tolerance)
- Multiple geographically distributed metal backups
- Possibly stored under a trust structure or with a partner
- Possibly itself protected by SLIP-39 split
The discipline scales with how much the holder has riding on the master.
The “child wallet compromise does not affect siblings” property is real
BIP-85’s cryptographic guarantee: leaking one child seed tells nothing about the master or about sibling children. A compromised phone hot wallet does not compromise the cold wallet, even if both were derived from the same master.
This is the practical value of BIP-85. The holder can use child seeds in operationally-risky environments (phones, Lightning nodes, partner-shared wallets) without those operational risks contaminating the master or other wallets.
The privacy leak
If the master’s extended public key (xpub) leaks, every child’s xpub becomes computable. The wallets are still safe (xpubs don’t permit spending), but the addresses they contain are now linkable. Holders who care about privacy across child wallets should not publish or expose the master xpub.
For most personal-use cases this is a minor concern — the holder’s various wallets are already linkable through their own use patterns. For privacy-conscious holders, BIP-85’s privacy properties are weaker than separate-master setups.
BIP-85 is not a backup substitute
A common misconception: “I’ll back up just the master, and the children are recoverable, so I’m protected.” This is true cryptographically. It is incomplete operationally.
The children’s wallets contain on-chain history, address discovery, and operational state that the master alone does not reconstruct. To fully recover a child wallet, the holder needs the master + the BIP-85 index + the child’s derivation path + (for some wallets) the child’s wallet-specific configuration. Documentation of these alongside the master is essential.
Multisig + BIP-85 is constrained
A holder may want to use BIP-85 children as keys in a multisig. The constraint: not all keys should be BIP-85 children of one master, because that collapses the multisig’s security model — a compromise of the master would compromise every multisig key.
The acceptable pattern: at most some of the multisig keys are BIP-85 children (typically the holder’s keys), and at least one key (typically the partner’s key or a separately-generated key) has independent entropy. This preserves the multisig’s structural protection.
Comparison with alternatives
| Approach | Backup count | Compromise blast radius | Index discipline | Operational complexity |
|---|---|---|---|---|
| Multiple independent seeds | N seeds, all backed up | Each seed compromise affects one wallet | None | High — N backups to manage |
| BIP-85 master + children | 1 master backed up; children recreatable | Master compromise affects all; child compromise affects one | High — index assignment must be documented | Medium — single backup but index discipline |
| Passphrase-only multi-wallet | 1 seed + N passphrases | Compromise of seed + any passphrase exposes that wallet | Passphrase discipline per wallet | Medium-to-high — passphrase backup per wallet |
| SLIP-39 split for the master | Master split into shares | Threshold of shares needed | Index + shares | Higher — SLIP-39 + BIP-85 layered |
The principal alternative to BIP-85 is independent seeds for each wallet. The trade-off: BIP-85 reduces backup count (good) at the cost of concentrating risk (bad). For holders with one or two wallets, independent seeds are typically cleaner. For holders with five or more wallets and strong master-backup discipline, BIP-85 is meaningfully simpler.
Tiered recommendations
Tier 0: Don’t use BIP-85. Single phone wallet is sufficient; there is nothing to simplify.
Tier 1 (50K): Generally don’t use BIP-85. Most Tier 1 holders have one or two wallets; the operational complexity of BIP-85 is not justified.
Tier 2 (1M+): Optional. Holders with multiple operational wallets (mobile, Lightning, business, family) may benefit. The trade requires master-backup discipline equal to total downstream exposure. The recommended pattern: BIP-85 for operational wallets only; the savings wallet remains a separately-generated seed.
Tier 3 (>$1M): BIP-85 is often appropriate as part of a tiered operational setup, with explicit attention to the master’s protection level. The master should be itself SLIP-39-split or otherwise protected at the level appropriate to its blast radius.
In all tiers, the principle is: BIP-85 is a convenience layer, not a security layer. Its value is proportional to the number of downstream wallets it consolidates; its cost is the concentration of risk on the master.
Common pitfalls
Using BIP-85 with a single downstream wallet. There is nothing to simplify, and the master-backup overhead is now wasted complexity.
Forgetting the index assignment. “I have the master and I derived a wallet from it but I don’t remember which index” is a recoverable problem (search through indexes), but a stressful one. Document the assignments alongside the master backup.
Inadequate master backup. Treating the master at the level appropriate to a single wallet, when it is actually the source of multiple wallets, is the most consequential mistake. The master’s backup discipline must scale with total downstream exposure.
Using BIP-85 for all keys in a multisig. Collapses the multisig’s security model. At least one key in the multisig should have independent entropy.
Master xpub exposure. Leaking the master extended public key allows correlation of all child wallets. For most personal-use cases this is minor; for privacy-conscious holders, this is meaningful.
Treating BIP-85 as more secure. It is not. The master is now the single point of failure for everything. Confidence in BIP-85 should be based on confidence in the master-backup discipline, not on the cryptography.
Using a hot-wallet seed as a BIP-85 master. The master must be protected at the level appropriate to the total downstream exposure. If the master is itself stored in a hot wallet (phone, online software), every BIP-85 child inherits that exposure.
Not documenting the BIP-85 setup for heirs. A heir who finds only the master seed has to know that BIP-85 was used, what indexes were used for what purposes, and what wallets to load each child into. Without documentation, the heir may not even realize that child wallets exist.
Tooling and resources
The synthesis document (canonical for the section):
- Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — BIP-85 treatment as an orthogonal layer.
Underlying specifications:
- BIP-85 — Deterministic Entropy From BIP-32 Keychains, Ethan Kosakovsky (2020). The canonical specification.
Primary practitioner sources:
- BitBox — BIP-85 Operational Guide (the BitBox team’s framing: “a child key can only be as secure as its parent key”)
- Coldcard — BIP-85 implementation documentation; details the 9,999-index cap and live-use modes
- Trezor — BIP-85 support documentation
- Lopp — passing treatment in operational essays; see Jameson Lopp
As of 2026-05-14: BIP-85 is supported natively in Coldcard, Trezor (newer firmware), BitBox02. Some software wallets (Sparrow, others) can use BIP-85-derived seeds but do not derive them. The hardware-wallet-derivation pattern is the standard.
Open questions for further development
- The synthesis treats BIP-85 as Configuration 7 of the configuration ladder, but BIP-85 is structurally orthogonal to the other configurations rather than a rung on the same axis. Should the configuration-ladder framing be revised to handle this more cleanly?
- The “BIP-85 child as passphrase” pattern is elegant but adds operational complexity. Is it the right answer to the passphrase-inheritance problem, or does SLIP-39 split of the passphrase achieve the same goal more simply?
- How does BIP-85 interact with future post-quantum migrations? If the master seed is compromised by a quantum break of ECDSA, every BIP-85 child inherits the compromise. The migration path for BIP-85 wallets is not well-specified.
- Should the framework recommend a specific master-protection standard for BIP-85 users? “Equal to total downstream exposure” is the principle, but operationalizing it requires holders to think clearly about what total downstream exposure means.
Related notes
The framing lenses:
- Loss vs exposure failure modes — BIP-85 concentrates both types of risk on the master
- Threat modeling for self-custody — BIP-85’s blast-radius profile shapes which threats it addresses
- Self-custody configuration ladder — BIP-85 as the orthogonal Configuration 7
Other storage and key concept notes:
- Seed phrases and BIP-39 — the BIP-39 seed format BIP-85 derives
- Passphrases and the 25th word — the passphrase-factory pattern
- SLIP-39 and Shamir Secret Sharing — the alternative split scheme
- Hot vs cold storage
- PSBT and wallet descriptors
Hardware wallets supporting BIP-85:
- Hardware wallets overview
- Coldcard — strongest BIP-85 support
- Trezor — native support
- BitBox — native support with explicit guidance
- Foundation Passport — limited support
Operational discipline:
- Backup strategies for seeds — master-backup discipline for BIP-85 setups
- Recovery rehearsal practice — including child-wallet recovery
- Common failure modes in self-custody — BIP-85 index-loss failure mode
The principal practitioner:
The sub-MOC home: