The Bitcoin proposal process separates application agreements from consensus changes. A wallet format can become useful because software authors adopt it, without changing which blocks the network accepts. The current BIP process uses document statuses including Draft, Complete and Deployed, with definitions appropriate to a proposal's type. Those labels organize technical work. They do not certify a particular wallet vendor or force every application to implement a format. Compatibility is established through supported behavior and tests, rather than simply the presence of a BIP number.

Bitcoin Core's descriptor documentation records scripts, key origins and derivation paths together. The practical implication is that wallet reconstruction needs the intended structure, not merely some keys. When another application reads a compatible descriptor, it can determine which outputs the described configuration watches.

BIP-32 describes hierarchical deterministic wallets, deriving a tree of key pairs from a seed. An extended public key can generate appropriate descendant public keys for watching payments without being able to spend. That separation helps a receiving server or watch-only wallet work without holding the corresponding secret. Hardened derivation changes what can be derived from public information. The specification warns that a parent extended public key combined with a non-hardened descendant private key can reveal the parent secret. Sharing public derivation data therefore deserves care.

BIP-85 uses a BIP-32 root to derive entropy for other key or mnemonic systems. Its motivation is managing several otherwise incompatible backups while avoiding reuse of the same seed across many wallets. This differs from putting every asset in one wallet application. Derived secrets can be separately used, while the root remains a powerful recovery and compromise point. The convenience of reducing backup count must be weighed against the consequences of losing or exposing that master arrangement.

BIP-39 encodes computer-generated entropy with a checksum into words and converts the mnemonic, plus an optional passphrase, into a seed. Its standard lengths run from 12 to 24 words. The specification explicitly distinguishes this from inventing a memorable sentence as a brainwallet. Every passphrase produces a valid seed, so mistyping a passphrase can open a different, apparently empty wallet. The words, their order and the intended passphrase must all match; a successful import screen does not prove the expected funds were recovered.

Electrum's own seed documentation explains its alternative versioned format and why Electrum does not generate BIP-39 seeds. Its criticism focuses on fixed wordlists and the absence of a version identifying how to derive an account. This is a documented design disagreement, not evidence that one familiar word count works everywhere. Two phrases containing natural-language words may use different algorithms. Identify the original wallet's format before recovery and follow compatible instructions rather than assume every mnemonic field accepts every backup.

SLIP-0039 is a separate Final specification from SatoshiLabs for threshold shares expressed as mnemonics. Enough shares reconstruct a master secret, while an insufficient set cannot. This is different from cutting a BIP-39 word list into pieces, and it is not a multisignature spending policy. Compatibility depends on wallets supporting that share format and its recovery process. Threshold design addresses a backup distribution problem, but users still need an intelligible plan for locating sufficient shares and understanding any associated passphrase.

BIP-44 places keys under purpose, coin type, account, change and address index. It distinguishes receiving and change branches and describes account discovery using a gap limit of 20 unused addresses. These conventions help another wallet find familiar accounts, but they are assumptions, not an exhaustive search of every possible derivation. If an application used another path or created a large gap, a normal scan may miss funds. The correct response to an empty view is to verify the recorded structure before concluding the coins vanished.

BIP-49 separates wrapped SegWit accounts under purpose 49, and BIP-84 uses purpose 84 for native SegWit single-key accounts. They intentionally make unsupported account types fail visibly instead of silently mixing incompatible address behavior. A compatible seed is therefore only part of compatibility. The recovering wallet must recognize the account purpose and script type, with the right network and account index. Similar key material can produce several different address families, and an address derived from one family is not evidence the others were scanned.

BIP-86 assigns purpose 86 to single-key Taproot accounts and specifies how the derived internal key becomes a Taproot output key. It addresses wallets relying on seed backups that do not carry script information. This convention helps implementations agree where to look. It does not cover every possible Taproot script policy or automatically describe a multisignature vault. Record the actual account structure and supported spending paths rather than treat the word Taproot as one universal wallet layout.

BIP-48 describes a hierarchy for multisignature wallets, separating script types under the account structure. Different participants can derive the intended keys consistently, but a participant's seed alone does not describe the whole group arrangement. Recovery also requires the other public keys, threshold and script construction. This is why a multisignature setup should preserve its policy alongside separate signing backups. Having the required number of secrets is only useful when a recovering application knows which combined spending condition those secrets were intended to satisfy.

BIP-67 specifies lexicographic ordering of compressed public keys for a deterministic multisignature redeem script. Without agreement on ordering, participants can combine the same keys into different scripts and addresses. The standard solves an interoperability detail with large practical consequences. It does not tell participants whom to trust, where to store keys or how to replace a lost signer. Those are operating arrangements above the format. Verifying a common receiving address and recording the complete configuration remains part of coordinating the group.

BIP-383 defines multi and sortedmulti descriptor expressions containing a threshold and public keys. The former preserves the listed order; the latter sorts keys when constructing a script. That distinction makes the spending condition explicit for software reading the descriptor. A public descriptor can identify the arrangement without containing the secrets needed to authorize payment. It still contains sensitive financial structure and derivation information. Storing the policy safely should not be confused with publishing it to every service that requests a wallet connection.

