Why one seed can yield different addresses
A seed phrase records a master key, not the wallet’s intent. The derivation path and the output script that turn that key into addresses live in the wallet software, and neither is written into the backup. When the same words reopen to a different set of addresses, the usual cause is that the new wallet assumed a different standard than the one the coins were actually received under.
Three standards, three output scripts
Three Bitcoin Improvement Proposals define the mainstream single-key schemes, and each binds a purpose number to a different output construction. BIP49 derives P2WPKH nested inside P2SH at m/49’/0’/0’/0/0, the format that gave older wallets SegWit addresses behind a script-hash wrapper. BIP84 derives native P2WPKH at m/84’/0’/0’/0/0. BIP86 derives single-key Taproot at m/86’/0’/0’/0/0. The purpose number is the load-bearing difference: it selects which child key is produced and what script receives the payment.
What a prefix change actually does
The export labels form a second, separate layer. Each standard assigns different version bytes to the extended public key, which is why a BIP49 account exports as ypub and a BIP84 account as zpub. Those prefixes are only a serialization header. Re-encoding a key from m/49’/0’/0′ with zpub bytes changes how the string is written; it does not re-derive the account at m/84’/0’/0′, and it cannot move coins already sent to the original script.
The output scripts make the gap concrete. BIP49 locks funds to a hash of the inner key-hash program behind a P2SH wrapper. BIP84 locks directly to a version-0 key-hash program. BIP86 locks to a Taproot output key, which is the internal key adjusted by a specified tweak rather than the internal key placed into an output unchanged. These are different conditions attached to a blockchain output, not different labels for the same one.
Moving value from one script type to another is a real transaction, not a formatting repair. A prefix converter can only rewrite the export label; spending coins out of a BIP49 output and into a BIP84 or BIP86 output requires building and broadcasting a transaction that signs the original script. Confusing the two is how a label edit is mistaken for a migration.
Why an empty wallet is not proof
Two traps follow from that. First, an empty wallet after a restore does not prove the backup controls nothing: if the software does not implement the account’s standard, it simply does not discover the account. BIP49 chose dedicated accounts specifically so this shows up as a missing account instead of a partial one. Second, a wallet that accepts a converted prefix has accepted the serialization, not proven that the reconstructed addresses match the ones that actually received funds.
A recovery order that avoids the trap
When addresses disagree, work in a fixed order. Record the intended network, account standard, full path, branch and index; confirm the candidate wallet documents that exact construction; then compare a previously known receiving address at the same branch and index. Treat a match as reproducibility of one address, not as proof a signer can spend. Never type seed words or extended private keys into a converter; keep secret material inside the trusted signer’s documented recovery flow.
Adapted from Same Bitcoin Backup, Different Addresses: Why Prefix Conversion Is Not Migration.