How Monero Privacy Works: Stealth Addresses, RingCT, and Its Limits

Introduction to Monero, part 2 of 3. 1. Fundamentals · 2. Privacy · 3. Wallets and nodes

An ordinary Monero payment publishes enough information for nodes to verify it without publishing the recipient's reusable address or transfer amount. It also obscures which earlier output was spent. Those protections come from several mechanisms with different jobs.

This second part follows the cryptography behind the payment introduced in part one. It explains what each mechanism proves, what an observer still sees and where devices, network connections and outside records can defeat privacy. The deployed protocol baseline is Monero v0.18.5.4, reviewed November 8, 2026.

The privacy mechanisms inside a transaction

Stealth addresses: receiving without publishing your wallet address

A Monero receiving address can be shared with someone who wants to pay you. It contains public keys. For each payment, the sender uses those keys and fresh transaction secret information to derive a one-time output key. That derived key appears on the blockchain instead of the reusable receiving address.

Bob's wallet can reproduce the relevant shared-secret calculation using his private view key and the transaction's public data. It tests whether the output belongs to him. An observer with only Bob's public address cannot perform the same private scan and list his receipts. Bob later derives the spending key for the output using his wallet's spending secrets.

The term stealth address describes this one-time destination mechanism. It does not mean Bob's advertised address is itself secret. If he gives the same address to two companies, those companies can compare their records and recognize the shared identifier. Nor does it stop Alice knowing which address she paid. Use separate subaddresses when it is useful to separate relationships.

The standard-address specification explains the two public keys, and Moneropedia's stealth-address entry explains their use in payments.

Ring signatures: hiding which earlier output was spent

A normal current Monero input references a ring of sixteen outputs: one that the wallet spends and fifteen decoys selected from eligible blockchain outputs. The ring lists possible spent outputs. Owners of decoy outputs neither sign this transaction nor lose money because their outputs were selected.

The wallet creates a CLSAG signature, the deployed ring-signature construction, that demonstrates the required ownership and commitment relationships without identifying the real member. A verifier can check the proof against the ring. It cannot simply extract a public pointer to Alice's actual input.

The sixteen members need not be equally plausible candidates. If an analyst has evidence excluding some members, the remaining candidates become more informative. Historical transactions used different ring sizes and selection methods. Information exposed by old behavior can still matter when analyzing history.

Decoy selection matters alongside the nominal ring size. A wallet tries to choose plausible decoys, including their ages. A badly chosen set can make the real spend stand out statistically even when the signature is mathematically valid. Ring signatures do not conceal the network connection used to broadcast, the sender's invoice or a compromised device's activity. See the CLSAG research and the deployed RingCT signature code.

RingCT: checking the arithmetic without exposing the amounts

Ring Confidential Transactions, or RingCT, combine hidden-amount accounting with spending proofs. Instead of publishing an ordinary output's amount, the transaction publishes a cryptographic commitment to it. A Pedersen commitment combines the amount with a random secret called a blinding factor.

A useful analogy is an amount sealed inside an envelope whose exterior can participate in an arithmetic check. The analogy stops at the cryptography. These are mathematical objects, not encrypted decimal numbers that every validating node can decrypt.

Commitments have an additive relationship. The protocol uses that relationship, along with the other proofs, to verify that committed inputs balance committed outputs plus the public fee. The verifier need not learn each underlying amount. The spender cannot legitimately create extra value merely by declaring an arbitrary change amount.

Balance alone is insufficient. In ordinary arithmetic, allowing negative values could make a fraudulent equation balance. Monero also requires range proofs showing that output amounts lie within the permitted nonnegative range. The commitment hides the value, the range proof constrains it, and the balance check relates the amounts. Those are separate tasks.

RingCT does not hide the whole transaction. Its fee, one-time output keys, key images, ring references and proof bytes remain public. The payer knows what they sent and the recipient knows what they received. Hidden amounts also make verification more technically demanding than adding publicly visible values. Security depends on the cryptographic assumptions and correct implementation of the proofs. The current RingCT code is the implementation reference, while Zero to Monero gives mathematical background that predates CLSAG and Bulletproofs+.

Bulletproofs and Bulletproofs+: smaller range proofs

Early RingCT transactions used Borromean range proofs. Bulletproofs reduced the space those proofs occupied. Bulletproofs+ refined the construction further and is used for current ordinary Monero transactions in the reviewed stable implementation. These improvements reduce the data needed to prove that amounts are in range, which helps transaction storage and transmission.

A range proof is not a proof that a buyer received the promised goods. It also does not identify the sender or hide their IP address. Its job is narrower: establish a property of hidden numbers without disclosing those numbers. Wallets construct the proof and nodes verify it. The Moneropedia overview, Bulletproofs+ paper and detailed glossary page cover the distinction.

Key images: detecting a second spend

If the network cannot see which ring member Alice spent, how can it reject a second spend of the same output? Each input publishes a key image derived from the actual output and its spending secret. The signature ties that image to the authorized spend.

Spending the same output again would produce the same key image, even if the wallet chose different decoys. Nodes check whether it has already appeared in the accepted chain. A conflicting second spend is invalid. Publicly recognizing that a spend is repeated does not require publicly naming the output that was spent.

A key image is a deliberately linkable marker, not a private key and not a general identifier for a person's whole wallet. Publishing wallet key images can disclose which outputs have been spent to someone who already knows those outputs belong to you. That is why view-only tools treat key-image import as a disclosure with a specific purpose. See the key-image specification.

View keys and spend keys: different kinds of access

A conventional Monero wallet has a private view key and a private spend key. The private view key lets the wallet identify incoming outputs and recover their amounts. The private spend key supplies the authority needed to spend, together with the rest of the wallet's key derivation.

