A BIP85 child wallet is not a second secret you wrote down once and forgot about. It is a deterministic output of a root key plus a short list of settings, which means it can come back two different ways. Confusing those two routes is how a recovery kit ends up failing to recover the wallet it was built for.
Two routes to the same wallet
The first route is regeneration. If you still have the original BIP32 root and the exact BIP85 parameters, the same child mnemonic is reproduced every time. The second route is direct restoration: keep the child mnemonic itself and skip the derivation entirely. Both routes still need the child wallet’s BIP39 passphrase, if one was set, and the wallet’s account configuration. The point to remember is that the two routes record different things, and neither one is a substitute for the other.
What regeneration must record
Regeneration depends on five fields, and each one has to be written down exactly: the method that reconstructs the original root, the BIP85 application (BIP39), the wordlist language, the word count, and the child index. BIP85 turns a hardened child key into entropy with HMAC-SHA512, and changing any of those fields selects a different derivation instead of failing loudly. A nickname like “spending wallet” is not a record; write the index and the word count explicitly, and do not confuse the BIP85 index with an account index inside the resulting wallet.
The passphrase that never errors
The passphrase is where recovery goes wrong quietly. Under BIP39, the passphrase takes part in seed generation, and an empty string is used when none is set. Because every passphrase produces a valid seed, a mistyped child passphrase does not raise an error: it just derives a different wallet. Label the parent-root passphrase and the child-wallet passphrase separately, and state explicitly when either one is empty. A device PIN, an account path, or the BIP85 index is none of these.
What a child mnemonic does not record
A directly retained child mnemonic has limits worth writing down too. It restores that child’s seed, but it does not record the root’s other children or their indices, and it says nothing about the wallet’s account paths or policy. BIP32 keeps key derivation separate from wallet structure on purpose, so “the mnemonic restored” is not the same as “the wallet is fully recovered.” Keep account paths and wallet policy as their own record. A public-only extended key can watch balances but cannot perform hardened derivation, so a watch-only export is monitoring, not a backup.
A five-point review
For the next recovery review, take one child and confirm five things: the root recovery method, the BIP85 application, the language, the word count, and the index, then check the passphrase requirement and the account configuration separately. One more point deserves a plain statement: holding the root concentrates recovery power, because anyone with the root and the settings can regenerate every child. Hardened derivation keeps children from being derived from public information; it does not make them independent of a compromised root. Decide deliberately how that root is protected, and confirm the signer’s documented procedure before entering recovery secrets into a website or erasing the only working signer.
Source: BTCUSA.