Today I spent the whole afternoon poring over Dusk Network to take part in the Creatorpad program of the project on Binance.

There’s one detail that made me re-read Dusk Network’s privacy section. “Selective Disclosure” sounds quite simple: keep private data private, but disclose it when needed. However, when I went through the docs, the way Dusk breaks down the components is different from what I initially imagined.

Dusk currently describes privacy in three directions: a public account with Moonlight, shielded transactions with Phoenix, and selective disclosure when an authorized party needs evidence.

I delved into Citadel because the docs specify that it’s the identity and access layer for selective disclosure. Citadel uses zero-knowledge proofs so users can prove they have a valid license without having to publicly reveal all identifying information.

The noteworthy point here is: in the docs, for example, it doesn’t say “disclose the entire identity.” The user creates a proof, and then the service provider checks the validity of the authorization through Citadel’s process.

Hold on—so that still doesn’t mean that every piece of data on Dusk is automatically and selectively disclosed. The docs only describe the primitives and patterns so application builders can create workflows that fit.

Maybe this is the key takeaway I need to keep: Dusk’s Selective Disclosure isn’t “privacy but with a public toggle,” but a way to separate the ability to prove some information from the act of publicly disclosing all information.

So the next question becomes more interesting: how far are these primitives actually implemented in real-world applications?
#dusk $DUSK @Dusk $BTC