Every Monero transaction starts its life in one place: your wallet. Before the transaction reaches the wider network, it travels through a phase designed to hide where it came from. That phase is Dandelion++, and it is the reason the IP address that first broadcast a transaction is hard to tie to it. It is also one of the most commonly misunderstood parts of Monero’s privacy, because people assume it does more than it does. Here is what actually happens, what it protects, and where its limits are.
The problem it solves
Monero’s ring signatures hide which output in a set of 16 was actually spent. That protection applies to the blockchain data. It says nothing about the network layer. When your wallet broadcasts a transaction the naive way, it sends it to your connected peers and they relay it outward. Anyone running enough nodes, and chain analysis firms do exactly this, can watch which node first announced a transaction and make a statistical guess about its origin. If that origin is your home IP, the blockchain privacy did not matter much. The observer could not read the transaction, but they knew who sent it.
How Dandelion++ works
The protocol splits a transaction’s journey into two phases. In the stem phase, your wallet passes the transaction to exactly one peer. That peer passes it to one of its peers, and so on. Each hop is a single relay, no wider spreading. After a random number of hops, often averaging around four, the transaction enters the fluff phase, where it is broadcast to everyone and propagates across the network normally.
The effect is geometric diffusion. An observer who watches the network can see the transaction appear at some node, but every node along the stem is an equally plausible origin. Each relay in the chain destroys a share of the evidence. With a stem of a few hops, the probability of correctly identifying the true source drops toward what you would get by guessing among the stem participants, and the stem length is randomized per transaction so the observer cannot calibrate around it.
What it does not do
Three honest limits, because overselling privacy gets people hurt.
First, Dandelion++ protects the transaction broadcast, nothing else. Your wallet still connects to peers for other traffic: block downloads, sync, general chatter. Node IP addresses are visible unless you route the entire connection through Tor or an untrusted network. If your threat model includes someone watching your internet connection, Dandelion++ alone is not enough.
Second, the first hop matters. If an adversary runs the node your wallet connects to as its stem peer, they see the transaction at hop zero. Running your own node, and connecting to it over a network you control, removes that problem. If you are not running a node yet, our guide to running your own Monero node in 2026 covers the real costs and hardware, and the piece on pruned nodes covers how to do it on a small disk.
Third, timing still exists. A stem adds a few seconds of delay before the fluff phase. That is normal. But if you broadcast the moment you receive funds, patterns can survive Dandelion++ on their own. The protocol hides the source IP trail, not human behavior.
What you should actually do
The practical setup, in order of effort. Minimum: use an official wallet with a remote node, and accept that Dandelion++ gives the broadcast decent but incomplete cover. Better: run your own node, local or remote, so your stem begins from infrastructure you control. Best for high-stakes use: run the node behind Tor, so even the stem phase cannot be linked to your IP. Monero’s daemon has built-in support for this, and it is the standard answer when people ask how to combine network privacy with blockchain privacy.
None of this costs you anything in fees. Dandelion++ is transport plumbing, and the fees you pay are set by the fee algorithm we covered separately. Changing your broadcast behavior does not change what a transaction costs.
Where the name comes from
The original Dandelion paper was proposed for Bitcoin and improved into Dandelion++, which Monero adopted and shipped for every transaction since early 2019. Monero’s implementation runs both phases on an ongoing basis: each node maintains a small set of Dandelion++ relay peers, swaps them at randomized intervals, and every new transaction flips a coin between stem and immediate fluff, so a portion of transactions never enter a stem at all. That randomness is deliberate. If every transaction stemmed, the stem graph itself would be a richer source of statistics than the broadcast pattern it replaced.
There is no setting to turn this on. Every official wallet and daemon does it, and has for years. If you read a guide telling you to configure Dandelion++ in monero-wallet-cli, the guide is out of date.
A brief note on remote nodes
If you use a public remote node from your wallet, your first stem hop is that node’s operator. Dandelion++ still blurs the trail beyond it, but the operator themselves sees the transaction at the source. The standard fix is the –tx-proxy option in monero-wallet-cli and the equivalent in the GUI, which sends transactions through Tor or I2P before they reach any node. Configure that once and every broadcast you make starts from an anonymous circuit rather than your own network.
The one-sentence summary
Ring signatures hide what the transaction says. Dandelion++ hides where it first appeared. View keys control who can check the outcome. Together they are the working privacy stack, and each one only covers its own layer, so know which layer your worry lives in before you pick a tool.