I spent an hour trying to understand why @Dusk_Foundation needs two different account systems.
Most chains pick one model. Public by default with optional privacy features. Or private by default with view keys for transparency. I assumed Dusk would follow the same pattern. One account type. One transaction mode. A toggle in the wallet that switches between visible and hidden.
It turned out to be something else entirely...
Dusk runs both natively. Moonlight is the public account layer. Standard addresses, visible balances, auditable transactions. Phoenix is the shielded layer. Hidden amounts, encrypted sender and recipient, zero-knowledge proofs verifying validity without exposing data. They are not toggles of the same account. They are parallel systems operating on the same chain, each with its own address format and use case.
This changes how I think about compliance on blockchain. I assumed privacy was something you added when you needed it. On Dusk, privacy and transparency are separate infrastructure lanes. An institution can hold public reserves in Moonlight for regulatory reporting while moving client funds through Phoenix for confidentiality. The same entity uses both without bridging between chains or wrapping assets into different privacy standards.
But the tension is real. Two account systems mean twice the complexity. Wallet software has to manage both. Users have to know which address type to use for which transaction. A mistake does not just mean a failed transfer. It means sending a confidential transaction to a public address or exposing a settlement that was meant to be hidden.
I am still working out whether financial markets want a chain that mirrors their existing separation between public books and private ledgers, or whether they want a simpler system that forces everything into one model.
Is two-account architecture flexibility or fragmentation?
#dusk
$DUSK
@Dusk_Foundation
Most chains pick one model. Public by default with optional privacy features. Or private by default with view keys for transparency. I assumed Dusk would follow the same pattern. One account type. One transaction mode. A toggle in the wallet that switches between visible and hidden.
It turned out to be something else entirely...
Dusk runs both natively. Moonlight is the public account layer. Standard addresses, visible balances, auditable transactions. Phoenix is the shielded layer. Hidden amounts, encrypted sender and recipient, zero-knowledge proofs verifying validity without exposing data. They are not toggles of the same account. They are parallel systems operating on the same chain, each with its own address format and use case.
This changes how I think about compliance on blockchain. I assumed privacy was something you added when you needed it. On Dusk, privacy and transparency are separate infrastructure lanes. An institution can hold public reserves in Moonlight for regulatory reporting while moving client funds through Phoenix for confidentiality. The same entity uses both without bridging between chains or wrapping assets into different privacy standards.
But the tension is real. Two account systems mean twice the complexity. Wallet software has to manage both. Users have to know which address type to use for which transaction. A mistake does not just mean a failed transfer. It means sending a confidential transaction to a public address or exposing a settlement that was meant to be hidden.
I am still working out whether financial markets want a chain that mirrors their existing separation between public books and private ledgers, or whether they want a simpler system that forces everything into one model.
Is two-account architecture flexibility or fragmentation?
#dusk
$DUSK
@Dusk_Foundation