Understanding Stealth Addresses: How XMRWallet Protects Your Monero Receiving Address

A user receives payment in Monero and wants a fresh address for each transaction, but not because they are paranoid. On most blockchains, a public address that appears in multiple transactions becomes a link in a transaction graph; observers can begin to cluster payments together and infer spending patterns. Monero solves this through stealth addresses, a cryptographic mechanism that generates a unique, one-time address for each incoming transaction without requiring the sender to know or coordinate with the receiver beforehand. The receiver’s actual address never appears on the public ledger. Instead, only the receiver can recognize and claim the funds using their private view key and spend key.

XMRWallet implements this system on the client side, meaning users retain complete control over the stealth address generation process and the keys needed to receive and spend Monero. The wallet does not manage addresses on a server, does not hold private keys, and does not create a record linking a user’s identity to their receiving activity. Understanding how stealth addresses work, and how monero wallet architecture supports this privacy guarantee, clarifies why Monero transactions are far more resistant to address clustering and external monitoring than Bitcoin or Ethereum transactions.

The problem stealth addresses solve

Public blockchains create a permanent record of every transaction. Bitcoin’s and Ethereum’s designs require that each payment be traceable to a specific address or account, and that address persists across multiple transactions. This creates an opportunity for address clustering: if a user receives multiple payments to the same address, any observer can link those payments together and begin to build a profile of their receiving activity. Even if the user’s identity is not immediately known, the cluster itself becomes a trackable entity.

Monero’s approach is fundamentally different. Instead of reusing a single address for multiple payments, Monero generates a unique stealth address for each incoming transaction. The process requires the sender to know only the recipient’s public address (sometimes called the “main address” or “primary address”). Using a combination of elliptic-curve cryptography and a hash function, the sender derives a one-time address from the recipient’s public key, adds a random value, and hashes the result to create the address where the payment will land on the blockchain. The recipient, holding the corresponding private keys, can use their private view key to scan the blockchain and identify which transactions belong to them, then recover the corresponding private spend key to authorize a payment to that address.

This architecture breaks the link between the recipient’s published address and the actual receiving addresses on the ledger. A user can publish a single receiving address on their website, in an invoice, or in a contact profile, and still receive many payments without creating a public record that says “this address belongs to the same entity.” Each on-chain receiving address is a one-time stealth address that only the recipient can recognize. An external observer sees only individual addresses with no obvious relationship to each other.

The privacy benefit extends beyond simple address clustering. Because the receiving address cannot be predicted before the transaction is created, a third party cannot pre-compute a list of likely receiving addresses for a known entity. The recipient cannot accidentally receive two payments to the same stealth address unless the sender happens to derive the identical address twice, which is cryptographically improbable. This means that the default behavior of Monero transactions is to create new addresses for each payment, without requiring the recipient to do anything special.

How XMRWallet generates and manages stealth addresses

XMRWallet operates as a non-custodial application, meaning that the wallet generates all keys and addresses locally on the user’s device and does not transmit them to any server. When a user creates a Monero wallet in XMRWallet, the application generates a cryptographic seed using entropy from the device. From this seed, the wallet derives the user’s primary spend key and primary view key. The primary address is then computed from the public versions of these keys.

When the user wants to receive a payment, they provide their primary address to the sender. The sender’s wallet or application (whether it is XMRWallet or any other compatible Monero wallet) uses the recipient’s primary address to perform the stealth address derivation. The sender computes a one-time output key from the recipient’s public spend key and a randomly generated ephemeral key, then encrypts the ephemeral key in the transaction. The result is a stealth address where the funds are locked.

On the receiving side, XMRWallet uses the user’s private view key to scan incoming transactions on the Monero blockchain. For each transaction output on the chain, the wallet attempts to decrypt the ephemeral key. If decryption succeeds, the wallet can derive the corresponding private spend key for that output and recognize the funds as belonging to the user. This scanning process happens locally; XMRWallet does not query a server to ask “do these outputs belong to me?” The wallet maintains complete cryptographic independence in deciding which outputs it can spend.

The wallet also supports subaddresses, a related but distinct feature that generates multiple distinct receiving addresses from a single wallet seed. Unlike stealth addresses, which are automatic and one-time, subaddresses are static addresses derived from the primary seed using an index number. A user might generate subaddress 0 for personal transfers, subaddress 1 for invoicing, and subaddress 2 for donations. Each subaddress is a separate receiving destination on the Monero ledger, but all of them are derived from and controlled by the same primary seed. Subaddresses provide organizational privacy—allowing a user to compartmentalize receiving contexts—without replacing the stealth address mechanism. When someone sends to a subaddress, the transaction itself still uses a stealth address for final settlement.

The cryptographic mechanisms underlying stealth address privacy

Monero’s stealth address system depends on several cryptographic building blocks. The primary operation is based on the elliptic-curve Diffie-Hellman (ECDH) key agreement protocol. When a sender creates a transaction, they generate an ephemeral keypair. They then combine the recipient’s public spend key with the private ephemeral key to produce a shared secret. This shared secret is hashed and combined with the recipient’s public spend key to create the actual receiving address. The ephemeral public key is embedded in the transaction, encrypted with information that only the recipient can decrypt.

