Wallet Restore Height and Gap Limit: Why Balance Shows Zero

A zero balance is usually a scan setting, not a lost key. On 7 November 2026, Monero's chain was at block 3,801,119. A wallet restored from a legacy 25-word seed with the restore-height field left blank starts reading from block 0: 3.8 million blocks, a 295,279,001,600-byte (275 GiB) chain database, and roughly 14.5 years of history, just to find a payout that may have arrived last week. The keys are correct the entire time; the wallet simply does not know where to look. A restore is not one action but two settings — the height or birthday where scanning starts, and the address gap limit that tells the wallet when to stop deriving addresses. Get either wrong and the balance reads zero while the money sits on-chain.

What a restore height is — and is not. It is a block number, not a secret and not part of the seed. The same words derive the same keys and addresses in any compatible wallet; the height only chooses which blocks to read. Monero's own restore guide states both failure directions plainly: set it above the block containing your first incoming transaction and the wallet will not detect all transactions, so the balance is wrong; set it below and the wallet scans unnecessary blocks, so the first sync takes longer. The first mistake is silent; the second is merely slow. That asymmetry gives the rule: when unsure, choose lower, never higher.

Monero: the 25-word seed has no birthday; the 16-word Polyseed does. In wallet2.cpp, an embedded birthday is used only for a Polyseed; for a legacy seed the scan begins at the height you supply, or at 0 if the field is blank. The CLI and GUI both accept a date in YYYY-MM-DD and convert it to a height, which is easier than hunting for a block number. At the time of writing the chain is 3,801,119 blocks high with a 120-second target: 720 blocks a day, 262,800 a year. A wallet whose first XMR arrived two years ago is looking through roughly 525,600 blocks if it starts at zero; with the height set one day before that first payout, it scans 720.

How to pick the number. Find the first incoming transaction to any address of that wallet in a block explorer and read its height. Then subtract a margin. One day of blocks is 144 on Bitcoin, 720 on Monero, 576 on Litecoin and 1,152 on Zcash because Zcash targets 75-second blocks. A 1,000-block margin on Monero covers about 33 hours. When you create a wallet, record both the height and the date; the date alone is enough because every compatible wallet converts it. If the old wallet file or cache still exists, export its height before deleting anything. If you only remember the month, round down by a few weeks — extra scan time is cheaper than a missing transaction. (Zcash vs Monero 2026)

Bitcoin and Litecoin add the gap limit. BIP-44 tells wallets to scan the external address chain until they hit 20 consecutive unused addresses, then stop on the assumption that nothing is beyond that point. Receiving on each address resets the counter, so a fresh address per swap is safe if every address is actually used. The danger is pre-generation: create 25 receive addresses for future swaps, use only the 25th, restore from seed, and the wallet can stop at address 20 and report zero. The funds are on-chain at a path the restore never derived. The fix is not reinstalling the wallet; it is raising the gap limit and rescanning. Electrum exposes the tools directly: `getminacceptablegap` returns the minimum limit needed to discover every known address, and `changegaplimit` changes it (with a confirmation flag). (Monero confirmation waits)

Zcash has a birthday instead of a height. zcashd derives the wallet birthday from the earliest key creation time and, on rescan, skips blocks whose timestamps are older than that birthday minus a time window (wallet.cpp). Light wallets ask for a birthday height instead. The same rule applies: too high hides older notes, too low reads the whole chain. Zcash targets 75-second blocks, so one day is 1,152 blocks and one year is 420,480 — more than eight times Bitcoin's block count for the same wall-clock period. Shielded notes do not make the scan optional; the wallet still has to read the blocks to find them. (Zcash vs Monero 2026)

Account-based chains replace the height with a derivation path. EVM wallets do not scan a chain; they derive addresses from m/44'/60'/0'/0/0 and an account index. A different path or index produces a different address set, and the restored wallet can look empty even though the seed is right. Solana wallets have their own path conventions, so a seed restored into a different wallet can land on a different address. Before moving funds, compare the first receive address generated by the restored wallet with the address you actually used. If they differ, check the path and index, not the balance. (SOL to XMR guide)

Six checks before trusting a restore. One: write the height or birthday and the creation date next to the seed — they are not secret, and losing them costs scan time. Two: set lower, not higher; Monero's guide is explicit that a too-high height silently misses transactions. Three: compare a known address character by character, not just the balance. Four: run the restore on a spare device before funding it. Five: on UTXO chains, if you pre-generated addresses, check the gap limit; Electrum's `getminacceptablegap` is the direct check. Six: if you change the height after syncing, rescan — editing the field alone does not re-read old blocks. The common mistakes are using today's height for an old wallet, leaving the field blank on a legacy seed, restoring a BIP-39 12/24-word phrase into a Monero wallet, forgetting a seed-offset passphrase, and using an exchange deposit address as the payout or refund address — that address is not yours. (recovering misdirected funds)

Closing: the keys never changed. A swap payout is just an output to an address derived from your seed, which is why the same words can recover it years later — and why the restore height and gap limit decide whether the recovered wallet shows it. As of writing (7 November 2026, 10:20 UTC), 1,000 USDT-TRC20 quoted 1.610578 XMR across two routes (150 bps advantage), 0.01 BTC quoted 1.223795 XMR (122.3795 XMR per BTC), and the catalog listed 438 assets on 65 networks, six of which need an extra ID. Quotes move; the live page governs. The restore settings do not move: write them down when you create the wallet. (XMR to USDT exit)