Most Monero privacy talk concentrates on what the blockchain records. Ring signatures hide the sender, stealth addresses hide the recipient, RingCT hides the amount. But every transaction has a moment before any of that cryptography matters: the instant your wallet broadcasts it to the network. Dandelion++ is the protocol that protects that moment. It hides which node first originated a transaction, which is the same thing as hiding the IP address behind it.
The problem it solves
A Monero transaction is private on the chain, but the broadcast is a network event. In the default flow, a wallet hands its transaction to a node, and that node immediately relays it to several peers, which relay to several more, following a diffusion pattern. Anyone running enough nodes and recording the timestamps and directions of first-seen transactions can trace the flood back to its origin. Studies on Bitcoin, whose relay worked the same way before Dandelion, showed that a modest number of spy nodes can deanonymise the sender’s IP with high confidence. Monero’s blockchain never records your IP, but the peer-to-peer network sees it plainly.
Once an observer connects an IP to a transaction, the rest follows. The IP leads to a VPN exit, a home line, or a hosting provider. Correlate that with timing and other traffic and the privacy the ring signatures provide starts to matter a lot less. This is the same class of weakness that makes running your own node worthwhile, a point covered in the case against remote nodes.
How Dandelion++ works
Dandelion++ replaces immediate diffusion with two phases. The stem comes first: the originating node passes the transaction to exactly one randomly chosen peer, and that peer, with probability, either continues the stem by passing it to another single peer, or switches to the fluff. The fluff is the ordinary diffusion flood. The stem typically runs through one to four hops before the transaction explodes outward.
The observer’s problem is now structural. The spy node sees a transaction arrive from a peer, but cannot tell whether that peer originated it or is merely the third link in a stem. Tracing one hop back gets you an intermediary, not a source. Because each hop is chosen randomly and stems are short, the observer’s best guess at the origin is a probability distribution across several nodes, and the real origin is only one candidate among them.
The ++ in the name matters. The original Dandelion proposal was vulnerable to adversarial relay patterns, where spy nodes distort the graph to make their guess easier. Dandelion++, designed in 2018 and implemented in Monero since the 0.13 release in October that year, adds redundancy: the transaction is handed to two stems instead of one, with each following its own path. A spy who misses one stem still sees the transaction, but its origin estimate degrades because the two paths muddy each other.
What it does and does not protect
Dandelion++ obscures the origin of a transaction at the network layer. It does nothing to the transaction itself, and it does nothing for the traffic around it.
- It does not hide your IP from the node your wallet connects to directly. If you use a remote node over a clearnet connection, that node’s operator knows your IP and can correlate it with the transactions you hand over. Dandelion++ protects the network’s relay pattern, not your first hop. The first-hop protection is the argument for a local full node, or Tor with remote nodes.
- It does not break timing analysis on its own. If you are the only person sending a transaction in a quiet window, the fluff’s arrival pattern still points near your neighbourhood of the graph. Dandelion++ adds plausible deniability, not a mathematical guarantee.
- It does not interact with on-chain privacy at all. Ring signatures, stealth addresses and RingCT, explained in the privacy mechanics walkthrough, operate on a different layer entirely. The two systems are complementary: one hides you in the crowd of possible signers, the other hides you in the crowd of possible originating nodes.
Why the stem exists at all
A fair question is why Monero bothers with the stem phase rather than randomising the diffusion directly. The answer is timing. In plain diffusion, the node that first relays a transaction is also the node that received it first, so the relay order itself is evidence. A stem decouples those two facts: the first node to relay into the fluff is a randomly chosen point several hops from the origin, and the origin’s own relay timing looks like every other stem participant’s. The stem also adds a small artificial delay, a few seconds on average, which is imperceptible for a payment confirmation but destroys the millisecond-precision timing attack that made the pre-Dandelion relay pattern traceable.
What a wallet user should actually do
Dandelion++ is on by default and needs no configuration. The practical takeaways are about the first hop, not the relay protocol.
Run a full node locally so the first entity that sees your transactions is your own machine. If a full node is not practical, use the official desktop or CLI wallets over Tor against a remote node that supports onion connections, so the node sees a Tor exit rather than your home IP. Avoid third-party wallet services and web wallets for any balance you care about; they see your IP, your transactions and your keys, and no relay protocol fixes that.
For the average user the mental model is simple: Monero’s on-chain privacy hides what you sent and to whom it can be linked, while Dandelion++ buys anonymity at the moment of broadcast. Neither layer is a reason to neglect the other. The chain does not record IPs, and the network does not record balances, and the combination only holds if you keep the first hop, the one part Dandelion++ explicitly leaves alone, under your own control.