I almost skipped past Zedger the first time I read through Dusk Network's architecture, assuming it was just a variant of Phoenix. It is not. Phoenix is a UTXO model built for confidential payments. Zedger is a separate hybrid model, blending UTXO style privacy with account based features, built specifically because security tokens need things a pure privacy model does not naturally support: whitelists that restrict trading to vetted holders, the ability for an issuer to freeze a compromised position, and forced transfer in cases where a court order or corporate action requires it.
That is a genuinely uncomfortable design decision for a privacy first project to make, and I respect that Dusk Network made it openly rather than pretending securities could run on the same rails as private payments. A confidential security contract, what the project calls XSC, needs an issuer to retain certain powers over tokens after they are distributed, because regulated markets require it. Building Zedger as its own model, rather than stretching Phoenix to cover a use case it was never designed for, keeps each system honest about what it actually guarantees.
The tradeoff is complexity. Two transaction models plus a transparent account layer in Moonlight means three distinct systems for developers, auditors, and users to understand, each with different privacy and control properties. This is also the tooling that has to work before Dusk Network's bigger promise, letting institutions issue regulated securities natively onchain, becomes more than a roadmap line, since that promise only turns real once a specific venue has both the legal authorization and the product design ready to use rails like Zedger. Dusk Network is betting that regulated issuers will value the precision of purpose built tooling over the simplicity of one model doing everything adequately.
#dusk $DUSK @Dusk
That is a genuinely uncomfortable design decision for a privacy first project to make, and I respect that Dusk Network made it openly rather than pretending securities could run on the same rails as private payments. A confidential security contract, what the project calls XSC, needs an issuer to retain certain powers over tokens after they are distributed, because regulated markets require it. Building Zedger as its own model, rather than stretching Phoenix to cover a use case it was never designed for, keeps each system honest about what it actually guarantees.
The tradeoff is complexity. Two transaction models plus a transparent account layer in Moonlight means three distinct systems for developers, auditors, and users to understand, each with different privacy and control properties. This is also the tooling that has to work before Dusk Network's bigger promise, letting institutions issue regulated securities natively onchain, becomes more than a roadmap line, since that promise only turns real once a specific venue has both the legal authorization and the product design ready to use rails like Zedger. Dusk Network is betting that regulated issuers will value the precision of purpose built tooling over the simplicity of one model doing everything adequately.
#dusk $DUSK @Dusk