BIP-174 defines the Partially Signed Bitcoin Transaction format, including the original version 0. It carries transaction information and fields needed by signers, then collects signatures until the spending conditions can be completed. A coordinator can construct the payment while a separate device signs it, including offline workflows. This is a container for collaboration, not a separate coin or a new consensus transaction. A fully prepared file still requires signers to verify the intended outputs, fees and relevant spending conditions before authorization.

BIP-370 defines PSBT version 2, allowing inputs and outputs to be added during construction and distributing transaction information into the relevant maps. There is no PSBT version 1 in this lineage; that number was skipped to avoid historic naming confusion. Version compatibility is a real feature boundary for coordinators and signers. The ability to add fields or modify a transaction during preparation does not mean an existing signature authorizes every later change. The chosen signing conditions and implementation must be considered together.

BIP-371 adds Taproot-related fields to PSBT, including signatures, scripts and derivation information needed for applicable spending paths. It supports both version 0 and version 2 containers. This demonstrates how format evolution and network features interact without being identical. A signer may accept a PSBT file yet lack the fields or policy support needed for a particular input. Applications should identify actual supported script and signature paths, rather than interpret generic PSBT support as a promise to sign every valid Bitcoin transaction.

BIP-380 defines descriptor syntax, key expressions and checksums. Key origins, extended keys and paths accompany script structure. A checksum detects representation errors; it is neither encryption nor approval of the policy. Understand whether an export contains public or private material before sharing it.

BIP-382 supplies wpkh and wsh expressions for SegWit outputs. These expressions make the type of output explicit rather than leave a receiving application to guess from the key alone. When moving a wallet, the descriptor tells the new application how the key is used. This can improve precision over trying many historical paths, although support still depends on the application. A descriptor understood by one tool is not a guarantee that every signer understands each script permitted within that description.

BIP-386 defines tr descriptors for Taproot outputs with an internal key and an optional script tree. That can represent more than the single-key derivation convention in BIP-86. Its usefulness is preserving the structure a wallet needs to recognize and spend the intended output. Recording a script tree is important when alternative spending paths exist. A recovery exercise should reproduce the policy and expected address, rather than simply import a secret and hope a wallet infers every intended branch.

BIP-388, marked Complete in the source record checked for this edition, defines compact wallet policies built on descriptors. Its motivation includes limited device memory and the difficulty of presenting a large descriptor to a person approving a configuration. The policy separates the expression from key information, letting a signer identify an account's receive and change structure. A concise representation helps review; it does not make an unfamiliar threshold or backup arrangement correct. The user still needs to understand what has been registered on the device.

BIP-389 is Draft and describes multipath key expressions, allowing related receive and change paths to be represented together. A document remaining Draft does not tell the reader that no implementation uses it; it tells the reader to preserve the proposal's actual status. Compatibility research should distinguish the document from particular software support. When a tool exports a compact expression, verify that another tool can parse it and reproduce the relevant addresses before making that representation the only record of a wallet's structure.

Blockchain Commons' HDKey specification describes a structured representation for keys, derivation paths and coin information carried through its UR ecosystem. Its version 2 tags differ from the older crypto-hdkey representation, which the document marks deprecated. This is another interoperability layer used to move information between tools. It does not replace the underlying signing or derivation rules. A compatible transport needs both ends to agree on encoding and interpretation, particularly when displaying or importing information from QR-based workflows.

Draft BIP-329 defines a wallet label export format for records including addresses, transactions and outputs. Labels can preserve the reason funds were received and guide spending decisions, but a seed does not reconstruct those human annotations. Exporting metadata reduces dependence on a particular application while creating another privacy-sensitive artifact. A complete operational backup can therefore include information that is neither a secret signing key nor public blockchain data. Handling that information intentionally is part of keeping the wallet intelligible over time.

Bitcoin Core 23.0's historical release notes changed the default for newly created wallets to descriptors and included other wallet behavior changes. This is a dated implementation milestone, not advice to install that old release today. It illustrates why a wallet migration has to consider the version that created or exported the data. A specification can be available before a feature is default, and later releases can change what a user sees. Preserve version and export context alongside the underlying standards when documenting a recovery path.

Sparrow's FAQ demonstrates how an apparently empty recovery can mislead an owner. An incorrect BIP-39 passphrase produces a different seed and different addresses. Separately, a restored wallet may miss newer activity when its discovery gap limit is too small. These are different diagnoses with different remedies. A successful import screen alone cannot establish that an application reconstructed the intended wallet. Check the original format, expected addresses and discovery settings before interpreting an empty balance as proof that the coins disappeared.

Bitcoin Core's PSBT documentation describes roles including creator, updater, signer, combiner, finalizer and extractor. Separating these jobs lets independent tools cooperate, but each still has obligations. A signer should examine what it is authorizing; a finalizer should only finish a transaction whose spending conditions are satisfied. The workflow is a chain of information and decisions. It can improve separation of responsibilities without making the coordinator, communication channel or human review infallible. Trace those roles when investigating why a payment cannot be completed.

Bitcoin Core's descriptor documentation lists supported expressions and key formats, including limits and examples. It is implementation documentation, which is exactly what an interoperability check needs alongside a proposal. Read it to establish what a particular tool can parse, then compare another tool's actual capabilities. The best evidence is reproducing an expected public result under a controlled test. A standards label on a product page is a useful starting point; a demonstrated recovery and signing workflow is stronger evidence for the user's concrete setup.