Research . Hardware forensics

Trezor derivation-path forensics

A restored Trezor that shows the wrong balance — or none — usually hasn’t lost anything. It’s deriving the wrong addresses. The coins are on-chain; the path is off.

Cập nhật tháng 7 năm 2026 · KeychainX — Dịch vụ khôi phục ví từ năm 2017

Hardware wallets derive many addresses from one seed using a derivation path. Over the years Trezor firmware and the wider standards shifted which paths a wallet used, and those divergences are a frequent, misunderstood cause of “my funds are gone” reports. This page documents the forensics of Trezor derivation and how recovery resolves it.

What a derivation path is

A single seed can generate effectively unlimited addresses, organised by a derivation path such as m/44’/0’/0’. The path encodes which coin, which account and which address index. Restore a seed under the wrong path and you derive a different, valid-but-empty wallet — the seed is correct, the money is real, but the software is looking in the wrong branch of the tree. That single fact explains most “restored but empty” hardware-wallet cases.

The standards that diverged

Bitcoin address types each got their own path standard: legacy BIP44 (m/44’, addresses starting 1…), SegWit-compatibility BIP49 (m/49’, 3…), native SegWit BIP84 (m/84’, bc1q…) and Taproot BIP86 (m/86’, bc1p…). As Trezor firmware adopted each over time, a wallet funded under one standard can be restored by other software defaulting to another — and show nothing. The funds sit at the addresses of the original path.

Firmware and account-index history

Beyond address types, older Trezor firmware and early third-party tools sometimes used non-standard or shifted paths and account indices, and some wallets used a specific ETH derivation path from a particular period that later software stopped defaulting to. Multiple accounts add another axis: funds at account index 1 or 2 are invisible if only account 0 is scanned. Reconstructing the history means knowing which firmware and tools were plausible at the wallet’s creation date and what each derived.

Passphrase (hidden) wallets

The passphrase, or “25th word”, adds a further layer: each passphrase produces an entirely separate hidden wallet from the same seed. A forgotten or mistyped passphrase, or connecting the Trezor to a different interface, presents a different derived wallet that looks empty — while the funds sit safely in the hidden wallet keyed by the correct passphrase. This is distinct from a lost PIN, and it’s a search problem rather than a dead end.

How a path sweep recovers it

Recovery is a systematic sweep: from the correct seed, derive across every plausible path standard, account index and (where relevant) passphrase, checking each derived set of addresses against the known funded address or the chain. When a derived address matches, the correct path is confirmed and the funds become spendable. The seed was right the whole time; the work is finding the branch the coins actually live on.

Why this is so often mistaken for lost funds

The reason path mismatches cause such panic is that everything looks catastrophic: you enter your correct seed, the wallet opens, and the balance reads zero. It is natural to conclude the coins were stolen or the seed is wrong. But a zero balance under a valid seed almost always means the software derived a different branch of the address tree than the one your funds live on — a different address type, account index, or (with a passphrase) a different hidden wallet entirely. The blockchain still shows your coins at their real addresses; only your current view of them is wrong. Understanding this prevents the worst mistake, which is assuming the loss is real and giving up.

Recording your path and passphrase

The way to avoid ever facing this is to record more than the seed. Note which address type your wallet used (legacy, SegWit, native SegWit, Taproot), which account index holds your funds, and — critically — your exact passphrase if you use a hidden wallet, since a passphrase is never stored anywhere and cannot be recovered from the device. A seed alone will restore a wallet; the path and passphrase details ensure it restores your wallet on the first try, on any software.

How the sweep is run in practice

The sweep is mechanical once the seed is known. From the seed we generate the account extended keys for each path standard, derive the first stretch of receiving and change addresses under each, and check them against the chain — either against a specific address the owner remembers, or by scanning for any address in the derived set that has ever held a balance. Adding passphrase candidates multiplies the space but the logic is identical: derive, check, confirm. Because the confirmation is against real on-chain history, there is no ambiguity when the right combination lands — the funded addresses appear, and the correct path, account and passphrase are established together.

Our documentation

KeychainX maintains a sweep harness covering the historical Trezor firmware paths, address-type standards, account indices and passphrase combinations, built from years of casework where a “restored but empty” wallet turned out to be a path mismatch. We publish this so owners don’t abandon a wallet that is, in fact, fully intact. For hardware cases see our Trezor recovery page.

Các câu hỏi thường gặp