A portfolio manager or accountant needs to monitor Monero holdings without holding the spending keys. Conversely, a device owner may want to maintain a balance check on an air-gapped phone without loading the full wallet. Traditional cryptocurrencies like Bitcoin make this straightforward: a public address and transaction history are visible to anyone. Monero’s privacy model complicates the picture because transaction amounts, recipients, and senders are encrypted by default. Yet auditing still matters—for compliance, oversight, or operational clarity. View-only mode addresses this tension by decoupling transaction visibility from the ability to spend, but the implementation details determine whether it truly solves the problem or merely shifts the privacy boundary.

Cake Wallet’s approach to view-only accounts reveals the engineering trade-offs inherent in Monero’s architecture. The wallet must handle the private view key—the secret needed to decrypt transaction details—in a way that lets a third party observe activity without gaining access to the spending key. That separation is technically sound, but it requires careful handling of what information is stored, where it is transmitted, and which actors can see it. Understanding how this works is essential for anyone managing Monero across multiple devices, delegating monitoring tasks, or simply wanting to audit their own activity without exposing unnecessary keys to an online interface.

The architecture of Monero’s dual-key system

Monero uses two separate cryptographic keys to control and monitor a wallet: the spending key and the view key. The spending key is required to create transactions and move funds; it is the secret most closely guarded. The view key allows the wallet to decrypt and observe all incoming and outgoing transactions without the ability to spend. This separation exists because Monero’s transaction protocol encrypts transaction details using the recipient’s public keys. Only someone with the private view key can unlock and read those details. Someone with only the view key can see that transactions occurred, what amounts were involved, and who participated, but cannot authorize a payment or move funds.

This architecture emerged from Monero’s design philosophy: privacy should be available by default without requiring users to understand complex settings. When a user creates a Monero wallet in Cake Wallet, both keys are generated and stored locally. The user’s seed phrase—a 24-word recovery phrase—encodes both keys. However, the wallet can derive the view key independently and share it with a trusted party or device without exposing the spending key. A third party holding only the view key becomes an auditor with read-only access.

The separation is mathematically clean but operationally nuanced. A view-only account still needs to synchronize with the Monero blockchain to observe transactions. That synchronization process involves scanning blocks, identifying outputs belonging to the wallet, and recording transaction history. Cake Wallet handles this on the user’s device by default, but the synchronization must contact a Monero node to retrieve blocks. That contact point—the node itself—can potentially see which blocks are being requested, and therefore infer account activity based on network traffic patterns. The privacy boundary therefore extends beyond the keys themselves to include the network requests made during synchronization.

How Cake Wallet implements view-only mode in practice

Creating a view-only account in Cake Wallet begins with the primary wallet’s private view key. The user accesses the wallet settings, finds the option to export or view the private view key, and can then create a separate view-only wallet—either in Cake Wallet on another device or by importing the view key into another application entirely. Cake Wallet itself does not require the spending key to be present; the view-only mode is a first-class feature, not a degraded backup. This means a user can configure an entire device or account dedicated to monitoring without ever introducing the spending key.

The mechanics work as follows: when the view-only wallet synchronizes with the Monero network, it downloads blocks and scans them locally using the view key to identify which outputs belong to the wallet. The wallet can then compute the amounts received and construct a complete transaction history. All of this happens on the device without the view key being transmitted to Cake Wallet’s servers. The non-custodial design means the application itself is not involved in managing the key or authorizing observations. The user’s device does the cryptographic work directly.

Background synchronization in Cake Wallet adds a practical layer to this setup. Rather than requiring manual updates, the wallet can periodically request new blocks when the device is powered on and the application is installed. For a view-only account, this means that balance information and transaction history can remain current without the user repeatedly opening the application. The background process still contacts a node—either Cake Wallet’s default node or a custom node specified by the user—but it does so using the same protocol as foreground synchronization. The privacy implications are similar: the node operator can see which account is being queried, though the actual transaction amounts and identities remain encrypted unless the node operator also possesses the view key.

One critical detail is that view-only accounts cannot generate new addresses in the same way a full wallet can. Monero supports subaddresses—unique receiving addresses derived from the master account without creating separate keys. A view-only wallet can view subaddresses that have already been generated by the full wallet, but generating new subaddresses requires the private spend key. This means a delegated auditor or a device running view-only mode cannot expand the address space on its own. The primary wallet must generate subaddresses and share the details with the view-only instance. For most monitoring scenarios this is acceptable; for dynamic address management it requires coordination.

Why view-only mode is not the same as full privacy

A critical misconception is that holding only the view key provides complete anonymity. The view key holder can see amounts, timing, and recipient information for every transaction. They can build a complete profile of the wallet’s financial activity. The privacy benefit is not that transactions become invisible; it is that the viewer cannot spend funds and the holder of the spending key does not need to expose it to an auditor or to an online device. The two privacy goals are different and should not be conflated.

Moreover, view-only mode does not protect against network-level observation. If an auditor device is using Cake Wallet to monitor Monero holdings, that device is still making requests to a Monero node over the internet. Unless those requests are routed through Tor or another anonymity network, the node operator can potentially correlate the requests with the source IP address. The view key itself remains private, but the fact that an account is being queried and synchronized is visible to the node. An adversary with access to node logs could identify patterns of which accounts are active and when, even without knowing the amounts or recipients.

A user concerned about this vector can configure a custom Monero node or route all traffic through Tor. Cake Wallet supports both options. Running a private node eliminates the concern that an external node operator could observe queries. Using Tor reduces direct IP address exposure, though it introduces dependency on the Tor network itself and can slow synchronization. The trade-off is between convenience and the specific threat model. For a user auditing their own Monero holdings on a personal device, the convenience of default synchronization may be acceptable. For a business auditor monitoring a major account, a dedicated node or Tor routing becomes more defensible.

