A user receives Monero payments from multiple sources—a freelance client, a peer-to-peer sale, a privacy-focused service—and wants a guarantee that none of these parties can later cross-reference their transactions or build a spending history. Traditional blockchain wallets offer no such guarantee; Bitcoin’s ledger exposes inputs and outputs by design, creating a permanent map of fund movement. Monero solves this through stealth addresses, a cryptographic mechanism that generates unique, one-time addresses for every transaction without ever revealing the recipient’s primary wallet address to observers on the blockchain.
The question is not whether stealth addresses exist in theory. It is how a practical wallet like XMRWallet implements them, why the implementation matters for security, and what assumptions a user must make about privacy when logging in via recovery seed phrase and beginning to receive funds. The difference between a stealth address and a public key is not trivial; it is the foundation that separates a transaction history visible to the world from one that remains opaque even to blockchain analysts with significant resources.
The core problem: Why published addresses are a privacy leak
In a typical Bitcoin workflow, a user publishes a receiving address—a string derived from their public key—and every payment to that address is linked on the permanent ledger. If the same address is reused for multiple transactions, any blockchain observer can aggregate them into a single entity. Even if a new address is generated for each payment, the transaction history can be reconstructed by analyzing amounts, timing, and spending patterns. The publisher of the address (a merchant, employer, or service) already knows the recipient; the blockchain makes that link permanently visible to everyone else.
Monero’s designers recognized that address reuse is a fundamental vulnerability, not a behavioral flaw that users could simply choose to avoid. Rather than relying on voluntary discipline, they built stealth addresses into the protocol itself. Every incoming transaction uses a unique, disposable address that appears on the blockchain as a random value. Only the recipient—and no one else, including the sender—can derive or recognize that address as belonging to their wallet. The sender generates it using public information about the recipient’s account, while the recipient generates the same address independently using their private view key. No third party can link multiple stealth addresses to a single wallet or recognize that payments going to different addresses belong to the same entity.
This is not encryption of the transaction itself. The amount, outputs, and inputs are still recorded on the blockchain. Rather, it is cryptographic obscuring of who receives a payment. The recipient’s account remains invisible; only one-time stealth addresses appear in the transaction history. This privacy property emerges from elliptic curve cryptography and Diffie-Hellman key exchange, not from legal obscurity or secondary services.
How XMRWallet generates a receiving address
When a user logs into XMRWallet using their 25-word recovery seed phrase, the wallet derives their master keys locally on the device. Monero uses a hierarchical key derivation system: from the recovery seed, the wallet generates a primary spend key and a primary view key. These are not addresses themselves; they are the cryptographic foundation that enables address derivation. The spend key is secret and must be protected; the view key can be shared with services that need to monitor incoming payments without the ability to spend them.
When a user requests a receiving address to publish or share with a sender, XMRWallet displays what appears to be a single address. Internally, this address is a sophisticated object containing the user’s public spend key and public view key
XMRWallet’s implementation keeps this process deterministic and local. When the user logs in with the recovery seed, the wallet regenerates all keys from the seed without needing external servers or account lookups. This cryptographic authentication model stands in sharp contrast to traditional account systems that store passwords on central servers. Because all key derivation occurs on the user’s device, the wallet never needs to store usernames, passwords, or recovery secrets. If the device is lost, the user can restore the wallet on another device by entering the same 25-word phrase, and all keys and addresses will be regenerated identically. The sender plays a crucial role in creating the stealth address, though they do not know that is what they are doing. When a sender in XMRWallet (or any Monero wallet) prepares to send funds to a published address, they generate an ephemeral key pair—a temporary public-private key pair used only for this transaction. They then use Diffie-Hellman key exchange to combine their ephemeral private key with the recipient’s public view key, producing a shared secret that is unique to this transaction. From that shared secret, the sender derives a modifier and applies it to the recipient’s public spend key using elliptic curve point addition. The result is a derived public key that becomes the stealth address—the output address on the blockchain that receives the funds. This entire computation uses only publicly available information: the recipient’s published address (which contains their public keys) and the ephemeral key pair generated by the sender. The sender’s software (whether XMRWallet or another Monero wallet) performs this automatically and displays the destination address in the transaction preview. The ephemeral public key is included in the transaction so that the recipient can reconstruct the stealth address. However, linking that ephemeral key back to the sender is computationally infeasible. The ephemeral key pair is temporary, discarded after the transaction, and cryptographically independent of the sender’s long-term keys. This design ensures that even if an observer sees the ephemeral key on the blockchain, they cannot determine which sender created it or reuse it in future analysis. When XMRWallet synchronizes with the Monero blockchain (whether through a remote node or local node connection), the wallet downloads all recent transactions and scans them for outputs belonging to the user. This scanning process is where the view key becomes essential. For each output in every transaction, the wallet uses its private view key to compute the same shared secret that the sender computed. If the shared secret matches, the output belongs to the user’s wallet. This scanning is one-way. The view key allows the wallet to recognize incoming payments without revealing the private spend key. Because the wallet performs this computation locally and the view key never needs to be transmitted, an attacker cannot intercept it during synchronization. XMRWallet’s support for local node connections strengthens this further; if a user operates their own Monero node on their network, the wallet queries only that node and never exposes its transaction interests to a remote service. Once the wallet recognizes an output as belonging to the user, it derives the corresponding private key from the stealth address using the spend key. This private key can be used to prove ownership and spend the output in a future transaction. From the user’s perspective, the transaction history shows receiving funds to what appears to be the same address repeatedly—but on the actual blockchain, each payment went to a different stealth address. An observer analyzing the chain sees random addresses with no visible connection. XMRWallet allows users to manage multiple addresses through the subaddress feature. A subaddress is not a separate wallet; it is a deterministic variant derived from the primary keys. Users can generate a subaddress for each merchant, client, or context without exposing that they all belong to the same wallet. Each subaddress is computed from a different index applied to the primary keys, so multiple subaddresses produce stealth addresses that appear completely unrelated on the blockchain. This is particularly useful for separating payment contexts. A freelancer could give one subaddress to Client A and a different subaddress to Client B. When Client A transfers funds, the wallet recognizes the stealth address and associates it with Subaddress 1. When Client B transfers funds, the wallet recognizes that stealth address and associates it with Subaddress 2. Observers on the blockchain see two completely different addresses and cannot determine that they belong to the same entity. From the freelancer’s perspective, XMRWallet’s address management interface shows organized receiving records without mixing payment sources. Subaddresses also reduce address reuse pressure. Instead of giving the same published address to many parties and then worrying about transaction linkage, the user can hand out different subaddresses. Each subaddress derives its own set of stealth addresses as senders initiate transactions. The primary address remains largely unused except as a backup or for viewing the full wallet balance. This architectural choice demonstrates how Monero’s privacy properties persist even when multiple receiving destinations are in use. A fundamental design choice in XMRWallet is that the private view key stays on the user’s device. The wallet never transmits this key to remote nodes, backup services, or external observers. This contrasts sharply with wallet designs that export view keys to centralized servers to enable lightweight synchronization. While a view-key-only connection is less powerful than possession of the spend key (the view key cannot authorize spending), it still reveals transaction patterns to the service. By keeping the view key local, XMRWallet forces the wallet to download the entire Monero blockchain (or a recent portion of it) and scan it locally. This is computationally more expensive than querying a server, but it preserves a critical privacy boundary. The remote node (whether it is your own node or a public node) cannot determine which outputs belong to the user. From the node’s perspective, all scanning requests come from a wallet, but the actual matching occurs on the device side. XMRWallet’s support for custom node connections enhances this further. A user who runs a local Monero node can configure the wallet to synchronize exclusively with that node. The wallet never reveals its transaction interests to any external service. If a user must use a remote node, the wallet client still performs the output matching locally; the remote node simply provides the blockchain data without learning what the wallet is looking for. Because all keys are derived from the 25-word recovery seed using a deterministic process, losing the seed is catastrophic. There are no password resets, no account recovery procedures, and no fallback authentication. This is not a limitation; it is an intentional security model. The absence of centralized account storage means there are no databases to hack, no support tickets to exploit, and no administrative override that could grant unauthorized access to funds. The user’s sole responsibility is protecting the recovery seed. If the seed is compromised—stolen, photographed, or written in an unencrypted file—an attacker can derive all keys and spend all funds. If the seed is lost and no backup exists, the user cannot recover the wallet. XMRWallet official site emphasizes this responsibility clearly: the wallet does not hold your funds, and the wallet does not have access to your recovery phrase. You alone control it. This model also prevents the wallet developers from imposing restrictions. If the code were to include a backdoor, a spending limit, or a forced withdrawal, it would require the developers’ private keys or a central enforcement point. Neither exists. The wallet software is open to inspection; the cryptography is published. A user can audit the code, compile it themselves, and run it offline if desired. The stealth address mechanism and key derivation process do not depend on trusting the wallet developers—they depend on trusting the underlying Monero protocol, which has been peer-reviewed and refined over years. Stealth addresses solve the address linkage problem, but they do not erase all privacy boundaries. Monero also implements ring signatures and RingCT to obscure inputs and amounts, but each privacy mechanism has limits. Ring signatures have a finite size, which affects anonymity set quality. RingCT is effective, but the fee structure and output denomination patterns can leak information under analysis. These are protocol-level considerations that wallet software cannot override. At the wallet level, user behavior matters. If a user receives funds to a stealth address and then immediately consolidates them into a single transaction, linking that consolidation to the original receive is possible through timing and amount observation. If a user receives at one monero transaction address and spends from another address immediately, the temporal correlation might suggest the same entity. Monero provides strong baseline privacy, but exceptional operational security requires thought about transaction timing, consolidation patterns, and how frequently addresses are used. The synchronization method also influences privacy. If a user configures XMRWallet to use a public remote node, that node cannot see which outputs belong to the user (because scanning happens locally), but it can observe that the wallet is connecting regularly and requesting blockchain data. An observer at the network level might infer wallet activity from connection patterns. Using a local node, a VPN, or Tor connection during synchronization raises the cost of that inference. These are complementary protections; stealth addresses eliminate ledger-level linking, while network privacy reduces traffic analysis. No. When a sender uses your published address, they generate a unique stealth address for each payment. These stealth addresses appear on the blockchain as random values unconnected to your published address or to each other. Only you (using your private view key) can recognize that incoming stealth addresses belong to your wallet. External observers, including blockchain analysts and the nodes you connect to, cannot link multiple payments to a single recipient. Keeping the view key local ensures that remote nodes cannot determine which outputs belong to your wallet. Even though the view key cannot authorize spending, it reveals transaction patterns to any service that holds it. By scanning the blockchain on your device, XMRWallet preserves this privacy boundary. Remote nodes provide blockchain data; your device performs the matching. This is computationally more expensive but provides stronger privacy guarantees. Your funds cannot be recovered. XMRWallet does not store passwords, recovery codes, or backup seeds on central servers. The recovery seed is the sole cryptographic proof of ownership; there is no alternative authentication method. This design eliminates account takeover attacks and centralized attack surfaces, but it makes seed backup essential. Store your recovery phrase offline, in multiple secure locations, and never type it into any device connected to the internet except during wallet restoration.Stealth address derivation: Sender-side computation
Stealth address recognition: Recipient-side decryption
Address management and subaddress support
Why the private view key remains on device
The role of key derivation in account security
Privacy limits and operational discipline
Frequently asked questions
Can someone track my payments if I publish my Monero address in XMRWallet?
Why does XMRWallet keep the private view key on my device instead of sending it to a server?
What happens if I lose my 25-word recovery seed?