Ledger Live Account Derivation Paths Explained: BIP44 Standards, Custom Paths, and Why Address Format Matters

A user recovers a Ledger hardware wallet on a new device, opens Ledger Wallet, and expects to see the same accounts and addresses that appeared on the original setup. Instead, the wallet shows different addresses. The private keys are correct—the recovery phrase is the same—but the accounts appear to have vanished. The problem is not lost funds or a compromised device. It is a mismatch in how the wallet is deriving addresses from the master seed, a process governed by a standard called BIP44 and its variations. Understanding derivation paths is essential for anyone managing cryptocurrency across multiple wallets, recovering accounts after device loss, or troubleshooting apparent missing balances.

Derivation paths are the mathematical instructions that convert a single recovery phrase into thousands of unique addresses. Every time a Ledger hardware device generates an address, it follows a specific path down a tree of possibilities. Change that path, and you change every address that appears in the wallet, even though the underlying private keys remain secured by the same recovery phrase. This distinction between the secret (the recovery phrase) and the route (the derivation path) is where most confusion arises. A user may possess the correct key but look in the wrong place for the money.

What derivation paths are and why they exist

A recovery phrase (also called a seed phrase or mnemonic) is a string of 12 or 24 words that can be converted into a master cryptographic key. From that single master key, an almost unlimited number of child keys can be generated in a structured way. Rather than storing thousands of separate secrets, a wallet stores one recovery phrase and uses mathematical rules to produce unique keys for each account, address, and blockchain. Those rules form the derivation path, a sequence of numbers separated by slashes that tell the wallet exactly which branch of the key tree to follow.

The standard path structure is expressed as: m / purpose / coin_type / account / change / index. The “m” represents the master key. Each subsequent number is a step down the tree, and each step narrows the possibilities. For Bitcoin, the BIP44 standard specifies that purpose is 44, coin_type is 0, account is 0 for the first account (1 for the second, and so on), change is 0 for receiving addresses and 1 for change addresses, and index is the specific address number within that branch. A complete path might look like: m / 44 / 0 / 0 / 0 / 0, which points to the first receiving address in the first Bitcoin account derived from a standard BIP44 wallet.

This hierarchy exists because cryptocurrency wallets need to be flexible. A single recovery phrase should work across multiple blockchains, multiple accounts on the same blockchain, and multiple addresses per account (for privacy and organizational reasons). Without a standard like BIP44, each wallet developer could invent their own path structure, making recovery and portability a nightmare. A user exporting a recovery phrase from one wallet would have no guarantee it could be imported into another and produce the same addresses. BIP44 solved this by creating an agreed-upon structure that most modern wallets follow, at least for the most common blockchains.

Ledger Wallet follows BIP44 for Bitcoin, Ethereum, and hundreds of other supported cryptocurrencies, but with important nuances. The coin_type value differs for each blockchain—Bitcoin is 0, Ethereum is 60, Litecoin is 2, and so on. When you add an account in Ledger Live, the application increments the account value and creates a new set of addresses. This allows a single recovery phrase to hold multiple accounts on the same blockchain without address collision.

How Ledger accounts and address generation work in practice

When a user sets up a Ledger hardware wallet with a recovery phrase and opens Ledger Wallet, the application does not immediately generate all possible addresses. Instead, it displays the first account and generates addresses on demand. Typically, the wallet will pre-generate addresses up to a “gap limit,” often 20 addresses, to ensure that if a transaction arrives before that address is shown on screen, the wallet can still detect it. Beyond that gap, the wallet stops scanning for activity and will only show new addresses if the user explicitly requests them.

This gap limit is crucial for understanding recovery. If funds were received at address number 25 in a long-unused account, and the recovery process only scans addresses 0 through 19, those funds will appear missing. They are not lost; they exist on the blockchain at a valid address derived from the recovery phrase. But they are invisible because the recovery process did not look far enough down the derivation path. This is why recovering a hardware wallet can sometimes require manually expanding the derivation range or manually scanning further down the path to find old addresses.

Ledger recovery phrases also need to match the device’s curve and format. A Ledger Nano S Plus or Ledger Nano X uses the same BIP39 standard that most wallets use, but importing a recovery phrase from an older or incompatible device type can fail. Similarly, account numbering matters. If the original setup created a Bitcoin account at index 0, then imported the recovery phrase into a wallet that treats it as account 1, the addresses will not match. The recovery phrase itself is correct, but the wallet is looking in the wrong branch of the key tree.

Ledger Wallet also supports “hidden wallets,” sometimes called passphrase-protected accounts, by appending a custom passphrase to the recovery phrase before derivation. This creates an entirely separate set of accounts from the same seed but with different paths. A user with a hidden wallet must remember both the recovery phrase and the passphrase to recover those accounts. If the passphrase is lost, the accounts are effectively locked even though the seed phrase is known.

BIP44 standardization and when paths diverge

