Most Monero users restore a wallet exactly once, usually on a new machine, usually in a mild panic. The process looks simple: type 25 words, wait. Then the wallet shows zero balance, or a balance missing months of history, and the doubt starts. This guide covers what the seed actually rebuilds, the settings that change what you see, and the mistakes that cost people real time.
## What the 25 words contain
A Monero seed is the private spend key in encoded form. From it the wallet derives everything: private spend key, private view key, public keys, and every address the standard account will ever produce. The 25th word is a checksum built from the first 24, which is why a typo usually fails immediately instead of silently creating a different wallet.
Two things follow from this that trip people up.
First, the seed doesn’t contain your transaction history. The blockchain does. After restoring, the wallet rescans the chain looking for outputs that belong to your keys. That scan is the slow part, and its length depends on the restore height you give it.
Second, the seed doesn’t contain your address book, labels, or payment requests. Those live in the wallet cache file on the old machine only. If the old cache file is gone, that metadata is gone. The money isn’t.
## Restore height: the setting that saves you hours
When you create a restoration wallet, official Monero GUI and CLI wallets both ask for a restore height. This is the block number, or date, when you first created the original wallet. The wallet then starts scanning from that point instead of from Monero’s genesis block in 2014. Scanning from genesis on a modern machine takes many hours, sometimes more than a day on a laptop HDD or a low-power VPS. Scanning from a date a year ago takes a fraction of that. If you know roughly when you first funded the wallet, use it. If you genuinely don’t know, scan from genesis and let it run. A too-early height is safe, just slow. A too-late height is dangerous, because the scan can miss outputs created before it and your balance will look short.
That last point is the one that hurts. People restore with a guessed height of “2023” when the wallet was funded in 2019, see a partial balance, and spend from assumptions. If anything about your balance looks wrong after a restore, rescan from a much earlier height before drawing conclusions. In the CLI, use the `set refresh-from-block-height 0` command followed by a rescan, or recreate the wallet file from the seed again with an earlier height.
## Why a fresh restore shows zero balance at first
A restored wallet starts with no history. It must scan forward block by block, checking every output key against your view key. Until the scan reaches the blocks containing your incoming transactions, the balance reads zero. Depending on hardware and restore height, “zero” can last twenty minutes or most of a day.
Progress checks: in the GUI the status bar shows the current sync height versus the network height. In the CLI, `status` gives the same numbers. don’t send funds to a wallet still mid-scan if you intend to track the incoming transaction properly, because until the scan passes the block containing it, the wallet can’t see it.
## The subaddress and account question
If your original wallet used subaddresses or additional accounts, a seed restore recovers all of them. Subaddresses are deterministic: the same seed always generates the same subaddress list in the same order. But wallet software only derives subaddresses it has been asked to display. After a restore, create the same number of subaddresses and accounts you used before, in order, and they’ll be identical to the originals.
The classic failure: someone received funds years ago on subaddress index 7, restores, looks only at the primary address, sees nothing, and panics before generating enough subaddresses. Generate generously, they’re free, and check the balance at the wallet level, which sums everything.
## Hardware and multisig wallets restore differently
A seed restore applies to standard single-signature wallets. The multisig wallets covered earlier on this site don’t restore from one seed at all, because no single participant holds the full spend key. Multisig restoration needs the exchange of the same key shares used at setup, plus the aggregate public key. If you’re restoring a 2-of-3 setup, you need at least two of the three original participants’ data.
Ledger and Trezor hardware wallets add another layer. The Monero app on the device derives keys from the hardware seed, and the desktop wallet keeps only a view-only copy. Restoring to a new hardware wallet from its own backup phrase works, but moving to a different device brand produces a completely different Monero address set. Plan hardware migrations as restores onto the same brand, or accept that you’re creating a new wallet and must sweep funds across.
## View-only restores have a separate use case
Sometimes you don’t want to restore spending ability at all. Importing just the private view key, which you can read about in our guide to Monero view keys, gives an auditor or accountant a wallet that sees every incoming transaction but can’t spend. For proving that a payment arrived, that’s enough, and it keeps the spend key off the machine doing the checking.
## A safe restore checklist
Write the seed on paper, never type it into a web page or photograph it. Verify you’re running an official wallet binary downloaded over HTTPS from getmonero.org and ideally check the signed hash list. Set the restore height a few weeks before the wallet’s first funding, not after. Let the scan finish fully before judging the balance. Generate enough subaddresses to cover your old usage. Then back up the new wallet cache file, because labels and history aren’t in the seed.
Restores go wrong in boring ways: guessed heights, half-finished scans, forgotten subaddresses. Get those three right and the 25 words do the rest.