Monero integrates the Dandelion++ protocol to obscure the network origin of a transaction before it is broadcast to the wider peer-to-peer network. The protocol operates in two phases: a stem phase, where the transaction is relayed along a random path of nodes without full diffusion, and a fluff phase, where the transaction is broadcast using standard gossip. The security of this model depends entirely on the integrity of the stem phase; if an adversary can observe or manipulate the stem path, the mapping between a transaction and its source IP address can be exposed, breaking the network-layer anonymity that complements Monero's on-chain privacy.

Dandelion++ Stem-Phase Attack Analysis
Introduction
Analysis of the stem-phase vulnerability in Dandelion++ that can link Monero transactions to originating IP addresses.
The primary failure mode occurs when an adversary controls a sufficient number of nodes to act as both the entry and exit points of the stem path. By running malicious nodes that participate in the Dandelion++ relay, an attacker can correlate the timing and content of a transaction entering the stem with its eventual emergence into the fluff phase. This is not a cryptographic break but a network topology attack that exploits the fundamental trust assumption of the stem relay: that no single entity controls the path. The risk is amplified by the relatively small size of Monero's public node network, where Sybil attacks and eclipse attacks remain practical concerns.
For node operators, wallet developers, and privacy researchers, the operational takeaway is that Dandelion++ provides probabilistic, not absolute, network-layer privacy. Defensive measures include monitoring for anomalous peer behavior, diversifying outbound connections, and avoiding reliance on a single network entry point. Chainscore Labs can assist teams in reviewing their node configuration and network monitoring setups to detect stem-phase anomalies, assess the risk of Sybil-based deanonymization in their specific operational context, and design integration patterns that do not inadvertently weaken the Dandelion++ privacy guarantees.
Quick Facts
Operational facts and failure modes for the Dandelion++ stem phase that can link Monero transactions to originating IP addresses.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Stem phase duration | Transaction propagates in a single path (stem) for a random number of hops before diffusing (fluff). | Node operators, privacy researchers | Verify stem length is not predictable or observable by a single adversary. |
Adversary model | A spy node connected to the victim or a network-level observer can correlate the first stem relay with the originating IP. | Node operators, wallet developers | Assume an adversary operates many listening nodes; do not rely on stem phase alone for IP obfuscation. |
Graph construction | The network graph used for stem path selection can be manipulated via Sybil nodes to increase the chance of being the first hop. | Node operators, protocol architects | Monitor peer churn and connection patterns for Sybil indicators. |
Timing analysis | Precise inter-node timing during the stem phase can link a transaction's entry into the network to its source. | Exchange engineers, wallet developers | Introduce random delays before transaction submission; avoid predictable submission patterns. |
Transaction blackout | A targeted eclipse or network partition can force a node to use a single, attacker-controlled stem path. | Node operators, mining pools | Configure diverse, trusted outbound peers and monitor for persistent connection failures. |
Diffusion transition | The transition from stem to fluff is a critical event; an observer seeing the first fluff broadcast can infer the stem path's origin. | Privacy researchers, protocol developers | Analyze fluff transition timing and graph topology for information leakage. |
Network-layer defense | Dandelion++ does not encrypt traffic; it only changes the propagation pattern. | All node operators | Use Tor or I2P to encrypt P2P traffic and hide IP addresses from direct observation. |
Technical Mechanism and Failure Modes
How the Dandelion++ stem phase can fail to protect Monero transaction origin privacy and what node operators must monitor.
Dandelion++ is Monero's transaction propagation mechanism designed to obscure the network-layer link between a transaction and its originating IP address. It operates in two phases: a stem phase, where a transaction is relayed along a single, randomly selected path of nodes without full broadcast, and a fluff phase, where the transaction diffuses normally across the network. The core privacy guarantee is that an adversary observing the network cannot easily distinguish the transaction's originator from a mere relay node. The stem phase is the critical privacy window; its failure directly exposes the sender's IP address.
The primary failure mode is a stem-phase graph-learning attack. An adversary controlling a sufficient number of malicious nodes can, over time, reconstruct the ephemeral stem paths. By observing the order and timing of transactions entering the fluff phase from different graph regions, the adversary can probabilistically identify the source node. This is exacerbated by intersection attacks, where a node's repeated use of the same transaction graph over multiple epochs allows the adversary to correlate stem-path endpoints. A single honest node on the stem path is the only defense; if an adversary controls all nodes in a stem, the origin is trivially exposed. The protocol's security relies on the assumption that the adversary does not have a complete view of the network graph and cannot perform a large-scale Sybil attack to populate stem paths.
Practical attacks exploit network-layer heuristics beyond the protocol specification. An adversary can use timing analysis, observing the latency between a transaction's first appearance on a monitored node and its subsequent diffusion, to infer if that node was the stem's start. Traffic analysis at the ISP level, while not a protocol failure, represents a realistic threat model where a powerful observer can correlate encrypted transaction sizes and timings to bypass Dandelion++ protections entirely. For node operators, the operational implication is clear: the privacy of every user is dependent on the collective honesty and topological diversity of the network. Running a node with a diverse set of outbound peers and monitoring for connection anomalies is a critical defensive measure. Teams needing a formal review of their node's network-layer exposure or integration of Dandelion++ into custom wallet infrastructure can engage Chainscore Labs for a targeted security assessment.
Affected Actors
Node Operators
Node operators are the primary defense layer. An adversary running a significant number of Sybil nodes can act as the stem relay for a target's transaction. If the adversary controls the node that receives the transaction directly from the originator, the link between the transaction and the source IP is immediately compromised.
Action Steps:
- Monitor peer connection quality and reject connections from nodes exhibiting suspicious timing patterns.
- Configure
--out-peersand--in-peersto limit exposure to untrusted nodes. - Use
--tx-proxyto broadcast transactions via a trusted outbound proxy, severing the direct IP-to-node link. - Run nodes behind a VPN or Tor to obfuscate the server's true IP address, raising the cost of network-layer deanonymization.
Operational and Integration Impact
The Dandelion++ stem-phase attack model creates concrete operational burdens for node operators, wallet developers, and exchanges. Mitigation is not automatic; it requires deliberate configuration, monitoring, and integration choices.
Node Operator: Stem-Phase Monitoring
Operators must monitor their node's behavior during the stem phase. Anomalies such as a node consistently acting as a diffuser or failing to relay transactions in a randomized pattern can indicate a Sybil attack or misconfiguration. Implement logging that tracks stem-to-fluff transitions and peer selection entropy without exposing transaction content. This is critical for nodes that serve as wallet backends for high-privacy users.
Wallet Developer: Network-Layer Integration
Wallet implementations must not bypass Dandelion++ by broadcasting transactions directly to a single, trusted node without stem-phase routing. This creates a static link between the transaction and the source IP. Developers should verify that their monero-wallet-rpc integration respects the local node's propagation logic and does not implement custom broadcasting that undermines the privacy model.
Exchange Engineer: Withdrawal Timing
Exchanges processing large withdrawal batches create a unique temporal fingerprint. If multiple outputs from a single batch enter the stem phase simultaneously from the same node, an observer can correlate them. Engineers should implement randomized delays and, where feasible, distribute withdrawal broadcasting across multiple, non-collocated nodes to disrupt this heuristic and protect user privacy.
Risk Team: Sybil Attack Surface
The stem phase's privacy guarantees degrade significantly if an adversary controls a large fraction of a node's outbound peers. Risk teams should assess their node's peer selection diversity and consider configuring trusted, non-Sybil peers or using network-level defenses like VPNs to obscure the node's true topological location. A node with only attacker-controlled peers has no stem-phase privacy.
Protocol Architect: Defense-in-Depth
Dandelion++ is a network-layer defense, not a replacement for cryptographic privacy. A stem-phase failure that links a transaction to an IP does not break RingCT or ring signatures, but it provides a critical metadata anchor for temporal analysis. System architects must design with the assumption that the network layer is compromised and ensure that on-chain privacy mechanisms can independently withstand deanonymization.
Risk Matrix
Operational risks and failure modes during the Dandelion++ stem phase that could link Monero transactions to originating IP addresses.
| Risk | Failure mode | Severity | Mitigation |
|---|---|---|---|
Stem-phase node compromise | A malicious node receiving a stem transaction logs the IP of the immediate peer, linking the transaction to that node. If the peer is the originator, privacy is broken. | High | Node operators should run exclusively over Tor or I2P to decouple IP addresses from node identity. Verify outbound-only connections to untrusted peers. |
Sybil attack on stem relay | An attacker surrounds a victim node with many malicious nodes. The victim's stem transaction is highly likely to be relayed directly to an adversary, revealing the origin. | High | Node operators should increase the number of outbound connections and use trusted, long-lived peers. Monitor for connection patterns from many nodes in the same /24 or /16 subnet. |
Stem-phase timing analysis | An adversary running multiple spy nodes observes the first appearance of a unique transaction across the network. The node that sent it during the stem phase is likely the origin. | Medium | Wallet developers should ensure randomized stem timers and transaction delays are implemented correctly. Verify against canonical |
Fluff-phase transition fingerprinting | An adversary monitors the network graph to identify the node that first broadcasts a transaction in fluff phase. If stem-phase peers are known, the origin node can be inferred. | Medium | Node operators should ensure fluff broadcast uses diffusion (not a single flood) to obscure the transition point. Verify |
Black-hole attack during stem | A malicious node accepts stem transactions but never forwards them, forcing the originator to re-broadcast. The re-broadcast pattern can deanonymize the sender. | Medium | Wallet software should implement exponential backoff with jitter for re-broadcasts and use a different outbound circuit for each attempt. Monitor for transactions stuck in local mempool. |
Exchange/hot wallet node targeting | An exchange's | Critical | Exchanges must run nodes behind a privacy network (Tor/I2P) and disable incoming connections. Use a dedicated, hardened node for transaction submission separate from the scanning wallet. |
Dandelion++ implementation divergence | A wallet or fork uses a non-standard Dandelion++ implementation with different stem length or timer logic, creating a fingerprintable behavior that distinguishes its transactions. | Medium | Wallet developers must use the exact Dandelion++ logic from |
Detection, Prevention, and Remediation Checklist
A practical checklist for node operators, wallet developers, and network engineers to harden their infrastructure against stem-phase deanonymization attacks. Each item identifies a specific failure mode, the signal to monitor, and the concrete step required to reduce the risk of linking a transaction to its source IP address.
Confirm that your node is not running in a legacy propagation mode that bypasses the stem phase entirely. The stem phase is the critical privacy window where a transaction is relayed along a single path before diffusing. If disabled, every transaction is immediately broadcast to the network, making IP-to-transaction linking trivial.
What to check:
- Ensure the
--disable-dandelionflag is not set in yourmonerodconfiguration. - Review logs for
Dandelionentries to confirm the node is entering stem mode for outbound transactions. - Verify that your node has a sufficient number of outbound connections (typically 8 by default) to establish a stem relay path.
Why it matters: A misconfigured node that skips the stem phase acts as a direct broadcast relay, instantly exposing the source IP of any transaction it originates. This is the most common and severe operational failure.
Source Resources
Use these sources to validate the Dandelion++ threat model against Monero’s current transaction-relay implementation. Because relay behavior can change between releases, operators and researchers should confirm conclusions against the deployed source and configuration.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Common questions from node operators, privacy researchers, and wallet developers about the practical risks and mitigations for Dandelion++ stem-phase attacks on Monero.
The stem phase is the first stage of Dandelion++ transaction propagation where a transaction is relayed along a single path of nodes (the stem) before diffusing broadly (the fluff phase). During the stem phase, the first node to broadcast a transaction is likely the originator. An adversary controlling nodes on the stem path can use timing and graph analysis to link a transaction to the originating IP address. This undermines Monero's network-layer privacy before the transaction even reaches the mempool.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