The recipient, holding the private view key corresponding to the recipient’s public spend key, can replicate the ECDH computation using the ephemeral key from the transaction. If the computation succeeds, the recipient derives the same shared secret and can hash it to recover the private spend key for that output. This asymmetry—only the holder of the private view key can recognize outputs—is what makes stealth addresses work. A public observer can see all the outputs on the blockchain but cannot determine which ones belong to any specific entity.

Ring signatures and confidential transactions complement stealth addresses to complete Monero’s privacy guarantees. Ring signatures ensure that an observer cannot tell which input in a transaction actually authorized the payment; the transaction includes a ring of potential signers, and only the actual signer knows which one they are. Confidential transactions (or more precisely, RingCT in Monero) hide the amounts being transferred. Together, these mechanisms ensure that stealth addresses solve only part of the privacy problem—linkability—while ring signatures address untraceability and confidential transactions address amount visibility.

XMRWallet relies on the Monero daemon or a remote node to validate transactions and provide information about the blockchain. The wallet itself cannot modify how stealth addresses, ring signatures, or confidential transactions work; those are protocol-level features. However, XMRWallet’s role is to ensure that it correctly implements the client-side stealth address scanning and key derivation process, and that it does not leak information about which outputs the user is interested in. A monero wallet that queries a server with “check these outputs for me” would compromise privacy even if the underlying protocol uses stealth addresses.

Local scanning and why it matters for privacy

One of the most important privacy decisions in XMRWallet’s design is that address scanning happens locally, not on a remote server. When a user opens the wallet and synchronizes with the blockchain, the wallet downloads the list of outputs from recent blocks, then attempts to decrypt the ephemeral keys using the user’s private view key. This process is entirely client-side; the wallet never asks a server “which of these outputs belong to me?” If it did, the server would learn which outputs the user was checking, even if the server did not know the user’s identity directly.

The trade-off for local scanning is synchronization time. On first use or after a long offline period, the wallet must download and check a large number of blockchain outputs. Modern implementations use optimizations such as subaddress scan hints and output indexing to reduce the computational burden, but even with these improvements, a new Monero wallet user may wait several minutes or hours to fully synchronize and discover all their funds. This is not a performance problem; it is a privacy feature. The time cost is paid once, and the benefit is that no external party has a record of the user’s scanning activity.

XMRWallet offers a view-only mode, which allows users to monitor an account’s balance and incoming transactions without the ability to spend. A view-only wallet is created by providing the primary address and the private view key. An observer with only the private view key can scan and identify incoming transactions but cannot create outgoing transactions because they do not have the private spend key. This mode is useful for auditors, accountants, or settings where a trusted party needs to monitor activity without having spending authority. The privacy model remains intact: the view-only wallet still performs local scanning and does not transmit the view key to any server.

The implication is that a user’s synchronization behavior, their balance inquiries, or any metadata about when they access the wallet are not recorded by XMRWallet or its servers. This is in stark contrast to non-private blockchains where a wallet service can observe every balance check and correlate it with wallet activity. In Monero, the default expectation is that such monitoring is technically infeasible if the wallet implements local scanning correctly.

Recovery seeds, backup, and ongoing address derivation

XMRWallet uses a recovery seed—typically a 24-word mnemonic phrase—that encodes the root entropy for the wallet. This seed generates the primary spend key and primary view key through a deterministic process. If a user loses their device or needs to restore their wallet on another machine, they can enter the recovery seed into XMRWallet on a new device, and the wallet will re-derive all the same keys and be able to scan the blockchain to recover all their funds and transaction history.

The security of this process depends on the confidentiality of the recovery seed. If an attacker obtains the recovery seed, they can derive all private keys and spend all funds in the wallet. XMRWallet never stores the recovery seed on a server; the user is responsible for writing it down, memorizing it, or storing it in an offline vault. The wallet can display the seed once during creation and allow the user to verify it, but it should not be transmitted to any online service or printed to a log file.

Because all addresses in the wallet are deterministically derived from the primary seed, a user can restore a wallet from seed and recover not only the primary address but also any subaddresses they had previously generated. The stealth addresses themselves are not stored; they are derived on-the-fly as the wallet scans the blockchain. This means that a user’s entire receiving history can be reconstructed from a single seed, without any need for an address book or backup of individual addresses. The tradeoff is that the wallet must re-scan the entire blockchain to rediscover all payments, which can take time on the first restoration.

XMRWallet emphasizes the importance of testing recovery before the seed is needed. Users are encouraged to create a test wallet, write down the seed, delete the wallet application, reinstall it, and use the recovery seed to restore the test wallet. This process confirms that the recovery seed is valid and that the user can perform the restoration procedure under controlled conditions. Without this validation, a user might discover during an emergency that they either cannot remember the seed correctly or have stored it in an inaccessible location.

Comparing stealth addresses to alternatives: pseudonymity versus privacy

