Monero Privacy Explained: Ring Signatures, Stealth Addresses, and RingCT

Introduction

Most people know that Monero is private by default. Fewer understand how that privacy is achieved, why three separate mechanisms are necessary, or where each one's limits lie. This article answers those questions without requiring a mathematics degree.

Monero's privacy architecture rests on three cryptographic layers, each targeting a different piece of information that a public blockchain would otherwise expose:

• Ring signatures — hide which output is actually being spent (sender ambiguity)
• Stealth addresses — prevent linking an on-chain output to a known recipient address
• RingCT (Ring Confidential Transactions) — conceal transaction amounts while preserving network verifiability

A fourth mechanism, Dandelion++, operates at the network layer to obscure which IP address first broadcast a transaction. It is covered separately because it sits outside the on-chain protocol.

These mechanisms are not redundant. Each one closes a privacy gap that the others leave open. Removing any one of them would allow a different category of surveillance. Understanding how they interlock helps you use Monero intelligently and understand its actual limits.

The Three Surveillance Problems a Public Blockchain Creates

On Bitcoin or any transparent blockchain, every transaction records three facts permanently and publicly: the sending address, the receiving address, and the amount. This enables address clustering, wealth estimation, payment tracking, and ultimately identity linkage when any address is associated with a real identity — through an exchange KYC, a merchant, or a public donation address.

Monero's design addresses each of the three leaks independently, because a solution to one does not automatically solve the others. You could hide amounts and still have a fully traceable transaction graph. You could obscure the sender and still expose the recipient through address reuse. The three layers are necessary precisely because the three surveillance risks are orthogonal.

Layer 1: Ring Signatures — Hiding the Sender

What a ring signature is

A ring signature is a cryptographic signature scheme in which a signer can prove they are a member of a group without revealing which specific member they are. The "ring" is the group of possible signers. Any member of the ring could have produced the signature, and no observer can determine which one actually did.

In Monero, the ring is not a group of users — it is a group of transaction outputs already on the blockchain. When you spend Monero, your real output (the one you own) is mixed with a set of other outputs drawn from the blockchain history. These other outputs are called decoys. The ring signature proves that whoever made the transaction controls one of the outputs in the ring, without specifying which one.

How ring members are selected

Decoy outputs are selected by the wallet software using a statistical algorithm that mirrors the natural age distribution of how outputs are typically spent on the network. This prevents naive attacks where an analyst could rule out obviously old or obviously new outputs as implausible decoys. As of the current protocol, every transaction input uses a ring size of 16 — meaning 1 real output and 15 decoys.

What ring signatures protect and what they do not

Ring signatures provide plausible deniability about which output is being spent. An outside observer can see that one of the 16 outputs in a ring was spent, but not which one. This prevents reliable transaction graph analysis: you cannot trace which wallet controls which funds simply by following the on-chain flow.

However, ring signatures do not hide the amount of the output being spent (that is RingCT's job), nor do they hide where the funds are being sent (that is stealth addresses' job). They also do not protect against statistical analysis if the entire blockchain is flooded with outputs controlled by one attacker — though this is expensive and impractical at scale.

MLSAG and CLSAG: the signature schemes

Monero originally used a ring signature scheme called MLSAG (Multilayered Linkable Spontaneous Anonymous Group signatures). Since October 2020, Monero uses CLSAG (Compact Linkable Spontaneous Anonymous Group signatures), which produces smaller transactions and verifies faster while maintaining the same privacy properties. The upgrade reduced the average transaction size by roughly 25%.

Key images: preventing double spends

Because a ring signature hides which output was spent, the network faces a challenge: how can it prevent someone from spending the same output twice without knowing which output it is? Monero solves this with key images. Each output, when spent, produces a unique key image derived from its private key. The network records all key images and rejects any transaction that includes a key image already seen. This prevents double-spending while preserving sender ambiguity — the key image proves uniqueness without revealing identity.

FCMP++: the planned successor

