A user downloads Trezor Suite, connects their hardware wallet, and navigates to the Bitcoin wallet section. They see an address displayed on screen. The next day, they open the Ethereum section and notice a completely different address structure. A week later, they restore the same device on a different computer, and suddenly the Bitcoin addresses have changed. This is not a malfunction. It is the result of hierarchical deterministic key derivation, a standard that allows a single seed phrase to generate thousands of addresses across different cryptocurrencies while keeping each derivation path mathematically distinct and reproducible. Understanding how these paths work is essential because an incorrect setting can make legitimate funds appear permanently lost, or cause a user to send assets to an address they cannot spend from.

Trezor Suite manages this complexity by implementing BIP44, a specification that defines how a hardware wallet should organize keys for different coins, accounts, and change addresses. The software presents a simplified interface—a list of accounts, a receive button, a transaction screen—but behind that interface is a precise mathematical hierarchy. A Bitcoin wallet and an Ethereum wallet are not separate entities stored on the device. They are different branches of the same deterministic tree, generated from the same seed using different derivation parameters. The critical consequence is that changing a single parameter in the path can send you down an entirely different branch, where none of your previous addresses exist.

How BIP44 organizes keys into a predictable tree

BIP44 is a standard that emerged from the Bitcoin Improvement Proposal process, designed to solve a practical problem: if a single seed phrase can generate unlimited addresses, how should different cryptocurrencies and accounts be organized so that recovery is deterministic and unambiguous? The standard defines a path structure written in notation such as m/44'/0'/0'/0/0, where each number represents a level in the hierarchy. The "m" represents the master seed. The first 44 is the BIP44 version identifier. The next number (coin type) determines whether this path leads to Bitcoin, Ethereum, Litecoin, or another asset. The apostrophe (hardened derivation) means that compromising a public key at that level does not compromise keys further up the tree.

Below the coin type comes the account layer. A user can create multiple accounts within Bitcoin using paths like m/44'/0'/0'/0/0 for the first account and m/44'/0'/1'/0/0 for the second account. This allows one seed phrase to control entirely separate wallets for Bitcoin that never mix addresses. The account structure is useful for organization—one account for savings, another for trading, another for receiving from specific sources—but each account is mathematically independent. Spending from account zero does not automatically give access to account one.

The final two numbers in the path represent the change flag and address index. The change flag is either 0 (for receiving addresses) or 1 (for change addresses, which are destinations for leftover funds after a transaction). The address index increments: 0, 1, 2, 3, and so on. So m/44'/0'/0'/0/5 means Bitcoin, first account, receiving address, the sixth address generated in sequence. This structure allows a wallet to restore itself from a seed phrase and reproduce every address in exact order, without storing address data on the device itself.

The elegance of BIP44 is that it is both deterministic and hierarchical. Any application that knows the seed can regenerate any address at any path. Different applications—Trezor Suite, a mobile wallet, a hardware wallet, a recovery tool—will produce the same address at the same path if they implement the standard correctly. This is why a recovery is possible: the seed contains all the information needed to find funds, and the path structure tells the application where to look.

Why Bitcoin and Ethereum require different coin-type values

Bitcoin uses coin type 0 in the BIP44 path, written as m/44'/0'/account'/change/index. Ethereum uses coin type 60, giving a path like m/44'/60'/account'/change/index. This difference exists because the Bitcoin Improvement Proposal process assigned a unique coin type to each cryptocurrency to prevent accidental address collision. If both Bitcoin and Ethereum used coin type 0, the same seed phrase would generate mathematically identical keys for both networks. Because the coins have different address formats and signature algorithms, this would be disastrous: a user could send Bitcoin to what they thought was an Ethereum address and lose the funds permanently, or vice versa.

The consequence is that a Bitcoin receiving address generated by Trezor Suite will never work for Ethereum transactions, and an Ethereum address will never work for Bitcoin. This is by design. When a user switches between the Bitcoin wallet and Ethereum wallet sections in Trezor Suite, they are not moving between storage locations on the device. They are telling the software to follow a different path down the derivation tree. The hardware wallet generates entirely different key pairs for each coin type, and the addresses reflect that difference in their format and encoding.

A third important example is Bitcoin Cash, which uses coin type 145. Some recovery tools and old wallets did not implement the coin-type distinction correctly, generating Bitcoin and Bitcoin Cash addresses from the same path. This created a subtle trap: a user could inadvertently send Bitcoin Cash to a Bitcoin address, or vice versa, because the addresses appeared valid to both networks even though they represented different keys. Modern wallets, including Trezor Suite, enforce strict coin-type separation to prevent this mistake.

The practical implication is that changing a wallet's coin type setting—if such an option were exposed—would point the software at an entirely different set of keys. This is why cryptocurrency management with a hardware wallet requires understanding the path structure. A user must not assume that every address generated by their seed is recoverable from every wallet software. The software must follow the same standard, starting from the same seed, using the same path, to reproduce the correct address.

Account and change address layers: practical separation in one seed

