Seed checksum vs wallet verification

A valid phrase is not proof of your wallet

BIP39 includes checksum bits derived from the mnemonic’s entropy. Those bits reject many invalid word combinations, but do not identify the wallet owner or establish that a phrase is yours. A valid phrase can still derive a completely different wallet. The BIP39 specification defines both the mnemonic checksum and the separate seed derivation.

What the checksum can filter

A standard 12-word BIP39 mnemonic encodes 128 entropy bits plus 4 checksum bits. A 24-word mnemonic encodes 256 entropy bits plus 8 checksum bits. Across uniformly sampled full word sequences, the respective valid fractions are 1/16 and 1/256. Those fractions do not automatically describe every constrained missing-word or permutation search: the constraints may change the distribution.

These are properties of BIP39, not timing estimates or recovered-wallet statistics. Other seed schemes can follow different rules. In particular, do not assume an Electrum seed is BIP39 simply because both are displayed as words.

The passphrase changes the derived seed

BIP39 derives a seed from the mnemonic and an optional passphrase; an empty passphrase is also an input. A mistyped passphrase does not provide an “incorrect password” signal at this step. It produces different seed material. The intended result must be checked using wallet evidence. See our passphrase guide and the upstream wallet-specific examples.

Then the derivation path matters

A deterministic wallet derives many keys from its root. An address check depends on the coin, account, address branch and index, as well as the script/address convention used by the wallet. A correct mnemonic with the wrong derivation settings can fail to match the address you supplied. The BTCRecover accounts and altcoins guide explains supported path choices.

Use an address you know came from the intended wallet, ideally early in its history. Record its source and which account used it. A limit that checks too few derived addresses can miss it; increasing a limit blindly also increases work. Establish the likely address history before expanding.

A useful verification record

• Original wallet application and approximate creation period.
• Seed scheme and wordlist language, established from that application.
• Whether an additional passphrase was used.
• Known address and the account or history it came from.
• Derivation settings and address range actually searched.

Keep this record privately. A checksum-only result belongs at the “candidate” stage, not the “recovered wallet” stage.