Ongoing research in the Monero community targets a replacement for ring signatures called FCMP++ (Full-Chain Membership Proofs). Instead of selecting a fixed-size ring of decoys, FCMP++ would allow a transaction to prove membership across the entire set of unspent outputs on the blockchain, dramatically increasing the anonymity set and eliminating the statistical weaknesses inherent in small rings. This upgrade is under active development and is expected to arrive in a future hard fork.

Layer 2: Stealth Addresses — Hiding the Recipient

The recipient privacy problem

On a transparent blockchain, if you publish a receiving address, anyone can observe the blockchain and see every payment sent to that address. Even if the sender is unknown, the recipient is permanently exposed. A salary payment, a donation, or a purchase can be correlated with a real identity the moment the address is linked to a person — which happens routinely through exchanges, merchants, and public profiles.

How stealth addresses work

Monero's stealth address protocol ensures that the address you share publicly — your wallet address — is never written to the blockchain. Instead, the sender uses your public spend key and public view key (both embedded in your address) to generate a unique, one-time destination address for every single transaction. This one-time address is what appears on the blockchain.

The recipient uses their private view key to scan the blockchain and identify which on-chain outputs belong to them. Once identified, they use their private spend key to actually spend those outputs. No one else — not the sender, not a node operator, not a blockchain analyst — can link the one-time on-chain address back to your published wallet address.

Public view key vs private view key

Your Monero wallet holds two key pairs: a spend keypair and a view keypair. The public view key is shared with senders (it is encoded in your wallet address) so they can generate the correct one-time destination. Your private view key is what lets you scan the blockchain to find your incoming funds. Importantly, you can share your private view key with a third party — an auditor, a tax authority, or an employer — to prove what you received, without granting them the ability to spend your funds. Spending requires the private spend key, which you should never share.

Subaddresses: unlinkable receiving addresses for different contexts

While stealth addresses prevent on-chain output linkage, there is still a risk at the address-sharing layer: if you give the same wallet address to multiple senders, those senders know they are sending to the same person. Monero solves this with subaddresses — additional receiving addresses derived from the same wallet keys, but mathematically unlinkable to your main address or to each other from an external perspective. You should generate a fresh subaddress for every distinct sender or context (employer, shop, friend) rather than reusing your main address or a single subaddress.

What stealth addresses protect and what they do not