After coin type, the next level in the hierarchy is the account number. Trezor Suite allows users to create multiple accounts within the same Bitcoin wallet, or multiple accounts within the same Ethereum wallet. Each account follows a different path: m/44'/0'/0'/0/0 for account 0, m/44'/0'/1'/0/0 for account 1, and so forth. From a security perspective, these are functionally independent wallets. A user could lose the private key for account 0 and still retain access to account 1, because they are derived separately. From a privacy perspective, account separation can help prevent linking transactions together, since addresses from different accounts appear to come from different wallets to an external observer.

The change address layer deserves particular attention because it affects how users actually interact with receiving addresses. When a user receives a payment, they share a receiving address (change flag = 0). When they send a payment, Trezor Suite typically generates one or more change addresses (change flag = 1) to receive unspent outputs. A Bitcoin transaction with one input and two outputs—one to the recipient and one change address back to the sender—is the standard pattern. If a user incorrectly assumes that all addresses in their wallet are receiving addresses, they might become confused when they see addresses in their transaction history that they never explicitly requested.

In practice, Trezor Suite handles this distinction invisibly. The software knows which addresses are receiving addresses and which are change addresses; it displays receiving addresses when the user clicks "receive," and it automatically generates change addresses during spending. But if a user imports their seed into a different wallet application that does not properly support BIP44, or if they manually try to reconstruct their wallet using an incorrect implementation, they might accidentally skip the change addresses or generate them in the wrong order. This can make it appear that funds have been lost, when in fact they exist at a change address the user does not realize belongs to them.

The address index (the final number in the path) increments as the wallet generates new addresses. Most receiving addresses follow paths like m/44'/0'/0'/0/0, m/44'/0'/0'/0/1, m/44'/0'/0'/0/2, and so forth. This sequential generation is why hardware wallets can reconstruct the entire address history from a single seed without storing any address list on the device. The device generates them in order, one at a time, on demand.

Why incorrect path settings can make funds appear lost

The most common scenario where path confusion creates apparent loss is wallet recovery. A user backs up their seed phrase from a Trezor device, then uses it to restore into a different wallet application. If that application does not follow BIP44, or uses a different coin-type assignment, or defaults to a different account number, the addresses generated will not match. The user will see an empty wallet even though the funds exist on the blockchain at an address derived from the original seed, just not at a path the new software recognizes.

This is not permanent loss in a technical sense. The funds exist on the blockchain. But they are inaccessible until the user finds the correct path and the software that can follow it. A user who takes their Trezor device and tries to restore it in a legacy wallet designed for an old BIP derivation standard might end up unable to access the keys. The solution is to identify the correct derivation path and either find a wallet that supports it or manually provide the path to the wallet software if it offers advanced options.

Another scenario involves address format choices. Bitcoin has multiple address formats: legacy (P2PKH, beginning with 1), SegWit (P2WPKH, beginning with 3), and native SegWit (P2WPKH, beginning with bc1). These are not different coins or different paths in the strict sense; they are different encodings of keys from the same derivation path. But some wallet software supports only one format, and some defaults have changed over time. A user might restore their seed and see different addresses than they originally used, even though both sets are valid because they just use different encoding schemes for the same underlying keys.

Trezor Suite handles this complexity by supporting multiple address formats and allowing users to switch between them. But when a user imports their seed into a different application, that application might not recognize the format choice, and the user might end up at the wrong address set. The critical lesson is that the seed phrase is necessary but not sufficient for recovery. The recovery process requires knowing the correct coin type, account number, address format, and derivation standard that the original wallet used.

A third trap emerges when users manually export keys or attempt to use their seed with a web-based wallet. A web application, even if it is honest and well-intentioned, could potentially derive and display incorrect addresses if it implements the standard incorrectly. Entering a seed phrase into a web form also exposes it to potential compromise through JavaScript vulnerabilities, network interception, or browser history. Trezor Suite is designed to reduce this risk by keeping the seed on the hardware device and never exposing it to the computer beyond the initial setup.

How Trezor Suite implements path selection for different cryptocurrencies

When a user opens Trezor Suite and connects their hardware wallet, the software immediately follows a predetermined set of coin-type paths. For Bitcoin, it follows m/44'/0'/account'/change/index. For Ethereum, it follows m/44'/60'/account'/change/index. The user does not manually enter these paths; Trezor Suite infers them from the cryptocurrency selected in the interface. The Bitcoin wallet icon automatically means coin type 0. The Ethereum wallet icon automatically means coin type 60.

The advantage of this design is simplicity. A non-technical user can open Trezor Suite, click "Bitcoin," and start receiving addresses without understanding BIP44 or coin-type assignments. The software handles the path logic. The disadvantage is that a user who needs to recover their wallet in a different application cannot easily control the path settings unless that application also exposes them. Most modern wallet software follows the same standard paths, so interoperability is generally smooth. But edge cases exist, and users with legacy wallets or recovery scenarios should be aware that path mismatches can occur.

