Restoring a Monero Wallet From a Seed Phrase: What Actually Happens When You Rescan
Your seed phrase is the wallet. The files on your disk, the wallet name, the cached transactions, none of that matters after a loss. Twenty-five words in a fixed order regenerate every key the wallet will ever produce, which is why a seed written on paper in a drawer survives a dead laptop, a failed SD card, and a house fire that takes the backups with it. This guide walks through a restore on the official GUI and Feather, explains the two settings people get wrong, and covers what a seed phrase cannot bring back.
Restore only needs the seed and the blockheight
Open the official Monero GUI and pick Restore wallet from keys or mnemonic seed. Enter the 25 words in order, separated by spaces. The wallet also asks for a restore height, and this is the setting that decides how long the restore takes and whether the balance looks correct at first.
The restore height is the approximate date or block number when the wallet was first created. Give it a date before the first incoming transaction and the wallet scans every block from there forward, looking for outputs that belong to your keys. The cost of guessing too early is time. Monero has roughly 2.9 million blocks as of late 2026, and a full scan from genesis on a desktop machine can take hours. The cost of guessing too late is worse. If you give a height after your first payment arrived, the scan starts past it, the wallet never sees that output, and the balance shows less than it should.
If you have no idea when the wallet was created, use block zero or the earliest date you ever held Monero, and accept the longer scan. Feather makes the date guess easier with a date picker, and both wallets let you change the restore height later from the settings, then rescan again. If a balance looks wrong, an early restore height plus a fresh rescan is the first fix to try.
Why the balance reads zero at first, and why that is normal
A restored Monero wallet does not download a list of your transactions. There is no such list on the blockchain for it to fetch. The wallet generates your private view key from the seed, downloads block data from a remote node or your own daemon, and checks every output key in every block against the view key. Only outputs your view key can decrypt are yours, and this is the same stealth address mechanism covered in our guide to how Monero privacy works. Until the scan reaches a block that contains your coins, the wallet genuinely does not know they exist, so a zero balance five minutes into a restore means the scan is not done, not that the coins are gone.
Two practical settings change the experience. First, a local daemon synced in pruning mode is the fastest way to restore on your own hardware. Second, if you connect to a remote node instead, pick one you have some reason to trust, because a remote node operator learns your IP address and can log which blocks you request. Our article on what a remote node operator sees covers the details, and the short version is that restoring against your own node leaks the least.
What the seed recovers, and the two things it does not
Everything derived from the seed comes back: your private spend key, your private view key, your primary address, all subaddresses, and every incoming transaction the scan finds. Change outputs from your own spends also come back, because they belong to keys derived from the same seed.
The first thing a seed does not recover is outgoing history you never see on-chain again. In practice this is rarely a problem, because the wallet rescans and reconstructs its own record as it matches blocks. The second thing matters more. If you ever sent a transaction and kept no record, the counterparty knows more than your restored wallet does. A restore tells you your balance. It does not tell you who you paid, and for that reason our guide to the best Monero wallets recommends keeping a small local record of large payments, or using transaction proofs when a payment needs to be verifiable later.
The recovery phrase vs the wallet file and password
People conflate three things, and the confusion costs coins. The 25-word seed regenerates keys, full stop. The wallet cache file, .keys file on disk, holds the seed plus a record of labels, address book entries and notes. The wallet password only encrypts those local files. Lose the password and nothing is lost, because the seed works without it. Lose the seed with the password intact and the coins are gone, because the password decrypts files you no longer have.
That leads to the check worth doing once a year. Restore your seed on a second device with a restore height well before your first transaction, let the scan finish, and confirm the balance matches. A five minute drill on a spare laptop proves the backup works, and the number of people who discover their paper backup has a wrong word only after a drive failure is not small.
Common restore failures and their fixes
Wrong word order or a missing 25th word: the seed checksum fails and both wallets refuse it. The 25th word is a checksum, so a transcribed phrase with a typo is rejected rather than restored silently. That rejection is a feature. It is better than a wallet that restores to a different, empty set of keys.
Balance stays zero after a completed scan: your restore height was too late, or the seed belongs to a different wallet. Fix the height first, rescan, and only then start asking harder questions.
Scan crawls: you are restoring from a remote node across a slow connection. A local pruned daemon is several times faster for a full-history restore.
Old wallet with payment IDs: pre-2018 wallets may have used long payment IDs for incoming exchange withdrawals. The funds still restore fine, the payment ID itself was just a memo field.
Once the scan completes and the balance is right, close the wallet, make a fresh backup of the cache file, and write the date on the paper seed so the next restore has an honest restore height to start from. Ten seconds of handwriting saves an hour of scanning in a couple of years.