BIP-85 (Deterministic Entropy)

What Is BIP-85?

BIP-85 (Bitcoin Improvement Proposal 85), titled "Deterministic Entropy From BIP32 Keychains," is an informational standard authored by Ethan Kosakovsky that defines a method for generating new entropy from an existing BIP-32 hierarchical deterministic (HD) wallet master key. That derived entropy can then be used to create entirely new seed phrases, private keys, or other cryptographic material for separate wallets and applications.

The core problem BIP-85 solves is backup complexity. A user who operates a Bitcoin wallet, a Lightning wallet, a Nostr identity, and a password manager might have four separate seed phrases to store securely. Each additional seed phrase increases the risk that one gets lost, stolen, or improperly backed up. BIP-85 collapses this into a single backup: one master seed from which all others can be regenerated on demand.

Unlike BIP-44 or BIP-84, which derive addresses and keys within a single wallet, BIP-85 derives the root entropy for entirely separate wallets. Each child wallet has its own independent BIP-39 mnemonic or key material, and the child wallet itself has no knowledge of the master seed that created it.

How It Works

BIP-85 builds on top of the existing BIP-32 key derivation infrastructure. The process starts with a standard BIP-32 master root key and uses a specific derivation path to produce raw entropy for child applications.

1. Start with a BIP-32 master root key (derived from a BIP-39 mnemonic or any valid seed)
2. Derive a fully hardened child private key using the BIP-85 derivation path
3. Pass the child private key through HMAC-SHA512 with the key string "bip-entropy-from-k" to produce 64 bytes (512 bits) of entropy
4. Truncate the output to the number of bits required by the target application (for example, 128 bits for a 12-word mnemonic, 256 bits for a 24-word mnemonic)
5. Feed the truncated entropy into the target application's standard process (such as BIP-39 mnemonic generation or WIF encoding)

The derivation path follows the format m/83696968'/{app}'/..., where 83696968' is the BIP-85 purpose code and every path component uses hardened derivation. The fully hardened path ensures that no child key can be used to work backward to the parent, even if an attacker knows the derivation scheme.

Derivation Path Structure

Each application type has its own sub-path under the BIP-85 purpose code. The most commonly used application paths are:

For BIP-39 mnemonics, the language parameter is 0' for English, and the words parameter specifies the mnemonic length: 12', 18', or 24'. The index parameter allows generating multiple children of the same type by incrementing the index value.

Example: Deriving a 12-Word Child Seed

To derive the first English 12-word child mnemonic from a master seed, the path would be:

# BIP-85 derivation path for first 12-word English child
m/83696968'/39'/0'/12'/0'

# Breaking down the path:
# 83696968' = BIP-85 purpose code
# 39'       = BIP-39 mnemonic application
# 0'        = English language
# 12'       = 12-word mnemonic (128 bits of entropy)
# 0'        = child index 0 (first child)

# The derived HMAC-SHA512 output is truncated to 128 bits
# Those 128 bits are converted to a 12-word BIP-39 mnemonic
# Changing the index to 1' produces a completely different mnemonic

Supported Output Formats

BIP-85 defines several application types, each producing a different form of cryptographic material from the same master seed:

