A user receives their first Monero payment through XMRWallet and faces an immediate conceptual problem: the transaction appears on the blockchain, but the sender’s identity and the exact amount are hidden from public view. The wallet shows an incoming balance, yet the mechanism that proves the funds are genuinely theirs—without exposing that fact to the network—remains opaque. The question is not whether the transaction happened, but whether the wallet’s verification process actually confirms that this payment belongs to them and that no one else can spend it.

The answer involves understanding how Monero’s cryptographic architecture differs fundamentally from Bitcoin or Ethereum, where transactions are transparent and verification means confirming that a sender had sufficient balance to transfer a stated amount to a public recipient address. In Monero, verification means something different: proving that a transaction recipient can access funds without revealing either their identity or the transaction amount to observers, including the sender. XMRWallet performs this verification entirely on the user’s device, using private keys that never leave local storage and mathematical proofs that make trust in third parties unnecessary.

How Monero hides the recipient without hiding the funds

Monero transactions do not contain recipient addresses in any form that a network observer can recognize. Instead, they use stealth addresses, a system where the sender generates a unique, one-time destination address for each payment using the recipient’s public spend key and a random one-time key. This means the same wallet can receive multiple payments, each appearing on the blockchain as going to a different address, yet all funds remain accessible only to the person holding the corresponding private spend key.

The critical mathematical property is that the sender can prove they created a valid stealth address without the recipient having to publish a reusable address that links multiple payments to the same identity. The sender performs this calculation: they take the recipient’s published public spend key, mix it with a random number they generated, perform elliptic curve operations to produce a destination address, and include the random component (called the transaction public key) in the transaction data. The recipient, holding their private spend key, can use that public transaction key to reconstruct the exact same destination address and verify that the funds are theirs.

An outside observer sees the transaction public key and the stealth address, but cannot connect them to any published recipient identity because they do not have the private spend key needed to verify the linkage. The sender cannot prove later which address they sent to because the random element makes the calculation unrepeatable. Even the sender cannot spend the funds; only the recipient’s private spend key grants that power. This separation of knowledge—sender knows the transaction occurred but not the recipient’s future spending authority, recipient can verify receipt without revealing to the sender—is what makes the system work without requiring trust.

Private view keys: How you scan the blockchain without revealing yourself

When XMRWallet reconstructs cryptographic keys locally from a recovery seed or encrypted wallet file, it derives two critical secrets: the private spend key and the private view key. The spend key is what authorizes transactions. The view key is what allows the user to identify incoming payments and calculate balances. They are mathematically linked, but their functions are distinct, and that distinction enables a powerful privacy feature.

The private view key lets the wallet scan every transaction on the Monero blockchain and test whether each stealth address was created for this wallet. The wallet performs this test locally: for each transaction, it retrieves the transaction public key, combines it with the private view key through elliptic curve mathematics, and checks whether the resulting address matches an address in the transaction. If it matches, the funds belong to this wallet. If it does not match, the wallet moves to the next transaction. This scanning process reveals no information to the network because it happens entirely on the user’s device.

The XMRWallet wallet supports both local node connections and remote node connections. A local node gives the user the full blockchain and provides maximum verification independence; the wallet can scan every transaction without asking any third party which transactions might be relevant. A remote node connection, conversely, means the wallet sends fewer transaction details to a remote Monero node, potentially reducing the information disclosed about which specific transactions it is interested in. Neither approach reveals to the remote node which addresses the wallet is monitoring, because the scanning logic runs locally with the private view key, which never leaves the device.

Some implementations can optionally allow sharing the view key with a trusted third party for non-custodial monitoring, but this is a user choice, not a requirement. If a user shares the view key, that party can see incoming transactions and balances, but cannot spend the funds or derive the private spend key. This is useful for accountants, custodians, or auditors, but it trades some privacy for transparency in specific relationships. The default is not to share; the wallet assumes users want full privacy unless they explicitly delegate view-only access.

Why ring signatures prove a transaction is valid without proving who sent it