BIP44 brought order to a chaotic landscape, but it did not eliminate all variation. Different wallets implement slightly different coin_type values for newer blockchains, and some older wallets predate the standard entirely. Bitcoin Core, for example, used its own derivation scheme before BIP44 became dominant. Ledger devices support multiple derivation schemes to maintain compatibility with legacy accounts, but users must be aware of which scheme they are using.

Ledger Wallet offers legacy derivation paths for backward compatibility. Bitcoin can be derived using the standard BIP44 path (m / 44 / 0 / 0 / 0 / 0) or older schemes such as BIP49 (segwit) or BIP84 (native segwit). Each produces different address formats: legacy addresses start with 1, segwit (P2SH-wrapped) addresses start with 3, and native segwit addresses start with bc1. A user who created a Bitcoin account in Ledger Wallet, received funds to a bc1 address, then later recovered the device and saw that account listed as a legacy path would notice that the same recovery phrase produces a 1 address instead. The funds at the bc1 address would still exist on the blockchain, but the wallet would not immediately show them because it was looking in a different derivation branch.

The reason for this divergence is that Ledger devices support multiple standards, and the software can choose which to apply. When recovering on a new device, Ledger Wallet generally tries to auto-detect the correct standard by checking for activity on different paths, but this automatic detection can fail if accounts are old or inactive. A user recovering an older device may need to manually select “Legacy,” “Segwit,” or “Native Segwit” paths to find the correct accounts.

Ethereum and most other blockchains use a simpler model. They typically have one standard coin_type value and one address format per blockchain. A Ledger Ethereum account will always produce addresses starting with 0x, and the derivation path follows BIP44 without significant variation. This makes Ethereum recovery more straightforward than Bitcoin recovery, but users should still understand that accounts are indexed separately, so account 0, account 1, and account 2 will each have distinct addresses even though they derive from the same recovery phrase.

Why changing paths creates new addresses and potential recovery issues

The most common recovery scenario involves a user who set up a Ledger hardware wallet, added some accounts, and sent cryptocurrency to those addresses. Months or years later, the device is lost or damaged. The user recovers the device with the original recovery phrase on a new Ledger device, opens Ledger Wallet, and expects to see the same accounts and balances. If the wallet was set up with standard BIP44 paths and the recovery process uses the same paths, the accounts and addresses will match, and funds will appear correctly.

However, if anything in the path derivation changes, the addresses will not match. Suppose the original setup used “Native Segwit” derivation for Bitcoin, but after recovery, Ledger Wallet defaults to “Legacy” derivation. The recovery phrase is correct, but the wallet is asking for addresses from a different branch. A user who received bitcoin at a bc1 address will not see that balance when the wallet shows 1 addresses instead. The blockchain still records those funds at the bc1 address; the wallet has simply stopped looking there.

Similarly, if the original setup created multiple accounts and a recovery process resets to account 0 only, any funds in account 1, account 2, or higher will be invisible until the user manually adds those accounts again. This is not a loss—the derivation path for account 1 is deterministic, so adding account 1 again will produce the same addresses—but it can feel like a loss because the funds do not appear automatically after recovery.

The recovery phrase itself cannot be lost or modified (assuming it is stored securely), and Ledger recovery phrases cannot be corrupted by the device or application. But the interpretation of that phrase depends on which derivation standard the wallet applies. Users who move between wallets, or who recover after a long gap, should verify the derivation path or address format before assuming funds are missing. A simple check is to see if a known address from the original setup appears in the recovered wallet. If it does, the derivation path is correct. If it does not, the user should try alternative paths or consult the original setup documentation.

Managing multiple Ledger accounts and blockchain compatibility

Ledger Wallet makes it easy to add multiple accounts within the same blockchain or accounts across different blockchains. Each account appears in a list, and the application tracks balances and transaction history for each. Behind the scenes, each account is assigned a unique derivation path, and each path produces a completely different set of addresses. This design enables strong account separation: a user can organize finances by purpose (savings, trading, staking) or by financial entity, and each account will have its own distinct addresses.

However, this flexibility introduces a responsibility. A user must remember which accounts were created and in what order. If an account is deleted from the wallet interface, the account itself is not destroyed on the blockchain—it still exists, defined by its derivation path—but the wallet stops tracking it. If the user later recreates the account at a different index number (such as account 0 becoming account 2), the new account will have different addresses, and any funds sent to the old account’s addresses will be invisible to the new account.

Ledger Wallet also supports custom derivation paths for advanced users. Instead of relying on the default BIP44 structure, a user can manually enter a custom path string such as m / 44 / 0 / 5 / 0 / 0. This is useful for recovering accounts created by software that does not follow standard BIP44, or for testing specific paths. But custom paths are a power-user feature and carry risk. If a custom path is entered incorrectly, the resulting addresses will not match any real account, and funds sent to those addresses will be inaccessible until the correct path is used.