Practical scenarios where view-only mode changes security posture

The first scenario is portfolio oversight by a trusted party. An investor might hold Monero in Cake Wallet on a hardware device or air-gapped machine, but want a spouse, accountant, or business partner to verify holdings and transaction history without granting access to the spending key. By exporting the view key and importing it into the Cake Wallet app on the auditor’s device, the investor grants permanent observation without exposure risk. The auditor can run background synchronization, check the current balance, and review transaction history, but cannot create a withdrawal or alter the wallet in any way. The separation is clean and does not require the primary wallet to remain online.

The second scenario is device segregation. A user might maintain a full Monero wallet on a secure, infrequently-online device (such as a hardware wallet or air-gapped phone), and a view-only instance on an internet-connected phone for checking balance during daily life. The view-only version answers the question „How much Monero do I have?“ without exposing the spending key to the internet-connected device. If the phone is compromised, an attacker gains visibility into recent transactions and the current balance, but cannot move funds. The attack surface has been reduced compared to running the full wallet on an online device.

The third scenario is operational delegation in an organization. A treasurer might hold the Monero spending key on a secure machine, while a finance manager with view-only access monitors inflows and outflows for compliance or accounting purposes. The division of responsibility is clear: only the treasurer can authorize payments, but the finance manager can immediately see that a payment occurred and verify the amount. This reduces the need for the treasurer to provide manual reporting and allows the finance manager to catch anomalies or discrepancies. The view-only account is still subject to network observation risk, but that risk is lower than requiring the finance manager to use a shared wallet or requesting frequent exports from the treasurer.

All three scenarios depend on careful handling of the view key itself. If the view key is written to a plain-text file and emailed, uploaded to cloud storage, or stored in an application without encryption, it loses much of its protective value. The view key must be treated as a secret—not as sensitive as the spending key, but not as something to broadcast widely. In Cake Wallet, the view key is displayed on screen when requested but is not automatically exported or backed up to external services. The responsibility falls on the user to decide whether and how to share it.

The node selection problem in view-only monitoring

When a view-only wallet synchronizes with the Monero network, it must connect to a node—a machine running the Monero software and maintaining the complete blockchain. That node provides the blocks that the wallet scans for transactions. Cake Wallet offers three options: connect to a default public node maintained by the Cake Wallet project, run a private node, or specify a custom node. Each choice has privacy implications.

The default public node is convenient and works immediately for users who do not want to operate their own infrastructure. However, the node operator can see which accounts are querying for blocks and when. If the same view-only account regularly connects from the same IP address, the node operator could potentially correlate that behavior with other information to identify the account holder. This is not a fundamental flaw in Monero’s privacy model—the private view key still prevents the node from seeing transaction amounts or spending capability—but it is a limitation that some users need to understand. For casual balance checking, this risk may be acceptable. For an account holding significant funds or for a user who values strict location privacy, a different node strategy is warranted.

A private node eliminates this concern by giving the user complete control over which machine processes the blocks and observes the queries. Running a full Monero node requires substantial disk space (the blockchain is over 200 GB) and bandwidth, but it is technically feasible for users with the resources. Cake Wallet can connect to a private node if the user specifies the node address. The setup is more complex than default synchronization, but the privacy benefit is significant: the user knows exactly who is observing their account activity, and that observer is themselves.

A custom node—one operated by a trusted third party or managed as part of an organization’s infrastructure—offers a middle ground. The user retains control over which node handles their requests, which can improve privacy compared to a public node while avoiding the operational burden of running a node independently. This is common in business environments where a single organization operates multiple Monero wallets and wants to synchronize them through a dedicated node rather than spreading queries across the public network.

Integration with hardware wallets and Ledger support

Cake Wallet’s support for hardware wallets such as Ledger adds another layer to the view-only discussion. A user can store their Monero spending key on a hardware device and use Cake Wallet on a computer or phone as the interface for viewing balances and creating transactions. The private keys never leave the hardware device; the Cake Wallet application only handles the view key and transaction metadata. This is operationally similar to view-only mode in that the online device lacks the ability to spend, but it retains the ability to construct and sign transactions (with hardware approval) rather than merely observing.

For a user with a Ledger, view-only mode becomes a supplementary monitoring option. The user might keep the Ledger-secured wallet on a desktop used for payments and hold a view-only copy on a phone for balance checks while away from the office. The hardware wallet itself is not exposed to either device; the Ledger signs the transaction on its own secure chip and returns a signed result. The view-only instance on the phone remains purely observational and requires no hardware approval.

Recovery and portability of view-only accounts

A view-only account created from an exported view key can be imported into any Monero wallet application that supports view-only mode. Cake Wallet is one such application, but others exist. This means a user is not locked into a single wallet if they later want to switch interfaces for monitoring. However, recovery procedures differ slightly from full-wallet recovery. A view-only account does not have a standard seed phrase because the view key alone is insufficient to spend funds. The user should record the view key itself (or the full wallet’s seed phrase from which the view key was derived) as a backup. Losing the view key means losing the ability to monitor that account, though the funds remain secure because only the spending key can move them.

When importing a view key into Cake Wallet, the application derives the public address associated with that key and begins synchronizing. Cake Wallet stores the view key locally and does not transmit it to its servers. The wallet can be used immediately without creating an account or providing personal information. For users who value the anonymous wallet experience, view-only mode preserves that property: Cake Wallet sees no account information, no email, no recovery phrase, nothing that would identify the user or link them to the account. The application is simply a tool for interacting with the Monero network.