• BIP-39 mnemonics (application 39'): generates standard seed phrases in 12, 18, or 24-word formats across multiple languages. This is the most widely used BIP-85 application, allowing one master seed to produce independent wallet recovery phrases.
• HD-Seed WIF (application 2'): produces a Wallet Import Format private key suitable for legacy Bitcoin wallets that accept a single WIF key as their seed.
• XPRV (application 32'): generates an extended private key that can serve as the root of a new HD wallet tree without requiring a mnemonic intermediary.
• HEX entropy (application 128169'): produces raw hexadecimal entropy of a specified byte length, useful for applications that need raw randomness rather than a formatted key.
• Passwords (BASE64 and BASE85): generates deterministic passwords of specified lengths, enabling password manager functionality from a hardware wallet.
• DICE (application for dice-based output): produces deterministic dice rolls, useful for generating entropy in formats compatible with offline backup schemes.

Why It Matters

Managing cryptographic secrets is one of the hardest problems in self-custody. Every new wallet or application typically requires its own seed phrase, and each seed phrase needs secure physical backup. For users running multiple wallets across different platforms, the backup burden grows quickly and becomes a point of failure.

BIP-85 directly addresses this by reducing the number of secrets a user must protect to one. A single steel plate backup of the master seed is sufficient to recover every child wallet, regardless of how many were created. This matters especially for self-custody setups where users manage separate wallets for different purposes: a cold storage wallet for long-term savings, a hot wallet for spending, a Lightning node, and perhaps a Nostr identity.

For developers building wallet infrastructure, BIP-85 simplifies key management architectures. A wallet SDK can derive application-specific keys from a single root without exposing the root itself to any individual application. Projects like wallet SDKs increasingly consider BIP-85 as part of their key management strategy.

Use Cases

Single Backup for Multiple Wallets

The primary use case for BIP-85 is consolidating backup responsibility. A user stores their master seed on a hardware wallet and derives child seeds for different purposes:

• Index 0: a 24-word seed for a cold storage Bitcoin wallet
• Index 1: a 12-word seed for a mobile spending wallet
• Index 2: a 12-word seed for a Lightning node
• Index 3: hex entropy for Nostr key generation

If any child device is lost or destroyed, the user recovers the child seed from the master by re-deriving the same path and index. The master seed backup is the only one that requires physical security measures like metal plates or vault storage.

Compartmentalized Security

BIP-85 enables operational security through compartmentalization. A user can load a derived child seed onto a device that operates in a less secure environment (such as a phone or always-online computer) without risking the master seed. If the child device is compromised, the attacker gains access only to that child's wallet. They cannot derive the master seed, sibling seeds, or any other child wallet.

Hardware Wallet Workflows

Hardware wallets with BIP-85 support enable a powerful workflow. A Coldcard, for example, can serve as the master seed vault and derive child seeds that are then loaded onto other devices:

1. Set up the Coldcard with a strong 24-word master seed
2. Use the BIP-85 menu to derive a 12-word child seed at index 0
3. Load that child seed into a SeedSigner or mobile wallet
4. The child wallet operates independently, with no connection to the Coldcard
5. If the child device is lost, re-derive index 0 on the Coldcard to recover

This workflow is supported by Coldcard, BitBox02, Foundation Passport, SeedSigner, and Specter DIY. Each device can serve as either the master (deriving children) or the child (receiving a derived seed).

Deterministic Password Generation

BIP-85's password application turns a hardware wallet into a deterministic password manager. Each index produces a unique, high-entropy password that can be regenerated from the master seed at any time. This eliminates the need for a separate password database while ensuring passwords are never stored on any connected device.

Risks and Considerations

Single Point of Failure

BIP-85's greatest strength is also its greatest risk. While it reduces the number of backups, it concentrates all security into a single master seed. If the master seed is compromised, every child wallet derived from it is compromised. If the master seed is lost and no backup exists, every child wallet is irrecoverable.

This makes the physical security of the master seed backup critically important. Users should consider Shamir's Secret Sharing or multisig arrangements for protecting the master seed, rather than relying on a single metal plate in a single location.

Forward Secrecy Limitations

BIP-85 derivation is deterministic and one-directional, but not forward-secret in the parent direction. A compromised child cannot reveal the parent, but a compromised parent reveals all children. There is no way to "rotate" a single child seed without changing the master seed, which would invalidate all other children.

In practice, this means if you suspect your master seed may be compromised, you must treat every child as compromised and migrate all funds to wallets derived from a new master seed.

Limited Wallet Support

While BIP-85 is supported by several hardware wallets, it is not universal. Software wallets and mobile wallets generally do not implement BIP-85 derivation. Users must verify that their specific wallet supports BIP-85 and implements it correctly before relying on it for backup recovery.

Cross-implementation compatibility should be verified using the official test vectors published in the BIP-85 specification. A child seed derived on one device should produce the same mnemonic when derived from the same master seed on a different device.

Passphrase Interaction

If the master seed uses an optional BIP-39 passphrase, the passphrase becomes part of the root key derivation. Different passphrases produce different master keys and therefore different BIP-85 children. Users must remember and back up both the mnemonic and the passphrase to recover any derived children.

Index Tracking

BIP-85 requires users to remember which index and application type they used for each child wallet. Unlike HD wallets that can scan for used addresses via the gap limit, there is no automatic discovery mechanism for BIP-85 children. Losing track of which index was used for which purpose means manually trying each index until the correct child seed is found.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.