What Is Dandelion++?

Every DigiByte transaction is public and traceable on-chain by design — that's what makes the blockchain auditable. But the very first step of getting a transaction onto the chain, broadcasting it to the network, used to leak something the blockchain itself doesn't: the IP address of whoever sent it. Dandelion++ is the protocol DigiByte uses to close that leak.

The problem: broadcast-based deanonymization

In a standard peer-to-peer broadcast, a node announces a new transaction to all of its connected peers at once, and each of those peers immediately relays it onward to all of theirs, and so on, flooding the network within seconds. That speed is great for confirmation times, but it's also a privacy hole: a well-connected observer running many nodes across the network can watch which peer announces a given transaction first, and that timing is a strong signal for identifying the originating IP address — even though the DigiByte address behind the transaction reveals nothing on its own. Network-level surveillance like this can undermine the privacy DigiByte's pseudonymous addresses are supposed to provide.

Two phases: stem, then fluff

Dandelion++ breaks that direct broadcast pattern into two distinct phases. In the stem phase, a new transaction is relayed privately to just one randomly selected peer at a time, forming a single unpredictable path through the network rather than spreading outward. Each node along that path independently decides, with some probability, to continue stemming to another single peer or to switch into the fluff phase — the ordinary flood-broadcast to all connected peers that gets the transaction into every mempool on the network. Because the transition point is random and the stem path is a single, unpredictable line rather than a branching flood, an observer watching the fluff broadcast can no longer reliably infer which peer originated the transaction — the trail that led there is deliberately obscured.

What Dandelion++ does and doesn't change

It's worth being precise about what this protects. Dandelion++ obscures the network-level origin of a transaction's broadcast; it does not hide the transaction's contents, amount, sending address, or receiving address once it's confirmed on-chain — DigiByte remains fully public and auditable at the ledger level. What Dandelion++ removes is a specific, non-cryptographic side channel: the ability to correlate "which IP said this first" with "who sent this transaction," a link that has nothing to do with the blockchain's actual security and everything to do with how the transaction happened to spread across the network.

Why this complements DigiByte's other defenses

Dandelion++ operates purely at the transaction-relay layer, independent of block production, difficulty retargeting, or mining. It sits alongside mechanisms like DigiShield and MultiShield as part of a broader pattern in DigiByte's design: layer specific defenses against specific, well-understood attack surfaces rather than relying on one mechanism to do everything. Where DigiShield and MultiShield protect the mining and consensus layer, Dandelion++ protects the network layer that gets a transaction from your wallet into a block in the first place.

Why "stem" beats a simple delay

A simpler idea — just wait a random amount of time before broadcasting — sounds like it would help, but it doesn't actually break the timing correlation an observer relies on; it only adds noise. Routing through a genuine chain of individual peers before the flood starts is what actually removes the direct link between "who told me about this transaction" and "who created it," because by the time the fluff phase begins, the transaction has already passed through one or more intermediaries who are not the original sender.

See the result

You can't watch the stem phase directly — that's the point — but you can see its result: every confirmed transaction, fully public and verifiable, in the block explorer, with no record of which peer first relayed it into the network.