I used to summarize Dusk Network as a private blockchain. Its live L1 is more deliberate than that label.
DuskDS supports two native transaction models. Moonlight uses visible, account-based balances. Phoenix uses encrypted notes and zero-knowledge proofs to hide amounts and participants while still proving that the spend is valid.
Both settle on the same underlying blockchain.
That means privacy on Dusk is not one global switch. It is a routing decision for each flow. A treasury payment may need public observability. An investor transfer may need confidentiality. The Transfer contract accepts both families and sends each payload to the appropriate verification logic.
I like the flexibility, but it creates a new operational question: who chooses the model, and can users see that choice before signing?
A regulated application could expose a private interface while moving part of the workflow through Moonlight. A Phoenix transaction could hide its value publicly while a viewing key gives an authorized party access. Neither outcome is wrong by itself. The risk is assuming "Dusk" tells me which data is visible without inspecting the actual route.
The signals I want are practical. Wallet prompts should distinguish public and shielded actions. Applications should document when value crosses between models. Auditors should be able to verify that viewing access is limited to the stated purpose.
I would also watch failure handling. If a shielded path is unavailable, the application should not silently fall back to a transparent transfer just to complete the action.
Dusk's dual model makes privacy selectable. Its credibility will depend on making that selection explicit enough that confidentiality is a property of the transaction, not a slogan attached to the network.
#dusk $DUSK @Dusk
DuskDS supports two native transaction models. Moonlight uses visible, account-based balances. Phoenix uses encrypted notes and zero-knowledge proofs to hide amounts and participants while still proving that the spend is valid.
Both settle on the same underlying blockchain.
That means privacy on Dusk is not one global switch. It is a routing decision for each flow. A treasury payment may need public observability. An investor transfer may need confidentiality. The Transfer contract accepts both families and sends each payload to the appropriate verification logic.
I like the flexibility, but it creates a new operational question: who chooses the model, and can users see that choice before signing?
A regulated application could expose a private interface while moving part of the workflow through Moonlight. A Phoenix transaction could hide its value publicly while a viewing key gives an authorized party access. Neither outcome is wrong by itself. The risk is assuming "Dusk" tells me which data is visible without inspecting the actual route.
The signals I want are practical. Wallet prompts should distinguish public and shielded actions. Applications should document when value crosses between models. Auditors should be able to verify that viewing access is limited to the stated purpose.
I would also watch failure handling. If a shielded path is unavailable, the application should not silently fall back to a transparent transfer just to complete the action.
Dusk's dual model makes privacy selectable. Its credibility will depend on making that selection explicit enough that confidentiality is a property of the transaction, not a slogan attached to the network.
#dusk $DUSK @Dusk
