A design question every privacy chain eventually answers: does every transaction get shielded, no exceptions, or does the user choose? Monero answers with mandatory privacy on every transfer, full stop. Dusk Network answered differently, building 2 separate transaction models into its base settlement layer instead of picking 1 posture and forcing all activity through it.
Phoenix handles the shielded side: a UTXO-based model where amounts and participants stay private by default, built for security and asset transactions where confidentiality is the entire point. Moonlight handles the public side: account-based, transparent, closer to how most people already picture a blockchain balance working. Both settle through the same DuskDS layer, both pay gas in DUSK, and a user or institution picks whichever model fits what they're actually doing instead of being locked into 1 philosophy about privacy for every use case.
I think this was the right call for a chain trying to serve regulated finance specifically, since institutions don't want uniform secrecy any more than they want uniform transparency; they want the ability to be private with counterparties and auditable with regulators, on the same rail, transaction by transaction. Building 2 transaction models instead of 1 is real engineering overhead a single-model chain never has to carry.
What I haven't seen proven yet is how this plays out once volume actually scales. 2 coexisting transaction models mean 2 sets of tooling, 2 mental models for developers integrating with Dusk Network, and potentially 2 liquidity pools that don't always move together. The flexibility is real. Whether it becomes a genuine advantage or a source of fragmentation is something only real usage numbers, not architecture diagrams, will eventually settle.
@Dusk_Foundation $DUSK #dusk
$ACE $PORTAL
Phoenix handles the shielded side: a UTXO-based model where amounts and participants stay private by default, built for security and asset transactions where confidentiality is the entire point. Moonlight handles the public side: account-based, transparent, closer to how most people already picture a blockchain balance working. Both settle through the same DuskDS layer, both pay gas in DUSK, and a user or institution picks whichever model fits what they're actually doing instead of being locked into 1 philosophy about privacy for every use case.
I think this was the right call for a chain trying to serve regulated finance specifically, since institutions don't want uniform secrecy any more than they want uniform transparency; they want the ability to be private with counterparties and auditable with regulators, on the same rail, transaction by transaction. Building 2 transaction models instead of 1 is real engineering overhead a single-model chain never has to carry.
What I haven't seen proven yet is how this plays out once volume actually scales. 2 coexisting transaction models mean 2 sets of tooling, 2 mental models for developers integrating with Dusk Network, and potentially 2 liquidity pools that don't always move together. The flexibility is real. Whether it becomes a genuine advantage or a source of fragmentation is something only real usage numbers, not architecture diagrams, will eventually settle.
@Dusk_Foundation $DUSK #dusk
$ACE $PORTAL