Dusk’s “privacy blockchain” label hides a more useful detail: privacy on Dusk is not one universal transaction mode.
The current docs split activity between Moonlight (public) and Phoenix (shielded).
For Phoenix transactions, Dusk says the sender, receiver and transferred amount are not exposed beyond involved parties and holders of the view key.
But for Moonlight transactions—and other contract interactions—visibility depends on the implementation and whether privacy tech such as zero-knowledge proofs is used.
That distinction changed how I read the XSC story.
The glossary describes XSC as a confidential smart-contract standard adaptable to business requirements, including privacy constraints and compliance rules.
So the architecture is not simply “hide everything.”
It can support privacy where confidentiality matters while still allowing transparent flows where operational requirements demand them.
There is a practical clue: Dusk’s own exchange-integration guide recommends Moonlight for exchange deposits and withdrawals, while Phoenix requires a different custody and scanning model.
For financial applications, that flexibility may be more important than maximal privacy by default.
What I’m watching is how XSC deployments expose this choice in practice: which data stays shielded, which becomes auditable, and who controls that boundary.
@Dusk $DUSK #dusk
The current docs split activity between Moonlight (public) and Phoenix (shielded).
For Phoenix transactions, Dusk says the sender, receiver and transferred amount are not exposed beyond involved parties and holders of the view key.
But for Moonlight transactions—and other contract interactions—visibility depends on the implementation and whether privacy tech such as zero-knowledge proofs is used.
That distinction changed how I read the XSC story.
The glossary describes XSC as a confidential smart-contract standard adaptable to business requirements, including privacy constraints and compliance rules.
So the architecture is not simply “hide everything.”
It can support privacy where confidentiality matters while still allowing transparent flows where operational requirements demand them.
There is a practical clue: Dusk’s own exchange-integration guide recommends Moonlight for exchange deposits and withdrawals, while Phoenix requires a different custody and scanning model.
For financial applications, that flexibility may be more important than maximal privacy by default.
What I’m watching is how XSC deployments expose this choice in practice: which data stays shielded, which becomes auditable, and who controls that boundary.
@Dusk $DUSK #dusk
