Monero view keys reveal incoming XMR without granting spending authority
Monero view keys let a view-only wallet recognize incoming XMR outputs and read their amounts without a private spend key. The public view key forms part of a receiving address; the private view key supplies the secret used during scanning. Sharing that secret exposes incoming payment information without granting spending authority. Tracking a remaining balance after spending also needs spent-output information, usually supplied through matching key images, because incoming records alone do not identify spent outputs.
last updatedAfter spending, a view-only wallet needs matching key images to distinguish spent outputs from the XMR it still holds.
Incoming XMR appears through output recognition
Output recognition connects a transaction's one-time destination to the receiving wallet's keys. The sender creates that destination using information from the receiving address and a transaction secret. The blockchain carries transaction public-key information the recipient combines with the private view key to derive a shared secret. Wallet software uses that derivation to check an output against the public spend key or the relevant subaddress key. A match identifies an output addressed to that wallet.
The same derivation supplies the information needed to decode RingCT output amounts. RingCT means Ring Confidential Transactions, the mechanism hiding ordinary transfer amounts from public observers. An output is a specific piece of value a transaction creates. Its amount and receiving destination can be readable to a view-only wallet even though public blockchain data does not display them as an account ledger.
Public and private view keys connect different parts of a payment
A receiving address contains public view and public spend keys. Senders use those public components to construct payments. Publishing an address does not grant the secret scanning access associated with the private view key.
The private view key supplies scanning access. A view-only wallet combines it with the primary address to recognize outputs, without needing the private spend key.
The private spend key enables construction of the one-time private keys needed to spend owned outputs. Keeping it outside the monitoring wallet separates discovering funds from authorizing their movement. A spending setup needs the relevant signing secrets, whether software or a separate signing device holds them.
In standard deterministic Monero wallets, a one-way hash operation derives the private view key from the private spend key. Knowing the derived view key does not reveal the spend key. Nondeterministic wallets use independently generated keys, so the deterministic backup relationship does not apply universally.
Can a view-only wallet show an accurate balance?
A view-only wallet can track a remaining balance when it recognizes the relevant outputs and obtains reliable spent-status information. The private view key alone supplies the receiving side. An otherwise complete scan can overstate the balance after the wallet spends funds.
Key images connect owned outputs to their spending status. A spending transaction contains key images, allowing the network to reject duplicate spending without publicly identifying the actual output within its ring. The view-only wallet cannot derive the required key images from its viewing secret alone.
Importing matching key images lets a view-only wallet check whether its outputs have been spent. Software-wallet cold-signing tools can exchange output data and signed key images between the watching wallet and its signer. Freshly received outputs need corresponding key images if later spending of those outputs must remain trackable.
Change returns as a new wallet-owned output. A view-only scan can recognize it without identifying the outgoing transaction as a spend. Adding every recognized output therefore does not give total external receipts or an available balance. Spent-status information also does not reconstruct recipient addresses stored only in the sending wallet's cached transaction history.
Subaddresses inherit the wallet's viewing scope
Subaddresses share the underlying private view key across a wallet, including its account groupings. Their address-specific public keys help the wallet recognize different receiving destinations. A view-only copy can therefore monitor subaddresses without obtaining a separate private spend key for each one.
Address discovery has a software limit. Wallets precompute a range of account and subaddress indexes called the lookahead. Receipts outside that range can remain missing until the wallet expands its search and scans the relevant history. Lookahead limits the current search range; it does not restrict the shared key's underlying scope. Another account inside the same wallet does not provide a separate viewing boundary.
What does a shared private view key expose?
Sharing a private view key and primary address gives the recipient broad access to incoming-output information. That includes amounts and the transactions containing those outputs across the wallet's derived receiving addresses. The recipient can continue scanning future payments using the same receiving keys. The secret carries no expiration date or revocation switch. Changing receiving subaddresses or moving between the wallet's account groups leaves the underlying viewing access intact. Anyone holding the key may retain information already learned, independently of the wallet software or service where the sharing began.
Future receipts need a wallet with independently generated keys to fall outside that shared viewing scope. Previously disclosed transaction information remains disclosed.
Monitoring and offline signing keep spending keys separate
A view-only copy contains viewing credentials while its corresponding signer retains spending authority. Monero GUI supports creating a view-only copy of an existing wallet or restoring one from the primary address and private view key. The restoration method leaves the private spend-key field empty. A recovery seed capable of restoring the spending wallet carries more authority than a view key.
Software-wallet offline signing separates transaction preparation, signature creation and network submission. The watching wallet can prepare unsigned data and submit an already signed transaction. The offline signer needs to check the intended destinations and amounts before authorizing the transfer. Monitoring can cover ordinary incoming transfers and mining payouts without putting spending secrets on the scanning device.
Hardware-backed wallets have separate device workflows. Monero CLI v0.18.5.3 rejects its software key-image export and import commands for those wallets; their supported device integration determines key-image synchronization.
Incoming records do not identify the sender
An incoming output does not reveal its sender's address through the private view key. The scanner recognizes the receiving destination and decodes its amount, while the transaction's ring obscures which earlier output actually funded it. Identifying a payer requires information outside that recognition process, such as a receiving-address assignment or a transaction-specific payment record. Local records can attribute a receipt without making the sender's address readable from the blockchain.
Is a private view key necessary to confirm one payment?
A private view key is unnecessary when a valid transaction-specific proof supplies the required payment evidence. A transaction key belongs to a particular transaction, while the private view key supports recognition across wallet history.
- For ongoing incoming-payment monitoring, the primary address and private view key supply the scanning credentials.
- For balance tracking after spending, matching key images and a current scan must cover the relevant outputs.
- For a single payment, a transaction key or payment proof works with the transaction ID and recipient address.
- For separate viewing access, independently generated wallet keys provide a boundary a new subaddress in the existing wallet cannot.
Successful receipt verification shows an amount directed to the specified address in that transaction. It does not prove the outputs remain unspent, unlocked or otherwise spendable.
Monero view keys: common questions
Does changing my wallet password revoke access to a copied view key?
Changing a wallet password does not invalidate a private view key someone already copied. The password protects local wallet files; it does not change the wallet's cryptographic keys. A recipient holding the raw viewing secret can keep using it without knowing the replacement password.
Why can a correct view key miss an older incoming payment?
A restore height later than an incoming payment excludes that payment from the wallet's ordinary history scan. Starting the scan earlier covers that history, although synchronization still needs to finish. Payments to subaddresses also require adequate address lookahead. Correct credentials alone do not establish complete scan coverage.
Does a normal remote node receive my private view key?
A standard Monero GUI or CLI daemon connection does not send the private view key to the node. The wallet scans transaction data locally. A service performing wallet scanning on a server has a different arrangement and may request the viewing secret, exposing incoming-payment information to that service.
How can the CLI's trusted-daemon setting affect key-image imports?
In Monero CLI v0.18.5.3, import_key_images refuses a daemon connection the wallet has not marked as trusted. This setting changes which operations the wallet permits. Marking a connection trusted does not establish the operator's trustworthiness; spent-status queries expose key images to the node, so its ownership matters.
Will restoring from a private view key recover saved address labels?
Restoring from the address and private view key does not recover locally saved address labels. The wallet can derive receiving addresses, while labels and transaction notes belong to saved wallet data. A copied wallet file may retain that information; recreating a wallet from keys alone cannot reconstruct those annotations.
Can a view-only wallet generate a spend proof?
A view-only wallet cannot generate a spend proof because it lacks the private spend key. Imported key images provide spent-status information without supplying the signing authority this proof requires. A receipt proof and a spend proof establish different facts, so access to one does not imply access to the other.