View-Only Wallet Setup: Monitor Your XMR Holdings Without Spending Capability

An advanced user holds significant Monero but wants to check balances and transaction history without keeping spending keys accessible on an internet-connected device. A view-only wallet solves this operational problem: it uses the public view key to scan the blockchain and display incoming transactions, while the private spend key remains offline and inaccessible to anyone with access to that monitoring machine. This separation is not merely convenient; it is a deliberate security architecture that aligns with how a Monero wallet should handle the distinction between reading and controlling funds.

The practical advantage is straightforward. A user can monitor their holdings from a compromised device, a shared computer, or a machine in an insecure location without risking funds. If the viewing device is breached, an attacker gains visibility into transaction history and balances but cannot move, spend, or transfer any Monero. The spend key—the credential required to authorize transactions—remains on an offline device or in secure storage, making actual theft significantly more difficult. Understanding how to set up and use this architecture requires clarity about what the view-only wallet reveals, what it cannot do, and how to manage the keys that make it possible.

The cryptographic foundation of view-only functionality

Monero’s key structure divides control into two independent asymmetric keys. The spend key is the private credential that authorizes transactions and moves funds. The view key is derived from the spend key but cannot be used to create valid transactions—only to decrypt and verify that funds received belong to a specific wallet. This mathematical relationship is not optional; it is built into Monero’s protocol. A Monero wallet can derive its view key from its spend key, but the operation is one-directional: knowing the view key does not reveal the spend key.

When a view-only wallet is created, the user extracts only the public view key and the public receive address. These two pieces of information allow the wallet application to scan the blockchain, identify incoming transactions sent to that address, and calculate the balance. The application can display transaction details, amounts received, and timestamps. What it cannot do is approve outgoing transactions, alter blockchain records, or authorize any payment. The spend authority remains exclusively with the offline device holding the full private spend key.

This design reflects a fundamental principle in key management: separate the credential needed to read from the credential needed to modify. Applied to a Monero wallet, it means a viewing device can have complete information about the state of funds without having the power to move them. An attacker who gains access to the viewing machine learns what the account contains and its transaction history, but cannot extract or spend the Monero. The cost of theft rises sharply because the attacker would need to separately compromise the offline device where the spend key resides.

The view key itself deserves careful treatment. Although it cannot authorize spending, it does allow anyone with it to see all past and future transactions received by the wallet. Some users treat the view key as a balance-checking credential and share it cautiously; others keep it as confidential as the spend key. The privacy implications depend on the user’s threat model. If an adversary knows both the view key and the receiving address, they can link every Monero the wallet receives to that account. For most users, protecting the view key is a lower priority than protecting the spend key, but it remains part of the complete security picture.

Setting up a view-only Monero wallet

The process begins with a standard Monero wallet on a secure offline device. Using the official Monero CLI wallet, a graphical client, or a compatible third-party application such as the monero wallet service, the user generates a new wallet with a recovery seed and a pair of keys. This initial wallet should be created on the offline device where the seed will be stored and backed up. Write down the recovery seed (a 25-word mnemonic) and store it in a secure location, such as a safe deposit box or encrypted offline storage.

Once the wallet exists, the user must export the view key and the public address. In the CLI wallet, the command `export_key view` displays the private view key, while `address` shows the standard receive address. In graphical wallets, these options typically appear under a security or account menu. The user then records both values. The public address is not sensitive and can be written down or even published if the user wants to receive funds. The view key should be treated carefully—written down or saved to an encrypted file, depending on the user’s storage preferences.

The next step is to move these two pieces of information to the viewing device. If the viewing machine is internet-connected, the user might type them directly into the view-only wallet application or import them from an encrypted file. If the viewing machine is also offline, a USB drive or other removable media can transfer the credentials. The key principle is that the spend key and recovery seed never travel to or appear on the viewing device. Only the view key and address are shared with the monitoring application.

On the viewing device, the user opens the view-only wallet application and selects the option to create or import a view-only wallet. This typically requires entering the public address and the private view key. The wallet will then begin scanning the blockchain to detect transactions sent to that address. The first scan may take several minutes because the wallet is examining every block since the creation of the account, but subsequent syncs update incrementally. Once setup is complete, the viewing device displays balances, transaction history, and confirmation statuses without any option to send funds.

