I used to see @Dusk talking about both Moonlight and Phoenix, and I thought it was simply “ordinary transfers” and “privacy transfers” done with two duplicated feature sets. But when I read the transaction model documentation and the exchange integration notes side by side, I realized the dual-model approach isn’t just showmanship—it’s an active acknowledgement within the same settlement layer: some fund flows must be public, while some should not expose amounts and relationships to everyone.
Moonlight is a public-account model where the balance, sender, receiver, and amount are all visible, making it easier for exchange top-ups, treasury operations, and scenarios that require public reconciliation. Phoenix instead puts funds inside encrypted notes, using zero-knowledge proofs to confirm there are no double-spends and that the funds are sufficient, while not revealing the specific amount and corresponding note to onlookers. When an audit is needed, selective disclosure is done via a viewing key.
The biggest misconception here is: “Because there is privacy, the browser can see nothing.” Even with the official browser, you can still see public metadata such as the block, transaction type, fees, and gas—the exact visibility depends on the transaction model and the contract. Conversely, an exchange also can’t just treat Phoenix as Moonlight and scan it directly. The official integration documentation explicitly recommends using Moonlight for deposits; privacy balances must be converted to public accounts first, and the custody and scanning logic are completely different.
So the challenge with $DUSK isn’t proving that privacy can be done—it’s ensuring users don’t take the wrong path when switching between public and private. For #dusk to truly enter regulated fund flows, privacy by default, disclosure when needed, and predictable custody must all hold together. Are you more worried about fully transparent leakage of positions, or is the dual-model approach raising product complexity too much?
Moonlight is a public-account model where the balance, sender, receiver, and amount are all visible, making it easier for exchange top-ups, treasury operations, and scenarios that require public reconciliation. Phoenix instead puts funds inside encrypted notes, using zero-knowledge proofs to confirm there are no double-spends and that the funds are sufficient, while not revealing the specific amount and corresponding note to onlookers. When an audit is needed, selective disclosure is done via a viewing key.
The biggest misconception here is: “Because there is privacy, the browser can see nothing.” Even with the official browser, you can still see public metadata such as the block, transaction type, fees, and gas—the exact visibility depends on the transaction model and the contract. Conversely, an exchange also can’t just treat Phoenix as Moonlight and scan it directly. The official integration documentation explicitly recommends using Moonlight for deposits; privacy balances must be converted to public accounts first, and the custody and scanning logic are completely different.
So the challenge with $DUSK isn’t proving that privacy can be done—it’s ensuring users don’t take the wrong path when switching between public and private. For #dusk to truly enter regulated fund flows, privacy by default, disclosure when needed, and predictable custody must all hold together. Are you more worried about fully transparent leakage of positions, or is the dual-model approach raising product complexity too much?
