#dusk $DUSK @Dusk
What I find interesting about Dusk’s privacy design is not just that notes are hidden. It’s where the hiding happens, and how many assumptions must hold at once.

Phoenix uses commitments and a Merkle tree, while value commitments add a blinding factor. Validators can verify consistency without learning the amount. Stealth addresses also make recipient linking harder.

The encryption layer is where I look harder. Current Phoenix exposes AES as its symmetric cipher, while the stack also includes JubJub ElGamal and Poseidon. Dusk’s Poseidon library has encryption functionality, but saying “Poseidon provides confidentiality” is too simplistic. The implementation has evolved, and that matters when judging semantic security.

My real question is whether the composition has been proven as one system. A commitment can hide a value and encryption can hide plaintext, yet privacy can still fail through metadata, key handling, nonce misuse, address correlation, or a flawed proof relation. I’ve seen this before: strong primitives do not automatically make a strong protocol.

Poseidon is built for ZK-friendly computation, while AES is mature for general encryption. That can help performance, but it makes the boundary between encrypt, commit, and prove important.

I’m not ready to trust the construction because the ingredients are respected. I want a formal argument showing note encryption hides values and identities. That is where Dusk’s privacy claim becomes something I can evaluate.