A Monero wallet restored from a height later than its first relevant payment can skip that payment and display the wrong balance. Choose a scan start at or before the earliest incoming transaction you need, then allow synchronization to finish. A lower height costs more scanning time; it does not move your coins or create a new payment.
Case one: recent payments appear, older ones do not
This is an illustrative diagnostic pattern, not a customer story: the restored wallet recognizes a recent incoming payment, but an earlier deposit is missing. Check the configured restore height against the earlier transaction's block. The official Monero restoration guide says that a height above the first incoming transaction can produce an incorrect balance because the earlier history is not scanned.
The installation date of your current app is not necessarily the beginning of the wallet's history. Neither is the date you last exported the backup. An older wallet can have used the same keys before either event. Base the starting point on the account's relevant transaction history, not on when the replacement phone or computer first opened it.
If you know a payment hash, a suitable Monero explorer can show the block containing that transaction. That identifies an event on the chain; it does not publicly reveal every payment belonging to your wallet. Keep the transaction reference and your own records together. Do not ask a stranger to identify your full balance by entering secret recovery words into a website.
Case two: everything is missing, but the scan is still running
A restore-height correction does not make results immediate. The wallet still has to inspect the relevant blockchain data. If a local node is not synchronized, it also has to catch up before the wallet can complete its work. The restore-height change guide explicitly distinguishes the rescan from an unfinished local-node synchronization. A progress indicator is therefore useful evidence, not merely a cosmetic delay.
Write down whether the wallet is scanning, whether the node is connected and whether its reported chain progress is advancing. Those observations distinguish a slow scan from a connection failure. Recreating the wallet repeatedly while the same underlying node remains behind can repeat the waiting period without answering the question. Avoid promising yourself a fixed completion time: the amount of history and available resources differ.
| Observed pattern | Restore-height explanation | Evidence to collect | Different issue to keep separate |
|---|---|---|---|
| Newer payments appear; older payments are absent | The scan may have started after older history | Configured start and the first relevant payment block | A different restored wallet |
| No payments appear while scan progress advances | The relevant blocks may not have been processed yet | Wallet and node synchronization progress | An application with no usable node connection |
| Scan completed but the expected account differs | An earlier start cannot fix different keys | Your known primary address and original backup arrangement | Wrong recovery material or an unintended passphrase |
| Total balance is present but less is spendable | This is not necessarily skipped history | Total and unlocked amounts in the same account | Output-lock and availability rules |
| Balance returns but old notes or payment keys are absent | Chain scanning does not replace every local record | Existing wallet files and cache backups | Loss of locally stored transaction metadata |
Case three: the account itself does not match
If the wallet completed its scan but the expected history still does not fit, verify that you restored the intended account. Compare its known primary address and original recovery arrangement. An unintended seed offset passphrase can derive another wallet; the restoration guide distinguishes that option from the password protecting a local wallet file. Do not repeatedly lower the scan start to compensate for different keys.
Subaddresses are a separate display consideration. A payment can have used one receiving subaddress while you are looking at another account view in the application. The existing Monero subaddress guide explains that distinction. Identify the intended wallet first, then inspect its accounts and discovered payments rather than treating every changed visible receive address as proof of a different seed.
Preserve the wallet records before changing the scan
The official GUI instructions warn that changing the restore height clears cached information such as recipient addresses, transaction keys and descriptions, while retaining a cache backup. That warning matters even when the underlying funds remain recoverable. Before proceeding, preserve the existing wallet files securely and understand where the application stores its backup. Do not delete the original working data merely because the secret recovery words are available.
A scan can reconstruct what the wallet can recognize from blockchain history; it does not promise to reconstruct every locally recorded description or payment key. The view-key explanation helps distinguish account observation from spending and payment proof. Keep original payment evidence when you may later need to demonstrate an outgoing transfer. A correct balance and a complete personal transaction notebook are different recovery goals.
Change the starting point once, then verify the result
- Find the earliest relevant incoming transaction or a conservative date before it. If the date is uncertain, prefer including extra history to skipping potentially relevant blocks.
- Secure the existing wallet files and local records. Read any cache-reset warning before accepting it.
- In Monero GUI, inspect the wallet information settings and use its restore-height change control. Follow the official instructions for your installed wallet rather than an unrelated recovery website.
- Set the earlier height or supported date and allow the wallet to rescan. If using your own local node, let that node synchronize as well.
- Check that a known old payment and a known recent payment are both recognized. Reconcile total and unlocked balances separately before attempting a new outgoing transfer.
There is no need to send a new payment to make the old history discoverable. If you are preparing a later no-account swap, resolve synchronization and the amount actually available to spend before creating a time-sensitive order. A restore-height setting does not extend an order's validity or establish that the sending wallet has enough currently usable funds.
Leave a useful record if the mismatch remains
Save the wallet application version, selected network, restore height, synchronization state and the public transaction references involved. State whether the problem affects old payments, all payments, unlocked funds or only local descriptions. These are different observations and should not be compressed into a single claim that Monero lost a deposit. Do not include the seed, private spend key or private view key in a routine support message.
If the relevant scan completed for the correct wallet and the expected history still differs, take that precise evidence to verified wallet support. Avoid further destructive resets while the original records remain useful. An unexplained mismatch deserves investigation; paying an unlock fee or restoring through an unknown website does not establish a missing transaction's ownership or status.
FAQ
What is the Monero restore height?
It is the point from which the wallet starts scanning blockchain history for its payments. A start later than an incoming transaction can skip that history and produce an incorrect balance.
How do I change the Monero GUI restore height?
Use the restore-height control in the wallet information settings, following the official guide for your version. Preserve local records first and allow the resulting rescan to complete.
Which XMR restore height should I use if I am unsure?
Choose a point at or before the earliest relevant incoming payment rather than a later date that may omit it. Scanning extra history takes more time, but guessing too late can leave the displayed balance incomplete.