For users managing Ledger crypto wallet accounts across multiple blockchains, it is important to understand that each blockchain has its own derivation structure. Bitcoin, Ethereum, Litecoin, and others each have their own coin_type values and sometimes their own address format rules. Ledger Wallet handles this automatically by selecting the correct path structure for each blockchain type, but if a user switches wallets (perhaps using Electrum for Bitcoin or MetaMask for Ethereum), they must ensure the new wallet uses compatible derivation paths. A recovery phrase that works with Ledger will also work with these other wallets, but only if the derivation path matches.

Testing recovery and maintaining a recovery strategy

The safest approach is to test the recovery process before it becomes necessary. After setting up a Ledger device and creating a recovery phrase, users should create a spare backup of that phrase and attempt a recovery on a test device using only the backup phrase, without the original device. This process validates that the recovery phrase is correct and that the user understands how recovery works. If the test recovery produces the same accounts and addresses as the original setup, the recovery phrase and backup are trustworthy.

Testing should also verify the derivation paths in use. A simple method is to export one or two addresses from the original device (in Ledger Wallet, the address is displayed on the device screen during account setup), then verify that the same addresses appear when recovered on a different device using the backup phrase. If they match, derivation is consistent. If they do not match, the user should investigate which path was used originally and ensure the recovery process uses the same path.

For users managing significant balances, a written record of account structure can be invaluable during recovery. This record should document: the number of accounts created on each blockchain, the index number of each account, the derivation path used (if non-standard), and perhaps a screenshot of the account list. This information does not need to be secret—derivation paths are not cryptographic secrets—but it should be stored safely and updated whenever accounts are added or deleted. During recovery, this record becomes a checklist for recreating the account structure on a new device.

One additional safeguard is to periodically check that Ledger Wallet can still detect addresses and balances correctly. A user who has not accessed a Ledger device for months should connect it once to verify that Ledger Wallet recognizes all accounts and that balances are correct. If any balances are missing or accounts are not recognized, that signals a potential path mismatch before actual recovery becomes necessary, allowing time to investigate and adjust settings.

Common recovery mistakes and how to avoid them

The most frequent recovery error is importing the recovery phrase into a wallet that uses a different derivation path than the original setup. A user might export the recovery phrase from a Ledger hardware wallet and import it into a software wallet or a wallet on a mobile phone without realizing that the software wallet uses a different coin_type value or a different path structure. The software wallet will accept the recovery phrase as valid (because the phrase itself is correct), but it will generate different addresses. If funds were sent to addresses generated by Ledger Wallet, they will not appear in the software wallet, creating the false impression that the recovery was unsuccessful.

Another common mistake is confusing account indices. Some wallets number accounts starting from 0, others from 1. If a user received funds in what they remember as the “first account” but that account is actually index 1 (not index 0), and during recovery they only add account 0, the funds will not be visible. The solution is to add multiple accounts in sequence during recovery, checking each one until the expected addresses and balances appear.

Ledger recovery phrases are also sometimes confused with PIN codes or passwords. The recovery phrase is a backup of the master private key and should be treated as such. If a recovery phrase is typed into a password manager, saved in a cloud service, or sent over email, it can be compromised. Additionally, some users assume that if they remember a recovery phrase, they do not need to write it down, but memory alone is fragile and can fail under stress (such as during a sudden device loss). A physical backup of the recovery phrase, stored offline in a secure location, is the standard practice.

Users switching between Ledger recovery phrase-based accounts and other wallet types should also be aware that recovery phrases from other wallets may not be compatible with Ledger hardware devices. For example, some older wallets or non-standard wallets use different BIP39 implementations or passphrase schemes. Before assuming a recovery phrase is valid, test it on a spare device or in a low-risk scenario to confirm that it produces the expected addresses.

When to use custom derivation paths and advanced recovery techniques

Custom derivation paths are generally not needed for routine wallet operations. Ledger Wallet’s default BIP44 implementation handles standard use cases well. However, custom paths become necessary when recovering funds from non-standard wallets or when troubleshooting complex recovery scenarios. A user who previously used a hardware wallet from another manufacturer, or who created accounts with custom software, may need to manually specify the derivation path to recover those accounts.

Some advanced recovery situations also require manual path specification. If a user suspects that accounts were created at unusual indices (such as account 10 instead of account 0), they can manually add accounts by path rather than relying on the automatic account detection. This is a power-user feature and requires understanding the path syntax, but it has recovered funds in cases where automatic recovery failed.

Ledger also provides a recovery check feature in the application settings that attempts to scan for activity across a range of standard paths and account indices. This feature can detect accounts that were not automatically added during recovery, helping to find “hidden” or inactive accounts. Running this feature during recovery, especially for older devices or devices that were inactive for a long time, can prevent the frustration of missing balances.

Users should approach custom paths and manual recovery with caution. A mistake in path syntax will produce valid-looking addresses that are not actually derived from the intended account. Funds sent to incorrect addresses are effectively lost, even though they exist on the blockchain. It is always safer to start with automatic recovery and only resort to custom paths if automatic recovery fails and the user has a specific reason to believe a custom path is needed.