Wallet Derivation Paths: Why One Seed Shows Different Addresses

The seed is the root, the path is the branch

A seed phrase does not contain addresses. It contains the entropy from which a root key is produced, and every address a wallet shows is derived from that root by following a path. Two wallets given the same seed and asked for the same script type will produce the same sequence of addresses. Two wallets given the same seed and pointed at different purposes will produce different ones.

BIP32 introduced the notation. A path is written as a sequence of indexes separated by slashes, starting from m for the master key, and BIP32 gives the example m/3H/2/5 as shorthand for three nested derivations. The H marks a hardened index. In most wallets the same idea is written with an apostrophe, so m/84'/0'/0' and m/84H/0H/0H describe the same node.

The five levels BIP44 defines

BIP44 takes that notation and assigns meaning to five levels:

m / purpose' / coin_type' / account' / change / address_index

The allocation of work across the levels is deliberate. The first three levels are hardened, which means public derivation cannot cross them; the last two are not, which is what lets an account-level extended public key generate receiving and change addresses without any private key. That is the same property a watch-only wallet depends on.

BIP44’s examples for Bitcoin make the structure concrete: the first external address is m / 44' / 0' / 0' / 0 / 0 and the second is m / 44' / 0' / 0' / 0 / 1. Coin type 0 is Bitcoin in the specification’s registered list, which is why the second level is 0' throughout the Bitcoin examples.

Why 84’ produces a different address

BIP84 reuses BIP44’s account structure and changes one level. It defines the derivation scheme for P2WPKH — native segwit — addresses, and states that it uses the same account structure as BIP44 and BIP49 but with a different purpose value to indicate the different transaction serialization method.

The purpose value it uses is 84’. Everything else follows BIP44’s definitions. In BIP84’s own words:

// Account 0, first receiving address = m/84’/0’/0’/0/0

Because the purpose level is the first child index after the master key, changing 44’ to 84’ selects an entirely different subtree. Every subsequent derivation happens from a different node, so every resulting address is different. The seed has not changed; the branch has.

This is the answer to the common confusion. A wallet that shows a different first address after a restore is not necessarily deriving from a different seed. It may be deriving from a different purpose, because it defaults to a different script type.

The test vector, checked line by line

BIP84 publishes test vectors, which is the cleanest way to see the relationship between a path and an address. Using the mnemonic abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about, the specification lists:

Three details are visible in the table. The addresses start with bc1q, which is the segwit v0 bech32 form BIP84 targets. The external chain (the 0 before the last index) produces the receiving addresses. The internal chain (the 1) produces the first change address, and it is a different address from either receiving address even at the same final index.

The test vectors also serialize the account-level keys with zprv and zpub prefixes, which is a detail worth noticing when comparing exports: the same underlying key material can appear under different textual prefixes depending on the script type a tool expects.

Why restoration sometimes finds nothing

BIP84 is direct about the failure mode. It states that the specification is not backwards compatible by design: an incompatible wallet will not discover accounts at all, and the user will notice that something is wrong.

“Something is wrong” usually looks like a zero balance after a restore. A wallet that supports only the older purpose will not scan the 84' subtree, so it will not see the addresses the other wallet was using. The seed is correct; the search was in the wrong place. Some wallets offer to scan several purposes or script types for exactly this reason, and the resulting list of candidate first addresses is a list of branches, not a list of seeds.

Reading a path

A path is readable if you take it one level at a time:

Two practical rules follow. First, a restore needs the right path as well as the right words; a backup that records the seed but not the script type is an incomplete backup. Second, when a wallet offers to import an extended key, the derivation path is the field that decides which addresses appear, which is why a wrong path shows an empty account rather than an error.

The path is part of the backup

The seed phrase is the part of a wallet backup that cannot be reconstructed. The path is the part that can, if it is written down; without it, the restore becomes a search across purposes and script types until the right branch is found. Recording both — the words and the path, or at least the script type — turns a restore from an investigation into a procedure.

Risk note. The path structures, hardened levels and test vectors in this article were read from BIP32, BIP44 and BIP84 on 2026-10-26. Wallet software may add levels or default to a different purpose. Nothing here is investment advice.