When a user sends Monero through XMRWallet, the wallet must create a signature proving it has authorization to spend the selected outputs without revealing which outputs in the blockchain are being spent. Monero uses ring signatures to achieve this. A ring signature works by combining the actual signing key with a ring of decoys: the wallet includes the real output being spent, then selects other outputs from the blockchain at random and includes them in a mathematical structure that proves one member of the ring is being spent without revealing which one.

From the network’s perspective, an observer sees that a transaction has been authorized by someone with control over one of several possible outputs, but which output is being spent remains cryptographically hidden. The ring size (the number of outputs in the decoy set) determines the ambiguity. A larger ring makes it harder to guess which output is real, but it also makes the transaction larger and more expensive. XMRWallet handles this calculation automatically, selecting an appropriate ring size based on network policy and the user’s preferences, but the user retains control over verification: their private spend key is the only authority that can unlock the funds in the first place.

The security of ring signatures depends on the assumption that the decoy outputs are selected from the actual blockchain history without bias. If outputs were selected in a predictable or recent pattern, an observer might be able to use statistical analysis to guess which output is real. Monero mitigates this through enforced decoy age and random selection rules. XMRWallet implements these rules locally when constructing transactions, ensuring that the signature pattern does not accidentally weaken privacy. The wallet also signs the entire transaction to prevent modification, so the ring structure cannot be altered after the fact by a network observer or intermediary.

Confidential transactions: Why amounts stay hidden

A ring signature hides which output is being spent, but on older cryptocurrencies, the transaction amount would remain visible. Monero hides amounts using confidential transactions, a commitment scheme where the actual amount is replaced with a cryptographic commitment that proves the sender did not create money out of thin air or double-spend. The commitment itself reveals no information about the actual number of coins.

The wallet constructs this commitment as part of the transaction signing process. It includes a random blinding factor, multiplies it by a curve point, combines it with the amount multiplied by a different curve point, and produces a value that is mathematically linked to the real amount without revealing it. To verify that a commitment is valid, the network checks a zero-knowledge proof called a Bulletproof, which confirms that the committed amount is between zero and the maximum supply without disclosing the actual value. The user’s XMRWallet verifies these proofs locally before broadcasting, ensuring that the transaction is correctly formed.

The combination of stealth addresses, ring signatures, and confidential transactions means that a Monero transaction reveals almost nothing: the sender is hidden in a ring of decoys, the recipient is hidden by stealth addressing, and the amount is hidden by a cryptographic commitment. A network observer can only confirm that a valid transaction was created by someone with cryptographic authority to move funds, that the transaction did not violate the money supply rules, and that the recipient will be able to recognize and spend the funds. Everything else—who sent it, who received it, how much was sent—remains private unless the parties themselves choose to disclose it.

How XMRWallet verifies you own incoming funds without trusting the sender

When XMRWallet receives a payment, the verification process is entirely mathematical and requires no trust in the sender or any third party. The wallet scans the blockchain, identifies a stealth address that was created using its public spend key, retrieves the transaction public key from the transaction data, and performs the stealth address recovery calculation. If the recovered address matches the stealth address in the transaction, the wallet is mathematically certain that this transaction was created for this wallet and no other.

The wallet then derives the private key needed to spend these funds. This key is computed from the transaction’s public key and the wallet’s private spend key through a deterministic calculation. The result is a key that is unique to this output and is mathematically linked to no other output in the blockchain. Only this wallet can perform this calculation because only this wallet holds the private spend key. The sender cannot derive this key; they do not have the necessary secret.

Verification also means confirming that the transaction structure is valid and that the amount claimed is correctly committed. The wallet checks the Bulletproof range proof to ensure that the committed amount is a valid monetary value. It verifies that the ring signature structure is correctly formed and that the transaction has not been modified since creation. All these checks happen on the user’s device, using only information the user controls: their recovery seed or encrypted wallet file, their private keys, and the blockchain data synchronized from a Monero node.

This design means you do not need to trust the sender to know that the funds are truly yours. The sender cannot later claim they did not send the payment, cannot spend the funds themselves, and cannot redirect the transaction to a different address. The sender also cannot see your address, your balance, your other transactions, or your future spending patterns. You have cryptographic proof of receipt without exposing any of those details to them. The transaction is immutable on the blockchain, but its privacy-relevant contents—who sent it, who received it, how much—are visible only to parties who hold the necessary private keys.

