Most blockchains make a single choice about visibility and force everyone to live with it. Dusk Network did something less tidy and, I think, more honest: it ships two transaction models side by side and lets the use case decide.
Moonlight is account-based and public, close to how a normal blockchain ledger behaves, easy to audit and simple to reason about. Phoenix is UTXO-based and shielded, hiding amounts and participants using zero-knowledge proofs, built for cases where confidentiality is the point rather than an afterthought. Both live on the same base layer, DuskDS, and both can move the DUSK token or pay for gas. A third layer, Zedger, sits above both for regulated securities specifically, tracking compliant asset balances in a way built to satisfy MiFID II style requirements rather than general payments. Nothing forces a user or a developer to pick a single philosophy of privacy and commit to it across every interaction.
The design decision worth sitting with is why Dusk did not just default everything to shielded and call it done, the way a lot of privacy projects do. Programmable privacy, in Dusk's own framing, means privacy that can be turned toward specific rules rather than applied uniformly. A regulated securities transfer might need Phoenix's confidentiality plus selective disclosure to an auditor. A simple staking transaction might not need shielding at all, and forcing it through a heavier privacy-preserving path would just add cost and complexity for no real benefit.
What this does not do is make the choice trivial for builders. Supporting multiple models means more surface area to secure, more documentation to write, and more decisions pushed onto developers who might have preferred one obvious default. Flexibility has a maintenance cost, and Dusk Network is still paying it.
#dusk $DUSK @Dusk
Moonlight is account-based and public, close to how a normal blockchain ledger behaves, easy to audit and simple to reason about. Phoenix is UTXO-based and shielded, hiding amounts and participants using zero-knowledge proofs, built for cases where confidentiality is the point rather than an afterthought. Both live on the same base layer, DuskDS, and both can move the DUSK token or pay for gas. A third layer, Zedger, sits above both for regulated securities specifically, tracking compliant asset balances in a way built to satisfy MiFID II style requirements rather than general payments. Nothing forces a user or a developer to pick a single philosophy of privacy and commit to it across every interaction.
The design decision worth sitting with is why Dusk did not just default everything to shielded and call it done, the way a lot of privacy projects do. Programmable privacy, in Dusk's own framing, means privacy that can be turned toward specific rules rather than applied uniformly. A regulated securities transfer might need Phoenix's confidentiality plus selective disclosure to an auditor. A simple staking transaction might not need shielding at all, and forcing it through a heavier privacy-preserving path would just add cost and complexity for no real benefit.
What this does not do is make the choice trivial for builders. Supporting multiple models means more surface area to secure, more documentation to write, and more decisions pushed onto developers who might have preferred one obvious default. Flexibility has a maintenance cost, and Dusk Network is still paying it.
#dusk $DUSK @Dusk
