Dandelion++ Explained: How Monero Hides Your IP When You Send

Nothing written on the Monero blockchain identifies a sender, so the best remaining clue for an observer is off-chain: which IP address announced the transaction first. On a plain gossip network that question has an answer. An observer connected to enough nodes can time when each one first mentions a transaction and trace the wave back to its centre. Dandelion++ is the relay protocol monerod has used since 2020 to move that centre away from you.

What does Dandelion++ hide?

Dandelion++ hides which node created a transaction from the other nodes on the peer-to-peer network. It does this by changing the route a new transaction takes, not by encrypting anything. Peers still see each other’s IP addresses, and your internet provider still sees Monero traffic.

The protocol comes from a 2018 paper by Fanti and co-authors. Monero merged it in April 2020 and shipped it in v0.16.0.0 “Nitrogen Nebula” on 23 May 2020.

How a transaction travels: stem, then fluff

A Dandelion++ transaction is first handed along a chain of single peers (the stem) and only then broadcast to everyone (the fluff). In monerod it works like this:

1. Every node divides time into epochs of about 10 minutes. At the start of each one it picks 2 of its outgoing connections as stem peers and flips a weighted coin: 20% of the time it will be a fluff node for that epoch, otherwise a stem node.
2. When your node creates a transaction, it sends it to one of its two stem peers and to nobody else. This happens even if your node is a fluff node this epoch.
3. A stem node that receives it forwards it to one of its own two stem peers. A fluff node that receives it broadcasts it to all its peers, and normal gossip takes over.
4. Every node that handled the transaction during the stem starts a timer. If the transaction has not come back through normal gossip when the timer fires, the node broadcasts it itself. A peer that silently drops stem transactions cannot make them vanish.

The settings in cryptonote_config.h, as checked on 11 November 2026:

Stem peers are chosen from outgoing connections on purpose. Your node picked those peers. An adversary cannot place itself on your stem just by opening lots of inbound connections to you.

Key point: To an observer timing the gossip wave, the apparent origin is the fluff node, typically several hops from the sender. A stem relay that receives your transaction also cannot tell whether your node created it or was relaying it for someone else.

Does Dandelion++ protect you when you use a remote node?

Not from the remote node. Dandelion++ runs between nodes, and it starts only after a node has the transaction. What each party learns depends on where your wallet submits:

If you use a remote node you do not run, connect to it over Tor from the wallet so the operator at least does not get your home IP. The trade-offs are laid out in remote node vs your own node.

How much do spy nodes weaken Dandelion++?

Dandelion++ assumes most of your peers are honest, and measurements suggest a meaningful minority are not. The 2025 paper “Friend or Foe? Identifying Anomalous Peers in Monero’s P2P Network” ran five measurement nodes (San Francisco, Amsterdam, Bangalore, Singapore and Sydney) and reported:

• 1,924 of 13,050 reachable IP addresses, 14.74%, behaved in non-standard ways.
• Seven /24 subnets under one network operator hosted 1,582 distinct peers.
• With default settings, non-standard peers held 15.26% of a node’s outgoing connections on average.
• With the community ban list loaded and 32 outgoing connections, that fell to 7.13%.

The authors call these peers non-standard, not proven spies. But the arithmetic is unkind. Stem peers are drawn from outgoing connections, so if they are picked evenly, at 15% the chance that at least one of your two stem peers in an epoch is non-standard is about 28%. At 7% it is about 14%. An adversary that sits on many stems can start ruling out candidate senders.

The Monero Research Lab recommended in late 2024 that node operators load a ban list of suspected spy IPs. The list’s README counted over 1,900 addresses. To use it:

monerod --ban-list /path/to/ban_list.txt

or put ban-list=/path/to/ban_list.txt in bitmonero.conf. The same study reported 1,022 anomalous IPs in its ban-list run that were not on the list, so treat it as a reduction and not a cure. Full instructions, including the GUI and Docker, are in the spy nodes and ban list guide.

What Dandelion++ cannot do

Dandelion++ protects against peers on the Monero network and nothing wider. Two gaps follow from that:

• An ISP-level observer. Someone who can watch your line sees your node send a transaction message that it had not received from anyone. No relay pattern hides that.
• On-off use. If you start monerod only to send a payment and then quit, an ISP can line up your connection times with your transactions. Monero’s anonymity-network documentation advises running the daemon as often as possible.

And one from the research: Dandelion++ anonymity does not improve as the network grows. Distant nodes barely affect the odds, so an adversary needs a share of your neighbourhood, not of the whole network.

When should you add Tor or I2P?

Add Tor or I2P when your adversary could plausibly run many nodes or watch your connection. For everyday payments from your own always-on node, Dandelion++ with the ban list is a reasonable baseline.

On your own node, the relevant option is --tx-proxy:

monerod --tx-proxy tor,127.0.0.1:9050,10

With it set, transactions that originate on your node are sent only to peers on the anonymity network. If no such peer is connected, monerod logs an error and holds the transaction. It does not fall back to clearnet. The daemon uses two outgoing anonymity connections for this and rotates them every 5 minutes.

A short decision list:

• Phone wallet on a public remote node: route the wallet through Tor. Dandelion++ is not protecting you from that node.
• Own node at home, ordinary use: keep it running, load the ban list.
• Own node, sensitive payments: add --tx-proxy. Setup is in Monero over Tor and I2P.
• Any setup: network privacy does not fix behaviour. The OpSec mistakes checklist covers the rest.

What is changing: transaction relay v2

Monero developers are reworking how nodes announce and fetch transactions under the name “Tx relay v2”. It is part of the FCMP++ beta stressnet builds. The v3.0 release notes of 25 September 2026 list major improvements to the protocol, and v3.1 on 26 October 2026 added denial-of-service protection for it. None of this is on mainnet yet, and it is tied to the FCMP++ upgrade, whose design is covered in how FCMP++ and Carrot work.