When you broadcast a Monero transaction, the recipient is hidden by ring signatures, the amount is hidden by RingCT, and the address is hidden by stealth addresses. That still leaves one thread hanging: where the transaction first appeared on the network. Anyone watching can see the IP address that first announced a transaction, and if that IP is yours, home connection, VPN exit, cafe wifi, the privacy of everything else is undermined. Dandelion++ is the protocol feature that cuts that thread, and it is worth understanding if you care about how private your Monero actually is.
What Dandelion++ does
Without Dandelion++, a wallet broadcasts a transaction to every peer it is connected to, and those peers relay it immediately to everyone they know. The transaction fans out from its origin like a firework, and an observer running a few nodes can statistically locate the fan-out point and link it to an IP address.
With Dandelion++, the transaction first travels in a completely different shape. Instead of broadcasting, your wallet passes the transaction to exactly one randomly chosen peer. That peer passes it to one of its own randomly chosen peers, and so on, a single quiet line rather than a fan-out. This is the stem phase, and it lasts a random number of hops. Only when the stem ends does the transaction enter the fluff phase, where it is broadcast normally and spreads across the whole network.
The effect is simple: by the time anyone sees the transaction, it has moved several hops away from your IP through relay nodes chosen at random. The observer watching the network sees the transaction appear from some node in the middle of nowhere, not from you. Neither you nor anyone else can easily tell which node was the true origin, because every node on the stem just looks like a relay.
Stem, fluff, and the random timer
Two details do the real work. First, the number of stem hops is randomised per transaction. If it were fixed at, say, four hops, the origin would be exactly four hops from the first broadcast, and a patient observer could walk back. Randomising the hop count means the origin could be one hop away or eight, and there is no way to know which.
Second, timing is deliberately jittered. Nodes in the stem hold the transaction for a random interval before forwarding it, rather than relaying instantly. Instant relaying leaks information too, because propagation timing can reveal distance from origin even without knowing the hop count. The random delays blur that clock.
Monero has shipped Dandelion++ since the October 2018 network upgrade, so every transaction on the network today uses it by default. There is no setting to enable and nothing to configure in standard wallets.
What Dandelion++ protects, and what it does not
Be precise about the boundary. Dandelion++ obscures the link between your transaction and your IP address at broadcast time, against passive network observers running their own nodes and watching traffic.
It does not protect you in every situation. If you use a remote node run by someone else, your wallet sends the transaction to that node first, and the node operator can see your IP alongside your transaction submission regardless of Dandelion++. Running your own node closes exactly this gap, which is one of the practical reasons a local node beats remote node lists, whatever your bandwidth budget. We cover the costs and setup of that in our guide to running your own Monero node.
Dandelion++ also does not hide anything from the counterparty of a transaction who already knows you sent it, and it does nothing about amounts or addresses, which are the job of RingCT, stealth addresses and the growing set of privacy features discussed in our overview of Monero transaction privacy in 2026. It is one layer in a stack, and Monero is designed so the layers do not depend on each other failing together.
Practical takeaways
For everyday use, Dandelion++ means you should stop worrying about broadcast surveillance from hobbyist spy nodes and focus on the parts you control:
- Use your own node if privacy matters to you, or a remote node you trust over one you found in a public list.
- Avoid sending transactions and then talking about them from the same connection. Dandelion++ obscures the network link, not human behaviour.
- Do not disable transaction relaying options in wallets that expose them unless you understand the trade-off; you are opting out of contributing to everyone’s stem cover, including your own future transactions.
A worked example
Suppose you send 0.5 XMR from a wallet on your laptop, connected through your own node at home. Your wallet picks one peer from its eight outbound connections and passes the transaction to it alone. That peer waits a random couple of seconds, picks one of its own peers, and forwards it. After a random number of such hops the transaction hits a node that switches to fluff and shouts it to everyone. A surveillance node sees a new transaction arrive from an IP in another country entirely. Working backwards is statistically meaningless, because every node along the stem behaves identically to the origin, and neither the hop count nor the delays are knowable. Contrast that with the pre-2018 behaviour, where the transaction would have burst out of your home IP within a second of you clicking send.
Now change one variable: you use a public remote node from a list instead. Your wallet hands the transaction to that node, whose operator logs the submission with your IP attached. Dandelion++ still runs from that node onward, but it is now protecting the remote node’s broadcast, not yours. The layer was fine; you stepped around it. This is why node choice, not relay configuration, is the decision that actually matters for broadcast privacy.
None of this requires effort in a default install. Dandelion++ is one of the quiet parts of Monero that just works in the background, which is exactly why so few people know it is there. Knowing it exists, and where its protection ends, is part of using Monero with your eyes open.