#dusk $DUSK @Dusk Translate @DuskNetwork documentation: When I read it, I had a very simple question at first—why would a single chain need to maintain three different transaction models at the same time?
Moonlight is fully public, Phoenix is fully private, and Zedger is the strangest: externally, it only exposes one root hash. Intuitively, wouldn’t a one-size-fits-all approach work?
But after going through the full design, I realized this wasn’t about accommodating different scenarios—it was about hard-wiring a gradient of information disclosure into the protocol layer.
DUSK’s real goal isn’t to build a “privacy chain,” but a chain that can issue securities. Securities come inherently with regulatory obligations that conflict with privacy: KYC, transfer restrictions, and mandatory buybacks. In a pure privacy model, where you don’t even know who the holders are, how do you pay dividends?
That’s exactly what Zedger solves: keep the ledger details locally, while only publishing the root hash on-chain. It hides information externally, yet allows issuers or regulators who obtain a view key to audit.
The Citadel protocol further completes the identity layer: it uses private NFTs to carry KYC credentials. Users use zero-knowledge proofs to demonstrate to the service provider that they meet the requirements—without revealing their specific identities. These three trust domains—public, regulators, and service providers—see information at completely different granularities.
DUSK has done something that most privacy chains haven’t: encoding regulatory rules into cryptographic structures.
What I care about more is the evolution path afterward.
After RWA is massively onboarded, will we see “compliance arbitrage”? For example, issuers could force security tokens to use Zedger, with view keys being escrowed and written into contract terms. If users can only rely on exchanges to custody view keys, will the protocol’s carefully designed “user-controlled disclosure right” end up becoming mere formalism?
Going further: if regulators require that “all RWAs must support real-time audit,” and the holder of the view key shifts from “users” to “licensed custodial institutions,” would DUSK’s privacy gradient collapse into “privacy from the public, transparency to regulators, and full exposure to custodians”? Zero-knowledge proofs would still be running, but the privacy boundary would drift from “user control” to “compliance configuration.”
What do you think? Let’s chat in the comments.
Moonlight is fully public, Phoenix is fully private, and Zedger is the strangest: externally, it only exposes one root hash. Intuitively, wouldn’t a one-size-fits-all approach work?
But after going through the full design, I realized this wasn’t about accommodating different scenarios—it was about hard-wiring a gradient of information disclosure into the protocol layer.
DUSK’s real goal isn’t to build a “privacy chain,” but a chain that can issue securities. Securities come inherently with regulatory obligations that conflict with privacy: KYC, transfer restrictions, and mandatory buybacks. In a pure privacy model, where you don’t even know who the holders are, how do you pay dividends?
That’s exactly what Zedger solves: keep the ledger details locally, while only publishing the root hash on-chain. It hides information externally, yet allows issuers or regulators who obtain a view key to audit.
The Citadel protocol further completes the identity layer: it uses private NFTs to carry KYC credentials. Users use zero-knowledge proofs to demonstrate to the service provider that they meet the requirements—without revealing their specific identities. These three trust domains—public, regulators, and service providers—see information at completely different granularities.
DUSK has done something that most privacy chains haven’t: encoding regulatory rules into cryptographic structures.
What I care about more is the evolution path afterward.
After RWA is massively onboarded, will we see “compliance arbitrage”? For example, issuers could force security tokens to use Zedger, with view keys being escrowed and written into contract terms. If users can only rely on exchanges to custody view keys, will the protocol’s carefully designed “user-controlled disclosure right” end up becoming mere formalism?
Going further: if regulators require that “all RWAs must support real-time audit,” and the holder of the view key shifts from “users” to “licensed custodial institutions,” would DUSK’s privacy gradient collapse into “privacy from the public, transparency to regulators, and full exposure to custodians”? Zero-knowledge proofs would still be running, but the privacy boundary would drift from “user control” to “compliance configuration.”
What do you think? Let’s chat in the comments.