Stealth addresses prevent recipient linkability on-chain. They do not hide the amount (RingCT's job), and they do not prevent metadata leakage at the network layer if you are connecting to a remote node without Tor. A remote node operator can see your IP address and the timing of your wallet scans, even though they cannot read transaction amounts or link outputs to your address.

Layer 3: RingCT — Hiding the Amount

Why amount privacy matters

Even if you cannot trace who sent to whom, knowing transaction amounts allows powerful inference attacks. You can match a payment amount to a known invoice. You can estimate a wallet's total balance by summing outputs. You can cluster wallets by characteristic spending patterns. Amount transparency completely undermines financial privacy even when sender and recipient are obscured.

How RingCT works: Pedersen commitments

Ring Confidential Transactions (RingCT) hide transaction amounts using a cryptographic primitive called a Pedersen commitment. A commitment scheme lets you "commit" to a value — prove that you know a specific number — without revealing what the number is. The commitment is binding (you cannot change the number after committing) and hiding (nobody else can determine the number from the commitment alone).

In practice, the network verifies that a transaction is valid — that no new XMR is created — by checking that the sum of input commitments equals the sum of output commitments plus a commitment to the fee. This equality proves conservation of value without revealing any individual amount.

Range proofs: preventing negative amounts

A naive Pedersen commitment scheme has a vulnerability: a malicious user could commit to a negative number, effectively creating coins out of nothing while the sum still balances. To prevent this, RingCT requires each output commitment to be accompanied by a range proof — a zero-knowledge proof that the committed value is a positive number within a valid range, without revealing the actual value.

Since October 2018, Monero uses Bulletproofs for range proofs, replacing the older and much larger Borromean ring signatures previously used. Bulletproofs dramatically reduced transaction size (by roughly 80% for a typical transaction with two outputs) and verification time. In June 2022, the network further upgraded to Bulletproofs+, which are approximately 5–7% smaller and faster to verify than standard Bulletproofs.

What RingCT protects and what it does not

RingCT makes all transaction amounts cryptographically invisible on the blockchain. Neither miners, nor full nodes, nor blockchain analysts can read output values. However, if you share your private view key, the holder can see your incoming amounts. RingCT does not protect against network-layer surveillance (Dandelion++ addresses that), and it does not hide who sent to whom (ring signatures and stealth addresses address that).

Layer 4: Dandelion++ — Hiding the Origin IP Address

The three on-chain layers protect what is recorded on the blockchain. They do not, by themselves, protect the moment a transaction enters the network — a point at which an attacker watching internet traffic could link the transaction to the IP address that first broadcast it.

Dandelion++ addresses this through a two-phase broadcast protocol. In the stem phase, a transaction is forwarded through a small, random chain of nodes — each passing it to exactly one other — before entering the fluff phase where it spreads to the full network in the normal way. Because the transaction enters the wide-broadcast phase from a node that is not the originator, an observer watching the network cannot reliably determine where it came from.

Dandelion++ meaningfully reduces IP-linkage risk but is not a substitute for Tor or I2P. If you require strong IP-level anonymity, you should run your Monero node and wallet over Tor or I2P in addition to relying on the protocol-level protections.

How the Four Layers Work Together

Each layer closes a distinct surveillance channel. When all four operate together on a single transaction, the result is:

• An outside observer cannot determine which output is being spent (ring signatures)
• An outside observer cannot link the on-chain destination to any published wallet address (stealth addresses)
• An outside observer cannot read the amount transferred (RingCT)
• An outside observer cannot reliably link the transaction to the IP address of the sender (Dandelion++)

Crucially, none of these protections require trust in any third party. All verification is cryptographic and decentralized. The network validates transactions without ever needing to see the underlying values.

What is still visible on the Monero blockchain

It is worth being explicit about what an observer can see. The Monero blockchain is public. Observers can see that transactions occurred, roughly when they occurred, their approximate size in bytes, and the list of ring members for each input (though not which is real). Block timestamps are public. The total supply can be independently audited using a mathematical property of Pedersen commitments that allows supply verification without revealing individual amounts. Nothing in Monero is "invisible" — the sensitive details are cryptographically masked.

The mandatory privacy advantage

On networks where privacy is optional — Bitcoin CoinJoin, Zcash's shielded pool, Ethereum mixers — the population of users choosing privacy is a small, self-selected subset. This paradoxically harms their privacy: the anonymity set (the group of plausible senders or recipients) is much smaller than on a network where everyone participates. Because every Monero transaction uses the same privacy mechanisms, the anonymity set for any given transaction is the full active transaction pool, not a privacy-conscious minority.

Monero vs Bitcoin Privacy: A Structural Comparison

This is not a complete security comparison — Bitcoin has its own strengths in areas such as script flexibility, ecosystem size, and auditability. The table focuses specifically on transaction privacy properties. For a broader analysis, see Monero vs Bitcoin: Privacy and Design Trade-offs.

What Monero's Privacy Does Not Protect Against

Understanding where Monero's protections end is as important as understanding where they begin. Monero's on-chain privacy mechanisms do not protect you in the following situations:

View key disclosure

If you share your private view key, the recipient can see all incoming transactions to your wallet, including amounts and timing. This is a deliberate feature for audit purposes, but it is a real privacy risk if you share your key unintentionally or under compulsion.

Remote node metadata

Connecting to a remote node (rather than running your own) allows the node operator to see your IP address, the timing of your wallet scans, and which blocks you are requesting — though not transaction amounts or addresses. If metadata privacy matters to you, run your own node or connect via Tor.

Exchange and on-ramp KYC

If you purchase XMR on an exchange that records your identity and withdrawal address, the exchange has a record linking you to that initial output. Once funds move through the network they become increasingly private, but the entry point remains a potential data disclosure.

Operational security failures

No cryptographic system protects against revealing information at the application layer — for example, posting your wallet address publicly, sending XMR to a contact who knows your identity, or running wallet software on a compromised device.

Frequently Asked Questions

Can ring signatures be broken or traced?

Ring signatures cannot be broken by simply observing the blockchain. An outside observer sees one transaction input that could plausibly belong to any of the 16 ring members. However, ring signatures do not provide absolute guarantees in every scenario. If an attacker controls a large fraction of the outputs on the blockchain — by flooding it with their own outputs — they could increase the statistical probability that a given input is genuine. This is known as an output flooding or Sybil attack on the ring, and it is expensive and impractical at scale. Monero's research into FCMP++ aims to replace ring signatures with a construction offering membership proofs across the entire blockchain output set, eliminating fixed-ring statistical weaknesses entirely. Common misunderstanding: Ring signatures do not make transactions literally invisible — they create plausible deniability by embedding the real input among decoys. Keep your wallet software updated to benefit from future protocol upgrades.

Does Monero hide transaction amounts completely?

RingCT hides the exact value of every transaction output using Pedersen commitments with range proofs. The network can verify mathematically that no new coins were created — inputs equal outputs plus fees — without knowing the actual figures. Neither miners nor full nodes can read amounts; verification works through the commitment math rather than plaintext inspection. However, if you voluntarily share your private view key with a third party for audit purposes, that party can see all incoming amounts to your wallet. Common misunderstanding: Some users assume amounts are hidden from ordinary users but visible to miners — this is incorrect. The practical implication is that you should be careful about who receives your view key, since sharing it exposes your full incoming transaction history.

What is the difference between a Monero main address and a subaddress?

A Monero main address is the primary receiving address derived directly from your wallet's public keys. A subaddress is a secondary address generated from the same wallet keys but mathematically unlinkable to the main address or to other subaddresses from the perspective of an outside observer. Subaddresses let you give different addresses to different senders without those senders being able to tell they are sending to the same wallet. Common misunderstanding: Many users believe reusing their main address is fine because Monero uses stealth addresses on-chain — while stealth addresses do prevent on-chain output linkage, the main address itself is public, and reusing it lets senders know they share a recipient. The practical implication is that you should generate a fresh subaddress for each distinct sender or context.

Does Dandelion++ protect my IP address when sending Monero?

Dandelion++ significantly reduces the ability of network observers to link a transaction to its originating IP. Without it, the first node to broadcast a transaction is often detectable as the source. Dandelion++'s stem phase passes the transaction through a small random chain before wide broadcast, making source identification much harder. However, Dandelion++ is not a substitute for Tor or I2P — if your ISP or an attacker is watching your specific connection they may still detect that you broadcast a transaction, even without knowing its contents. Common misunderstanding: Users sometimes assume Dandelion++ alone provides IP-level anonymity equivalent to Tor. The practical implication is that if IP privacy matters to you, run your wallet and node over Tor or I2P in addition to relying on Dandelion++.

Why does mandatory-by-default privacy matter more than optional privacy?

Privacy systems are strongest when all participants look identical. When privacy is optional — as on Bitcoin, or in Zcash's shielded pool — users who choose private transactions form a small, self-selected subset. Analysts can narrow their focus to that subset, which is far smaller than the full transaction set. In Monero, every transaction uses the same mechanisms, so no transaction stands out as "trying to hide something." The anonymity set — the pool of people any given transaction could plausibly belong to — is the entire user base, not a privacy-conscious minority. Common misunderstanding: Many people assume using a mixing service or optional privacy feature provides equivalent protection to Monero. Because optional privacy pools are small and self-selected, they are actually weaker anonymity sets. The practical implication is that Monero's uniform application of privacy provides structural anonymity that opt-in alternatives cannot replicate at equivalent user adoption levels.