Why view-only wallets reduce exposure on compromised machines

A typical attack on a user’s device aims to capture credentials that move assets. Malware that steals private keys, intercepts transaction signing, or captures wallet passwords can result in direct loss. A compromised viewing machine running a view-only wallet cannot be exploited in these ways because the spend key is not present. Even if the attacker gains administrative control of the viewing device, they cannot extract spending capability.

This protection is strongest when the viewing machine is physically and logically separated from the device storing the spend key. If both devices are in a user’s home and both are compromised by malware, the separation offers less value because the attacker could potentially move both devices under their control. However, if the viewing device is a shared computer, a cloud-hosted machine, a phone in an insecure location, or a system that needs to be rebooted or reset frequently, the advantages become clear. The viewing device can be compromised, wiped, or replaced without affecting the security of funds.

The attack surface of a view-only wallet is also narrower in a security sense. A standard Monero wallet that holds spending keys must defend against theft of those keys, accidental exposure in memory, and attacks that trick the user into signing malicious transactions. A view-only wallet eliminates the signature-based attacks because there is no signing capability. It reduces the damage from key compromise because the view key only reveals information, not control. The remaining risks are information leakage—an attacker learns transaction history and balance—and operational mistakes, such as confusing the view-only wallet with a spending wallet and losing funds by misunderstanding what the device can do.

Transaction sending with offline key approval

A user who wants to spend Monero must take additional steps because the view-only wallet cannot sign transactions. The typical workflow uses a technique called offline transaction signing. The view-only wallet prepares the transaction details—selecting inputs, calculating fees, defining outputs, and generating a transaction structure—but marks it as unsigned. The user then exports this unsigned transaction to a file or displays it as text.

The unsigned transaction moves to the offline device holding the spend key, either via a USB drive, a paper printout (for extremely paranoid setups), or manual typing if the transaction is small. On the secure machine, the user opens a full Monero wallet with the spend key, imports the unsigned transaction, reviews the details carefully, and signs it. This step requires the spend key to authorize the transaction cryptographically. Once signed, the user exports the signed transaction as a file or text again and moves it back to the viewing device or to a connected node.

The viewing device or a connected network node can now broadcast the signed transaction to the Monero network. Since the transaction is already signed, no further approval is needed. The network relays the transaction, miners include it in blocks, and the balance of the wallet decreases as the Monero is sent to the recipient. This process is slower than pressing a single send button on a standard connected wallet, but it eliminates the need to keep the spend key online. The trade-off between convenience and security is explicit and controllable.

This workflow requires that the user carefully review the unsigned transaction before signing it. If the user makes a mistake in the transaction details or if malware on the viewing device modifies the unsigned transaction, the user could send funds to the wrong address or pay unexpectedly high fees. To mitigate this risk, users should examine the recipient address and output amount multiple times before approving the signature on the offline device. Some wallet implementations also allow signing to be delegated to a hardware wallet, which can provide a second review step and additional protection against key theft.

View-only wallet security and privacy boundaries

A view-only wallet reveals a significant amount of information about account activity. Every transaction sent to the associated address is visible, along with the amounts and approximate timing. An observer who associates the address with an individual can infer spending patterns, account size, and recipient destinations. This is why a view-only wallet, despite its security advantages for key management, does not solve the transaction privacy problem on Monero’s network level.

Monero’s protocol includes ring signatures and stealth addresses, which obscure transaction relationships at the protocol layer. Ring signatures mix the actual spending key with decoy keys, making it difficult for observers to determine which output is being spent. Stealth addresses are one-time addresses generated for each incoming payment, preventing address reuse and making it harder to link multiple payments to a single account. However, these privacy mechanisms operate at the blockchain level, not at the wallet application level. A view-only wallet respects these mechanisms, but it cannot add privacy protection that the protocol does not provide.

