Trezor hidden wallet: confirmed BTC on-chain, passphrase not reproducing

[jwsutherland]

Bitcoin Client Software and Version Number:
Trezor Model T using Trezor Suite (desktop, current version).
Also verified independently using Sparrow Wallet in watch-only mode.

Operating System:
N/A (not a client software bug).

System Hardware Specs:
N/A.

Description of Problem:
I transferred BTC from Newton (Canadian exchange) to a self-custodied address generated by my Trezor Model T.

The BTC exists, is fully confirmed on-chain, and has never moved since the original transaction. However, I cannot currently access the wallet that derived this address.

This strongly indicates that the address was created under a BIP-39 passphrase-protected (hidden) wallet and that I am currently entering an incorrect passphrase.

Important clarifications:

There has only ever been one Trezor device.

The 12-word recovery seed is correct and verified.

Entering an incorrect passphrase opens a valid but unrelated empty wallet (expected behavior).

This is not a transaction failure, theft, or exchange issue.

Any Related Addresses:
bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

Any Related Transaction IDs:
(Available if needed — omitted here for brevity, but the address above shows the confirmed balance on mempool.space.)

Screenshot of the Problem:
Not applicable — no client error message; behavior is expected for an incorrect passphrase.

Log Files from the Bitcoin Client:
Not applicable.

What I am asking:
I understand that a forgotten passphrase cannot be “recovered” in the general case. I am looking for expert confirmation on the following points:

Whether there are any remaining derivation-path edge cases (e.g., legacy vs native SegWit) worth ruling out given this setup.

Whether offline passphrase reconstruction (bounded candidate testing using the known seed and funded address) is the only remaining technically sound approach.

Confirmation that no other wallet-level explanation exists beyond an unreproduced passphrase.

I am not asking for hacks, shortcuts, or guarantees — only technical validation and guidance on whether anything remains to be checked.

Thank you for your time and expertise.

[FinneysTrueVision]

Any Related Addresses:
bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

Any Related Transaction IDs:
(Available if needed — omitted here for brevity, but the address above shows the confirmed balance on mempool.space.)

That is not a valid Bitcoin address.



Trezor Suite does not let you load any more accounts if there is already one empty Bitcoin account in the application. If you have already checked different account indexes on Sparrow, then it is most likely that you have the incorrect passphrase for the wallet and will have to use recovery software to brute force it to regain access.

[jwsutherland]

Thanks for pointing this out — you’re absolutely right.

This was a transcription error on my part.

The correct address is:

bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv


The missing q after bc1 in my earlier post made the address invalid when copied.

This is a native SegWit (bech32) address, and the balance and confirmations can be verified on mempool.space and other explorers.

Apologies for the confusion, and thank you for catching that.

The underlying question remains the same: the address exists on-chain with confirmed BTC, but is not derived by the currently opened wallet, strongly indicating a passphrase-protected (hidden) wallet.

I appreciate any guidance on remaining derivation-path edge cases worth ruling out beyond passphrase reconstruction.

[philipma1957]

Thanks for pointing this out — you’re absolutely right.

This was a transcription error on my part.

The correct address is:

bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv


The missing q after bc1 in my earlier post made the address invalid when copied.

This is a native SegWit (bech32) address, and the balance and confirmations can be verified on mempool.space and other explorers.

Apologies for the confusion, and thank you for catching that.

The underlying question remains the same: the address exists on-chain with confirmed BTC, but is not derived by the currently opened wallet, strongly indicating a passphrase-protected (hidden) wallet.

I appreciate any guidance on remaining derivation-path edge cases worth ruling out beyond passphrase reconstruction.

Post a blockchain link to the address.

That address does not show for me.

I did three chains all  show zip.

[jwsutherland]

👉 https://blockchair.com/bitcoin/address/bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

[nc50lc]

What I am asking:
I understand that a forgotten passphrase cannot be “recovered” in the general case. I am looking for expert confirmation on the following points:
-snip-
Confirmation that no other wallet-level explanation exists beyond an unreproduced passphrase.

Since you've used Sparrow, it's possible to select p2wpkh in the script type when creating the Sparrow wallet, then edit a different derivation path when connecting Trezor.
So, there's a chance that you might have mismatched the standard derivation path of a certain script type with another.
Even non-standard derivation path might have been used.

If the issue isn't the passphrase, it's worth trying to reproduce it by mismatching the script type and derivation path when restoring the hidden wallet.
Since the address is bc1q..., select "Native SegWit (p2wpkh)" in the script type then change the derivation path in "Show derivation..." to BIP44, 49 or 86 before clicking "import Keystore".
Then each derivation path's second, third or higher account_index in case the first isn't used.

[LoyceV]

👉 https://blockchair.com/bitcoin/address/bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

So you have an empty address and no way to reproduce it. That makes this whole topic pointless. See post below.

For next time: before funding any address, make sure you can reproduce it from scratch by verifying your backup. Also make sure you use the correct address and don't fall for clipboard malware.

[FinneysTrueVision]

So you have an empty address and no way to reproduce it. That makes this whole topic pointless.

They probably meant this address bc1qqn5raset2n9m0npn50xnyadmlvdgctgdtum3mv with 0.7 BTC in it. I don’t blame them for seeking advice, but they should have provided accurate information.

[jwsutherland]

Thanks for the feedback.

To avoid further confusion: this address does exist and does contain ~0.7175 BTC, which can be verified here:
https://blockchair.com/bitcoin/address/bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

Some explorers (including mempool.space and blockstream.info) incorrectly reject this address, which is what caused the earlier verification issues.

The underlying issue remains unchanged: the funds are confirmed on-chain but are not derived by the currently opened wallet, consistent with either a passphrase (hidden wallet) or derivation-path mismatch.

I appreciate the guidance so far.

[satscraper]

The underlying issue remains unchanged: the funds are confirmed on-chain but are not derived by the currently opened wallet, consistent with either a passphrase (hidden wallet) or derivation-path mismatch.

I appreciate the guidance so far.

Before diving into passphrase‑related despair, I would first try scanning addresses a bit deeper ^{that is, beyond the default gap limit of 20 addresses in Sparrow}.

Open your wallet ==>Settings==>Gap limit==>set it as high as needed==>Watch addresses==> choose All.

Then rescan from the date your transaction was sent

[LoyceV]

To avoid further confusion: this address does exist and does contain ~0.7175 BTC, which can be verified here:
https://blockchair.com/bitcoin/address/bc1qgn5raset2n9m0npn50xnyadmlvdgctgdtum3mv

You have (literally!) posted the wrong address in all your 4 posts so far. FinneysTrueVision posted an address that looks like it, but is funded. If you would have checked your own link, you would know this. If this is how you handled your passphrase, it's no surprise you can't find back your funds. It sounds like you need to try some variations on your password, or even brute-force it (but not before setting up a secure offline system to run this).