Stealth Address vs Ring Signature in Monero
Stealth Address vs Ring Signature in Monero
About 1.2 million Monero transactions cleared the network in April 2026, and not one of them publicly revealed a sender, a receiver, or an exact amount on the public ledger. That property doesn't come from one cryptographic trick. It rides on at least three overlapping layers, two of which confuse beginners and even experienced Bitcoiners constantly: the stealth address and the ring signature. They sound similar, get mentioned in the same paragraph of every Monero explainer, and both are casually described as "the thing that makes Monero anonymous." But they protect different sides of the same transaction, and conflating them makes it impossible to reason clearly about what a chain observer can or cannot see.
At MoneroSwapper we field this question almost daily — usually from people who just used our swap interface, noticed no KYC was required, and want to understand the actual cryptographic reason for that. This article unpacks both primitives, walks through where they overlap, where they don't, and what each one would leak if it disappeared from the protocol tomorrow. By the end you'll know exactly which problem each construction solves and why removing either one would collapse Monero's privacy guarantees.
Why Confusing the Two Hurts Your Mental Model
People who reason about Monero privacy from a single bucket called "the anonymity stuff" tend to make three predictable mistakes. They believe sharing a view key is harmless because "ring signatures still protect everything," they assume that increasing the ring size also strengthens receiver privacy, and they think the receiver of a payment is hidden by the same construction that hides the sender's input choice. None of these are correct, and all three lead to real operational errors.
The split between sender-side and receiver-side privacy is the single most useful distinction to internalize. Monero's protocol applies different cryptography to each side because the two problems are different. Hiding who is paying you means making outputs unlinkable to your published address. Hiding which prior output you are spending means making your input indistinguishable from a group of decoys. These are not symmetric problems.
- Receiver-side privacy: handled by stealth addresses (one-time output keys derived from the recipient's published address).
- Sender-side privacy: handled by ring signatures (specifically CLSAG since the October 2020 hardfork).
- Amount privacy: handled by RingCT with Bulletproofs+ range proofs — a third, separate layer.
When someone asks "is Monero traceable?" the honest answer depends on which of these three layers the questioner has in mind. A view key leak compromises only the first. A weak ring choice compromises only the second. And a future flaw in Bulletproofs+ would compromise only the third. They fail independently, which is why understanding them independently matters.
What a Stealth Address Actually Is
A stealth address is a one-time public key generated by the sender at the moment of paying you. Every time someone pays the same published Monero address, a fresh, mathematically unrelated destination key appears on chain. No two payments ever share a destination, even if they go to the same wallet, in the same minute, from the same sender.
The construction relies on elliptic-curve Diffie-Hellman. Your published address encodes two public points: one tied to your spend key and one tied to your view key. When Alice pays you, her wallet generates a random ephemeral scalar, multiplies it against your view key point to derive a shared secret, hashes that secret, and adds the hash to your spend key point. The result is the one-time destination key written into the transaction output. Alice publishes only her ephemeral public point — the secret used to derive the destination cannot be recovered from anything on chain.
How your wallet finds payments meant for you
Your wallet uses your view key to perform the same Diffie-Hellman operation in reverse against every output it sees. When the math works out, the wallet knows that output belongs to you. When it doesn't, the output is silently ignored. This is why running a Monero wallet requires scanning the chain rather than looking up an address in a search index: there is no address on chain to look up.
Crucially, only your spend key can actually spend the output. The view key reveals which outputs are yours but cannot move them. This is the structural reason Monero supports view-only wallets — accountants, auditors, or watch-only services can confirm income without gaining the ability to drain funds.
Subaddresses extend the same idea
Most users never share their primary address. Instead, they hand out subaddresses — separate public addresses derived from the main keypair using a fixed index. Each subaddress is unlinkable from the main address and from every other subaddress, even to someone holding all of them. This is what powers the per-customer address generation in merchant tools, donation pages, and our own MoneroSwapper deposit flow: every order gets a fresh subaddress, so on-chain observers can never aggregate them under one wallet.
The most common privacy mistake we see new users make is reusing a single primary address everywhere. The protocol gives you unlimited subaddresses for free — use them.
What a Ring Signature Actually Is
A ring signature is a digital signature produced on behalf of a group, where any verifier can confirm "one member of this group signed this" but cannot tell which member. Monero uses ring signatures to hide which past output is being spent as the input to a new transaction.
When you spend, your wallet selects fifteen other on-chain outputs that aren't yours and bundles them with your real input into a ring of sixteen. The signature is valid if and only if one of the sixteen members holds the corresponding spend key — but the verifier (and the public chain) cannot tell which one. Your output and fifteen unrelated decoys all become equally plausible candidates as the true spent input.
CLSAG and the current state of the art
Monero's specific construction is called CLSAG (Concise Linkable Spontaneous Anonymous Group signatures), which replaced MLSAG in the October 2020 hardfork. CLSAG produced roughly 25% smaller transactions and about 20% faster verification at equal security. The ring size has been a protocol-wide fixed value since 2019 — first 11, then 16 from the August 2022 hardfork onward. A uniform ring size matters because variable sizes would themselves leak information about wallet software, transaction type, or user behavior.
Key images prevent double spending
Because no one can see which input is real, the protocol needs a separate mechanism to prevent double spending. That mechanism is the key image: a deterministic value derived from the spend key and the one-time output key. Every output produces exactly one possible key image, and the network rejects any transaction whose key image has appeared before. The image reveals nothing about the output's identity but guarantees one-time use.
Side by Side: What Each Construction Hides
The matrix below makes the division of labor explicit. Notice that no single primitive hides all three of sender, receiver, and amount. Monero needs the full stack to provide the privacy property most users have in mind.
| Property | Stealth Address | Ring Signature (CLSAG) |
|---|---|---|
| What it hides | The link between a published address and on-chain output destinations | The link between an on-chain output and the transaction that spends it |
| Side of the transaction | Receiver-side (output) | Sender-side (input) |
| Underlying primitive | Elliptic-curve Diffie-Hellman + hashing | Linkable spontaneous anonymous group signature |
| Tunable parameter | None — derivation is one-shot per output | Ring size (currently fixed at 16) |
| What breaks it | View key disclosure to a hostile party | Poison output attacks, EAE-style heuristics, very small anonymity sets |
| What it does NOT hide | The transaction amount, the sender's input | The destination, the amount, the timing |
| Cost per transaction | Tiny — one extra scalar multiplication | Larger — scales with ring size, currently dominates tx size |
One observation worth pausing on: a stealth address is not a probabilistic guess. It is a hard cryptographic guarantee that the output destination cannot be linked back to the recipient's address without the view key. A ring signature, by contrast, is statistical — observer confidence is roughly one in sixteen by default, and that figure can degrade against an attacker who controls the decoy selection process or owns many of the ring members.
How They Combine in One Real Monero Transaction
To see why neither alone is sufficient, walk through a single payment. Alice wants to send 2 XMR to Bob, whose Monero address she has from a public donation page.
- Alice's wallet computes the stealth output. It generates an ephemeral scalar, performs the Diffie-Hellman with Bob's view key point, and derives a one-time destination public key. This goes into the transaction's output list. No one watching the chain can connect that output to Bob's published address.
- Alice's wallet selects the ring. To fund the payment, Alice must spend one of her own prior outputs. Her wallet picks that real output and fifteen decoys from the chain's recent and historical output set. The decoy selection follows a published gamma distribution that mirrors the spending patterns of real users.
- Alice's wallet signs with CLSAG. The signature proves one of the sixteen ring members consented to the spend. The verifier learns nothing about which one. The key image attached to the signature ensures the real output cannot be spent again.
- Alice's wallet hides the amounts with RingCT. Inputs and outputs are encoded as Pedersen commitments. Bulletproofs+ range proofs convince the network that no output exceeds the input total, without ever revealing the numbers.
- Bob's wallet scans the new block. Using his view key, Bob performs Diffie-Hellman against every output. When the math matches Alice's payment, the output reveals itself. Bob now knows he has been paid 2 XMR, but the chain itself shows only an opaque blob.
Strip out the stealth address and Bob's wallet would still find the payment, but so would every chain analysis firm: every payment to Bob's address would land at the same destination, and his entire incoming history would be public. Strip out the ring signature and Alice's spend would point at exactly one prior output, exposing her wallet's transaction graph. Strip out RingCT and the amounts would leak, making the other two layers far easier to deanonymize through value correlation. Each layer protects against a different adversary.
A Practical Example: A MoneroSwapper Swap
Consider a user who deposits 0.05 BTC at MoneroSwapper and receives XMR at a freshly generated subaddress in their Feather wallet. Two ledgers record parts of this trade, and what each observer sees is instructive.
On the Bitcoin side, the deposit address is plainly visible. Chain analysis tools — Chainalysis, Elliptic, TRM Labs — will tag it as belonging to a non-custodial swap service if they have heuristics for our deposit pattern. The amount, the timing, and the originating UTXOs are all public. This is normal for Bitcoin and is one reason users seek Monero in the first place. The swap engine sends BTC to a liquidity pool, and the trail on the BTC chain effectively ends at that pool.
On the Monero side, the picture is fundamentally different. Our payout transaction creates a stealth output keyed to the user's subaddress. To a chain observer the output is a fresh public key with no apparent connection to either MoneroSwapper or the user. The transaction spends a ring of sixteen, including one of our outputs and fifteen decoys, so even our own spend is not transparently identifiable from chain state alone. RingCT obscures the exact payout amount. The result is that even an observer who knows a swap occurred cannot prove which specific Monero transaction in the relevant block was the payout, nor which subaddress received it.
This asymmetry — transparent BTC in, opaque XMR out — is the entire point of using Monero as a privacy layer rather than as an end-to-end transaction currency for every payment. The stealth address ensures the swap's output cannot be linked to the user's address; the ring signature ensures our payout cannot be linked back through our hot wallet history.
FAQ
Can stealth addresses be deanonymized?
Only by someone holding the view key for the recipient address. The view key reveals which outputs belong to which wallet but cannot spend them. If you share a view key with a third party — for example, to demonstrate solvency to an auditor — that party can see all your incoming payments forever, including past ones. Treat the view key as sensitive data, not as a "read-only password" that can be safely posted.
Why did Monero increase the ring size to 16?
The August 2022 Fluorine Fermi hardfork raised the ring size from 11 to 16 to widen the anonymity set per spend. Sixteen is roughly the sweet spot where additional decoys produce diminishing privacy gains at increasing transaction-size costs. The next generation, FCMP++ (full-chain membership proofs), is expected to replace fixed-size rings with proofs over the entire output set, effectively making the anonymity set the whole chain.
Are ring signatures going away with FCMP++?
Yes, eventually. FCMP++ is the planned successor to CLSAG for sender-side privacy and is in active development as of 2026. It will use a different cryptographic construction — Curve Trees plus a SAL proof — to prove input membership in the full UTXO set rather than in a 16-member ring. Stealth addresses are not affected and will remain in use. The two layers were always independent, which is exactly why one can be upgraded without touching the other.
Is one more important than the other for everyday privacy?
For receiving payments, the stealth address does almost all the work — without it, any address shared publicly would expose every payment ever received. For spending, the ring signature is what prevents your wallet's transaction graph from becoming a public record. Both matter, but they matter in different scenarios. A merchant accepting Monero leans more heavily on stealth addresses. A privacy-conscious sender leans more heavily on ring signatures.
Does a swap service like MoneroSwapper need either key from me?
No. The user supplies only the destination Monero address (or subaddress). The swap engine derives the stealth output the same way any sender would, with no access to the user's spend key or view key. This is the structural reason no-KYC Monero swaps are possible at all: nothing about the cryptography requires the service to identify the user, and nothing about the user's privacy depends on trusting the service to keep secrets.
Conclusion
Stealth addresses and ring signatures are not two names for the same thing. They solve opposite halves of the privacy problem — one hides where the money is going, the other hides where it came from — and they fail under different threat models. Understanding the split is the difference between treating Monero as a magic box and actually being able to reason about your own privacy posture. If you want to put either layer to work without thinking through implementation details, that is exactly what MoneroSwapper is built for: anonymous, no-KYC swaps that hand you a fresh stealth output protected by a 16-member ring, every single time.