Local key derivation: Why server-side storage would break the entire system

The reason XMRWallet is non-custodial is not simply a matter of company policy or marketing positioning. It is because storing private keys on a server would make the entire privacy system collapse. If the private spend key were held server-side, the server would become the effective owner of the funds, capable of signing any transaction. If the private view key were stored server-side, the server would be able to scan the blockchain and identify all incoming transactions, seeing the user’s balance and transaction history. Neither of these outcomes is compatible with the cryptographic privacy that Monero provides.

XMRWallet reconstructs both keys locally from the user’s recovery seed or encrypted wallet file every time the user logs in. The login process takes the information the user provides—either a 25-word seed or an encrypted file with password—and derives the keys through deterministic cryptographic operations that produce the same keys every time, provided the input is unchanged. This means users can restore their entire wallet on different devices, using different software that implements the same algorithm, and receive the same funds. The keys are never created or stored by the server; they exist only in the user’s memory or device storage.

The wallet does synchronize blockchain data with a Monero node to retrieve the transactions needed for scanning and to broadcast outgoing transactions. That synchronization reveals some metadata: the node may observe when the wallet connects, how often it synchronizes, and approximate transaction volume. But it does not reveal the private keys, the user’s identity, or the specific transactions the wallet is interested in, because the scanning and verification happen locally. A local node connection further reduces this metadata leakage by eliminating any remote service that could correlate multiple connections.

What an attacker or malicious node cannot do

A malicious node operator cannot forge a transaction in your name because they do not have your private spend key. They cannot prevent you from receiving funds because they cannot control whether stealth addresses created by other senders will include your wallet’s public key. They cannot identify which transactions are yours because scanning happens locally with your private view key. They cannot see your balance or history without the view key, and even if you shared that key for transparency, they cannot spend the funds.

A compromised computer or device running XMRWallet is a different threat. Malware with access to the device’s memory could potentially steal the private keys during the login process or while the wallet is active. This is why XMRWallet implements local security practices: automatic session expiration, recommendations to avoid using public devices, advice to clear local data after use, and the option to use encrypted wallet files with strong passwords. These practices do not solve the malware problem entirely, but they reduce the window of opportunity and limit the amount of data that persists after use.

An important non-threat is the sender. The sender can prove they created a transaction that resulted in a stealth address, but they cannot prove they sent it to any particular person. They cannot spend the funds, cannot modify the transaction after broadcast, and cannot see whether the recipient has moved the funds. If you received a payment and then spent it immediately, the sender would know a transaction occurred but would have no way to confirm the recipient’s actions. Privacy is bidirectional in Monero: the sender’s identity is hidden from observers, but the recipient’s future activity is also hidden from the sender.

Why “zero-knowledge” is the right term, but only for specific operations

The term “zero-knowledge proof” sometimes gets applied loosely to any system with strong privacy, but in Monero’s architecture it has a precise meaning: the Bulletproof range proof is a zero-knowledge proof of the committed amount’s validity. The proof mathematically demonstrates that the amount is within a valid range without revealing the actual value. No information about the amount leaks, no additional assumptions are required, and the proof is verifiable by anyone with the transaction data.

The stealth address system is not a zero-knowledge proof in the formal sense; it is a privacy-preserving address scheme where the sender proves nothing to the network except that they created a valid cryptographic object. The ring signature similarly is not zero-knowledge in the formal definition; it proves that one member of a set can authorize a transaction without revealing which member. These are privacy-preserving cryptographic techniques, but they operate differently from formal zero-knowledge proofs.

The practical result, however, is equivalent for the user: when you receive Monero through XMRWallet, you gain cryptographic certainty that the funds are yours, that they can be spent only with your private spend key, and that no one else can prove whether you received them or what you do with them afterward. You verify this using locally-held secrets without trusting the sender, the network, or the wallet provider. The mathematics is sound because it does not rely on any trusted third party maintaining integrity or secrecy; it relies only on the computational hardness of solving discrete logarithms and the proper implementation of the algorithms themselves.