Giving an accountant suitable view-only wallet information can let them observe receipts without being able to authorize payments. That access still reveals sensitive financial information. Share it only when you intend to disclose those receipts.

View-only access alone does not reliably reconstruct all outgoing activity or an accurate unspent balance. A view-only wallet cannot derive all spending key images from its view key. Importing key images helps it identify spent outputs, while payment destinations and other wallet metadata can require separate records. Access to subaddress-derived receipts also depends on the wallet knowing or scanning the relevant subaddress indices.

A recovery seed generally restores the secrets needed for full control of the wallet, not merely its view. Anyone asking for your seed to "verify" a payment is asking for much more access than a payment check needs. Our offline-wallet guide explains how viewing and spending can be separated across devices.

Dandelion++: obscuring the first broadcast

On a peer-to-peer network, an observer can record which computer first relayed a transaction to it. That can reveal information even if the transaction's cryptography is sound. Dandelion++ initially passes transactions along a narrow stem path, then distributes them more widely in a fluff phase. The first peer an observer hears from may be a relay rather than the transaction's creator.

The stem phase makes the first broadcast harder to attribute under the protocol's threat model. Dandelion++ does not encrypt IP addresses or replace Tor or I2P. An adversary controlling peers, observing network traffic or exploiting implementation behavior may learn more. The implementation announcement describes the intended protection.

At the November 8 review, issue #11690 reported a possible way to infer non-broadcast transaction-pool membership from connection handling. Its author explicitly described a code-path analysis without a running-network reproduction. That is not proof of real-world deanonymization. Our report on the investigation separates the source findings from what remains unverified.

Fees and other public metadata

A Monero fee is visible on the blockchain. Block reward issuance is public too. The block's coinbase transaction has different amount rules from ordinary RingCT transfers. It is generally based on transaction weight and a fee rate, with wallet priority and current conditions affecting the estimate. It is not a fixed percentage of the amount sent. Spending many small outputs can make a transaction heavier than spending one larger output. Use the wallet's current estimate rather than a fee copied from an old guide.

Observers can also see the transaction identifier, its encoded size and weight-related structure, ring references, output count, key images, public transaction data and the block containing it. A node may record when it first received the transaction. Block timestamps and network observations are different kinds of evidence, with different precision and trust assumptions.

The normal privacy mechanisms conceal specific relationships and values within this public structure. They do not make the existence of a transaction secret. Transaction weight and fee estimates explain why the amount and the fee need not move together.

Privacy limits: decide who you need protection from

A threat model identifies who might observe or attack you, what they can access and what you want to keep private. Hiding a purchase from a casual blockchain reader is a different problem from protecting a compromised phone or resisting an observer with extensive network visibility.

The protocol cannot protect every part of a payment. These exposures need separate attention.

Your device can reveal everything you type or view. Malware can read a software wallet, replace a destination address, record a seed or capture transaction details before cryptographic privacy mechanisms matter. A PIN or wallet password is only one part of device security. Keep the operating system and wallet updated, and avoid installing untrusted tools beside funds you cannot afford to lose.

Connections leave evidence. A public node may observe your source IP and requests. An internet provider can observe some connection metadata. Tor, I2P and Dandelion++ address different pieces of this problem, with different assumptions. They do not turn a hostile operating system into a trusted one or guarantee protection from a global observer.

Counterparties keep records. An exchange may keep identity verification, deposit and withdrawal records. A merchant may keep a name, delivery address, invoice and payment time. Monero does not delete those records. Know Your Customer checks can associate activity with an identity even when the public blockchain does not supply a complete spending graph.

Timing and behavior can narrow possibilities. A distinctive sequence of actions may correlate across services or network observations. Amount confidentiality and decoys reduce information available on chain, but someone with other observations may still make useful inferences. A claim that a company can "trace Monero" needs a stated method, evidence and limits. A claimed attribution is not automatically a deterministic proof, and dismissing every attribution as impossible would also be unjustified.

Ring privacy has finite candidates and historical baggage. Analysts may rule out decoys using outside knowledge or infer likely spends from patterns. Current rules cannot retroactively erase disclosures made by older wallets, earlier transaction formats or users themselves. Ring size is one parameter in this problem, not a percentage anonymity guarantee.

You can disclose payment information yourself. Publicly posting a reusable address links it to that public identity. Sharing a view key can expose receipts. Payment proofs and transaction secrets can reveal a payment relationship. Local wallet metadata may contain recipient addresses, labels and notes that do not appear on chain. Backups need protection too.

Match your precautions to those exposures. Protect the seed and device first, then consider what the node operator and payment counterparty can observe.

Research and future upgrades

Monero's privacy design continues to change through research, review, implementation and network coordination. FCMP++, short for Full-Chain Membership Proofs with spend authorization and linkability, aims to replace small-ring membership with proofs over a much larger eligible set. That would change the assumptions behind the ring-size discussion in this article.

At this review, the stable release examined here still uses the deployed CLSAG and Bulletproofs+ transaction rules. The project's roadmap lists full-chain membership proofs as upcoming work. Some implementation components have already merged, including Rust integration work. A merged component is not evidence that mainnet has activated a new transaction format. This guide does not assign a launch date or present FCMP++ as a live feature.

Research also addresses proof efficiency, wallet scanning and usability, network privacy and mining. Smaller proofs reduce some costs but do not remove storage and verification requirements. More convenient wallet recovery must preserve clear security boundaries. Decentralized mining needs usable software and operator participation as well as a suitable proof-of-work algorithm.

For changes that affect your funds, follow stable release notes and explicit network-upgrade instructions. Do not install a research branch merely because its proposal promises stronger privacy. The Monero Research Lab and source repository make the research and implementation available for examination.

Continue with part three: wallets, nodes and a first transaction.