The viewing device’s network connection also matters. If the view-only wallet connects to a full node, that node can observe the requests the wallet makes when scanning the blockchain. A malicious node operator could observe which blocks the wallet is querying, potentially inferring which addresses belong to the user. To reduce this exposure, users can run a personal full node on the viewing machine or connect through a privacy-focused node configuration such as a Tor connection. The wallet security itself is strong, but network privacy requires additional attention to node selection and network routing.

Recovery and backup considerations for view-only setups

A view-only wallet is not a complete backup of the original account. Backing up the view key and address alone does not preserve the ability to spend funds. If the offline device holding the spend key is lost, damaged, or destroyed, and the recovery seed was not separately backed up, all Monero is inaccessible. The view-only wallet will still show the correct balance and transaction history, but no one will be able to authorize transactions to move those funds.

The recovery seed of the original Monero wallet is therefore the most important backup. It must be stored separately from both the viewing device and the offline spending device. A common best practice is to write the seed on paper and store it in a physical safe, a safe deposit box, or another secure offline location. Some users create multiple copies and distribute them across different physical locations to protect against fire, theft, or natural disaster. The seed must remain unencrypted and secure because it is the ultimate recovery mechanism for the entire account.

For users who want to add redundancy, the view key and address can also be backed up, though this is less critical. If the viewing device fails, the user can recreate a new one by re-entering the view key and address on a replacement device. The viewing application itself can be reinstalled from a trusted source. Neither step requires the spend key. The offline spending device should have its own secure backup strategy, whether a copy of the recovery seed in a different location or a hardware wallet that can be replaced by restoring from its backup seed.

Hardware wallets and view-only wallet integration

Many users combine hardware wallets with view-only wallet functionality to achieve both strong key security and convenient monitoring. A hardware wallet such as a Ledger or a Trezor stores private keys on a dedicated device and never exposes them to a computer’s operating system. The viewing computer can display a view-only wallet associated with that hardware wallet’s address, and when the user wants to spend, the hardware wallet signs the transaction after the user confirms the details on the device’s screen.

This setup provides additional security advantages beyond simple offline storage. The hardware wallet’s operating system is isolated and designed specifically to protect keys. The user must physically approve each transaction on the device, providing a human checkpoint before any funds are moved. If the viewing or signing computer is compromised, the attacker still cannot extract the key from the hardware wallet or trick the device into signing unauthorized transactions without the physical confirmation.

The downside is that not all hardware wallets have full Monero support, and those that do may have different levels of maturity and testing. Some hardware wallets support Monero directly, while others require workarounds or integration with specific wallet software. Users interested in hardware wallet integration should research the specific device and software combination thoroughly, test with small amounts before relying on larger balances, and ensure that both the hardware wallet and the associated view-only wallet software are kept up to date.

Best practices for operating a view-only Monero wallet

The most reliable approach is to treat the viewing device and the spending device as entirely separate systems with different security profiles and update cadences. The viewing device might be internet-connected and updated frequently, while the spending device remains offline and updated only when the user specifically decides to do so. This separation reduces the risk that a zero-day vulnerability or a network attack will affect both devices simultaneously.

Users should never enter the recovery seed or spend key into the viewing device under any circumstances, even if a wallet application prompts for it. Legitimate view-only wallet software will never ask for the spend key. If a wallet application requests the full seed or spend key, it is either a mistake in the software design or a phishing attempt. Users should verify the source of any wallet application before installation, preferably by downloading from the official Monero project website or a trusted third-party distributor.

Regularly testing the recovery seed is a best practice that many users neglect. Every few months, a user should verify that the recovery seed can regenerate the wallet and that the view key matches the original account. This test should be done on a secure machine and in a controlled way that does not expose the seed to unnecessary networks or devices. Testing the recovery process before a crisis occurs prevents the discovery that the backup is incomplete or unreadable when funds actually need to be recovered.

When monitoring the view-only wallet, users should pay attention not just to the balance but to the transaction history and confirmation statuses. Unexpected transactions, missing received funds, or transactions that remain unconfirmed for an unusual time can signal problems. A view-only wallet cannot prevent theft, but it can provide early warning if the spending device has been compromised or if the recovery seed is in someone else’s hands. Regular review of transaction activity is a simple monitoring practice that can catch problems before significant losses occur.