Network went digging into "auditor access" because it's usually the vaguest part of any privacy-coin pitch. Wanted the actual mechanism, not the phrase.
Dusk runs two transaction models side by side: Moonlight (fully public, like a normal account model) and Phoenix (shielded, confidential balances/transfers). You pick per-transaction. That part's straightforward.
The part I didn't expect: disclosure to an auditor isn't "the auditor gets a master key to everything." Per Dusk's own writeup, a user encrypts the transaction payload with a user key, then encrypts that user key with the auditor's key — so only the specific auditor can unlock it. A zero-knowledge proof then confirms the auditor key was actually used correctly, without exposing the payload to anyone verifying the chain.
So it's transaction-by-transaction, key-specific disclosure, not a backdoor sitting on the whole system. No auditor key = no access, full stop, even for the network's own validators.
The gap I couldn't fully close: docs describe this at the Citadel identity layer, but I didn't find a public case of a regulator actually pulling data through this flow on mainnet yet. It reads solid on paper, but "auditor decrypts one transaction via provable encryption" and "a regulator's actual workflow during a live audit" are two different tests.
Has anyone seen this triggered in an actual compliance scenario, not just documented as a capability
#dusk $DUSK #dusk $DUSK
Dusk runs two transaction models side by side: Moonlight (fully public, like a normal account model) and Phoenix (shielded, confidential balances/transfers). You pick per-transaction. That part's straightforward.
The part I didn't expect: disclosure to an auditor isn't "the auditor gets a master key to everything." Per Dusk's own writeup, a user encrypts the transaction payload with a user key, then encrypts that user key with the auditor's key — so only the specific auditor can unlock it. A zero-knowledge proof then confirms the auditor key was actually used correctly, without exposing the payload to anyone verifying the chain.
So it's transaction-by-transaction, key-specific disclosure, not a backdoor sitting on the whole system. No auditor key = no access, full stop, even for the network's own validators.
The gap I couldn't fully close: docs describe this at the Citadel identity layer, but I didn't find a public case of a regulator actually pulling data through this flow on mainnet yet. It reads solid on paper, but "auditor decrypts one transaction via provable encryption" and "a regulator's actual workflow during a live audit" are two different tests.
Has anyone seen this triggered in an actual compliance scenario, not just documented as a capability
#dusk $DUSK #dusk $DUSK