A Bitcoin seed restores key material, not the notes you attached to it. Enter the same mnemonic in a new wallet and your addresses come back. The labels that explain which payment was a salary, a refund, or a long-term holding do not. Those notes live in the wallet’s own metadata, and unless you export them on purpose, a seed restore quietly leaves them behind.
Three recoveries, three different questions
It helps to split wallet recovery into three tasks that can succeed or fail on their own. Signing-secret recovery reproduces the keys a signer needs to spend. Script and account reconstruction rebuilds the derivation paths and descriptors that identify those keys. Annotation preservation keeps the human-readable notes attached to transactions, addresses, and outputs. Passing one check proves nothing about the other two.
The standards draw the same line. BIP-32 specifies a system for deriving a tree of keypairs from a single seed, which is why a seed can reproduce keys but carries no user-written labels. BIP-380 defines output descriptors that record script types and derivation paths so a backup can reconstruct what to sign. Neither standard moves the note that explains why a payment happened.
What a BIP-329 export contains
BIP-329, “Wallet Labels Export Format,” is a Draft and Informational standard for portable wallet annotations. It uses UTF-8 JSON Lines: one valid JSON object per line, with multiline values forbidden. Every record needs a type and a ref that say what the note points to. The common types are tx (a transaction ID), addr (a base58 or bech32 address), and input and output (a transaction ID plus an index), alongside public-key, extended-public-key, and silent-payments records.
Three properties stay optional: label, origin, and spendable. The origin field is an abbreviated BIP-380 output descriptor that carries key-origin information but no actual keys, child paths, or checksum. Its job is to separate labels from different accounts derived from one seed. The spendable field applies only to output records and marks whether the wallet should treat an output as spendable.
Read the import rules before you trust a migration
The format is permissive in ways that matter during a move. If label or spendable is omitted, the importing wallet should leave the existing value alone; a missing label is not an instruction to clear a note. An importing wallet may also skip records it does not store and truncate labels it cannot fit, with a suggested 255-character cap. BIP-329 defines no private-key record type, so a label export is bookkeeping, not a backup that restores spending power.
Treat the file as sensitive anyway. It can hold addresses, transaction references, extended public keys, and descriptions that tie payments to people or purposes. Encrypt it in transit and at rest, and delete plaintext copies you no longer need.
A migration checklist
Before you retire an old wallet, name the record types you use and export them through the wallet’s documented process. Verify a few important examples in the new application: a long note, an account-origin field, and an output restriction if you keep one. Compare records by type and reference rather than by wording, because a transaction-level note and an output-level note can share identical text yet point to different objects. Keep the original metadata until you have checked unmatched references and truncated notes.
Adapted from Bitcoin Wallet Labels After a Seed Restore: What to Back Up.