Trezor Suite also allows users to create multiple accounts within a single cryptocurrency. The Bitcoin account dropdown shows "Account 1," "Account 2," and so forth. Each account is a separate derivation path, and they are completely independent. A user could receive payments to account 1, export the public key, share it with a service, and know that account 2 is completely private. This account separation is rarely used by casual users but is powerful for advanced privacy and organizational workflows.

The software also abstracts away the change address layer entirely. A user does not need to understand that change addresses exist or how they are generated. Trezor Suite shows the user a "Receive" button that displays a fresh receiving address, and a "Send" feature that handles change address generation automatically. This hiding of complexity is appropriate for most users, but it also means that a user who wants to manually verify their address derivation path needs to understand the underlying structure that Trezor Suite is managing invisibly.

Verifying addresses and preventing misdirected transactions

Trezor Suite displays each receiving address on the hardware device's screen for manual verification before a payment is received. This is a critical security feature because it prevents a compromise of the computer from causing funds to be sent to a wrong address. If an attacker gains control of the desktop application and attempts to show a fake receiving address, the user can still verify the correct address on the physical device display, which is isolated from the computer.

The address shown on the device screen is derived using the same path logic as the software. If the device and software disagree about the path, the address shown on screen will not match the address shown in the software, and the user will immediately detect the inconsistency. This is not a common occurrence with a genuine Trezor device and unmodified Trezor Suite, but it is a potential failure mode if the device has been compromised or the software has been altered.

When receiving a Bitcoin wallet or Ethereum payment, the user should always verify that the address shown in Trezor Suite matches the address displayed on the device. This prevents sending funds to an address controlled by an attacker, or to an incorrect path that might not be recoverable. A payment sent to the wrong address is irreversible on public blockchains, so address verification is one of the most important operational checks a user can perform.

The Ethereum wallet implementation in Trezor Suite includes the same address verification flow. An Ethereum address is a 42-character string beginning with 0x, derived from the public key and chain parameters. Because Ethereum addresses are shorter than Bitcoin addresses and do not include a checksum, a single character error is less likely to be caught automatically. This makes manual verification on the device display even more important. A user should read the address character by character if possible, or use a second device to verify the payment details before confirming.

Path recovery and restoring access to legacy addresses

If a user restores their seed phrase from a Trezor device into a different wallet application, or if they need to recover funds from an old wallet they created years ago, understanding derivation paths becomes essential. The recovery process requires identifying which path was used to generate the original addresses. This might require trial and error: trying coin type 0, then coin type 145, then a custom path, until an address appears that matches the one on the blockchain.

Some wallet applications, particularly older or less common ones, used non-standard paths. A Bitcoin wallet created in 2012 might have used m/0/1 instead of m/44'/0'/0'/0/1. A recovery tool that assumes all wallets use BIP44 will not find these addresses. The solution is either to locate the original wallet software and use it, or to find a recovery tool that supports legacy paths. Users can download and verify Trezor Suite from the official Trezor Suite site, which supports modern standards and the most common legacy paths.

Another recovery scenario involves partial information. If a user has written down only the first few addresses from an old wallet, they can use those addresses as reference points to determine the derivation path. By searching for those addresses on the blockchain and noting their positions, a user can infer the path structure and then use appropriate recovery software. This process is tedious but can be successful if the user has recorded addresses and understands the search method.

The most robust recovery strategy is to test the recovery process before it becomes necessary. When a user first sets up a Trezor device, they should export the seed phrase, restore it into a second device or application in a controlled environment, and verify that the same addresses are generated. This confirms that the recovery process works and provides confidence that a loss of the original device would not result in inaccessible funds. This test should be done carefully, using a computer that is not connected to large amounts of cryptocurrency.

Advanced path settings and when to use them

Trezor Suite exposes account selection in the user interface, but it does not expose full path customization. Advanced users who need to use non-standard paths can do so by accessing alternative wallet software that supports custom derivation paths, or by using a command-line tool. This is rarely necessary for standard Bitcoin and Ethereum use, but it becomes relevant for users who are recovering funds from legacy wallets, managing multiple derivation standards, or using advanced privacy schemes.

Some privacy-focused workflows involve using different derivation paths for different purposes. A user might use path m/44'/0'/0'/0 for public-facing transactions, m/44'/0'/1'/0 for personal transactions, and a completely custom path for sensitive payments. Because these paths generate different addresses and keys, they appear to be entirely separate wallets to an external observer. This separation is useful for limiting the amount of history visible if one set of keys is ever compromised.

The trade-off with custom paths is that recovery becomes more difficult. A user who uses a non-standard path and loses the original application that generated it will have trouble recovering funds unless they have carefully documented the path and can find compatible recovery software. For most users, the standard paths used by Trezor Suite are the right choice because they are widely supported and will be recoverable for decades.

Users interested in exploring custom paths should ensure they understand the implications and have tested their recovery process. A seed phrase is only as valuable as the ability to use it, and a path that is too exotic or poorly documented can render a seed phrase inaccessible when recovery is needed most.