Bitcoin and Ethereum transactions are pseudonymous but not truly private. A Bitcoin address is not directly linked to a person’s legal identity, but all transactions to and from that address are visible on the public ledger. If an observer can connect a Bitcoin address to a user through a purchase, exchange deposit, IP address leak, or other side channel, they can then examine all transactions associated with that address and build a complete financial history. Many users have learned this the hard way after purchasing Bitcoin years ago and later realizing that every transaction they made was permanently traceable.

Monero, by contrast, prioritizes privacy by default. Stealth addresses mean that each receiving transaction uses a unique on-chain address that cannot be linked to previous or future transactions from the same wallet. An observer who sees one stealth address cannot predict or recognize the next stealth address belonging to the same wallet. Combined with ring signatures and confidential transactions, Monero transactions resist analysis at the protocol level rather than relying on users to opt into privacy features.

Other privacy-focused cryptocurrencies such as Zcash offer privacy features that users can choose to use, but transactions on the transparent ledger are visible by default. A user must manually shield their coins to hide transaction amounts and participants, and must manage separate addresses for shielded and transparent transactions. Monero’s model is to make privacy automatic and mandatory, so that the default action—sending a transaction—already provides privacy protection without requiring the user to understand cryptographic options or make error-prone choices.

XMRWallet’s role is to preserve Monero’s privacy guarantees at the wallet level by refusing to compromise on the client-side scanning model and ensuring that private keys never leave the user’s device. Some wallet implementations have tried to optimize performance by using a server to perform scanning on behalf of the user, but this introduces a significant privacy leak: the server learns which outputs belong to each user. XMRWallet’s commitment to local scanning means that performance is bounded by the user’s device, but privacy is not traded away for convenience.

Practical considerations for everyday use of stealth addresses

From a user’s perspective, stealth addresses work transparently. When receiving a payment, the user provides their primary address to the sender. They do not need to specify “use a stealth address” or configure any options; Monero’s protocol automatically generates and uses stealth addresses for every transaction. The user sees their balance update, they can inspect transaction details to see amounts and timestamps, and they can copy the transaction hash to look up details on a block explorer. The technical stealth address machinery is invisible, which is by design.

However, there are a few practical scenarios where understanding stealth addresses improves user awareness. If a user imports their wallet into a different Monero application, both implementations must correctly perform stealth address scanning, or the user might miss some of their received funds on first synchronization. If a user’s primary address is shared on a website or in multiple contexts, and they later wonder whether different senders can tell that they are the same recipient, the answer is no—the stealth address mechanism ensures that each sender sees a different receiving address, and a public observer cannot cluster them.

One common misconception is that a user should generate a new primary address for each sender to maximize privacy. This is unnecessary because stealth addresses already provide this benefit. A single primary address can be published once and reused indefinitely; each sender will still derive a unique stealth address, and the recipient will be able to distinguish payments from different sources based on transaction metadata if needed. Generating multiple primary addresses might be useful for organizational reasons (to separate invoicing from donations, for example) but does not provide additional privacy.

Another practical point is that stealth addresses are a sending-side feature; the recipient does not need to do anything to receive them. A user cannot disable stealth addresses in Monero even if they wanted to. All Monero transactions use stealth addresses for receiving addresses. This universality means that Monero users benefit from stealth address privacy without needing to understand the mechanism, similar to how HTTPS encryption works by default for most websites without users having to opt in.

Threats that stealth addresses do not address

Stealth addresses are a powerful tool, but they are not a complete solution to all privacy threats in cryptocurrency. One important limitation is that stealth addresses protect the identity of the recipient at the protocol level, but they do not protect the sender’s identity from the recipient. If someone sends you Monero to a stealth address, you know you received funds, but you do not necessarily know who sent them unless you have side information. Conversely, ring signatures protect the sender’s identity from external observers, but the recipient can still see that they received funds from someone.

Another threat is address reuse at the application level. If a user generates a subaddress and gives it to multiple people, those multiple senders will each derive different stealth addresses, so the payments will not be linked on-chain. However, the user knows that they gave the same subaddress to multiple people, so they know those senders are distinct. If a user later consolidates all those funds by spending them together, an observer might infer that those inputs belonged to the same user. This is not a failure of stealth addresses; it is a limitation of transaction history and the user’s own knowledge of their wallet structure.

Metadata analysis can also threaten privacy. If a user always accesses their wallet at the same time each day, from the same location, and synchronizes with the same Monero node, an observer might infer patterns about their activity. Using Tor or a VPN to mask IP address, running a personal Monero node, and varying access patterns can mitigate these threats. XMRWallet supports custom node configurations and network privacy practices, but the wallet itself cannot eliminate all side-channel risks.

Finally, stealth addresses protect only the receiving side of a transaction. If a user receives Monero via stealth address but then sends it to a regulated exchange or a service that knows their identity, the privacy provided by stealth addresses is effectively nullified downstream. The privacy chain is only as strong as its weakest link; a user must maintain privacy discipline throughout the transaction lifecycle, not only at the point of receiving.