#dusk $DUSK @Dusk
What I find interesting about Dusk’s compliance model is that it treats identity less like something you store and more like something you prove.
Citadel 2 separates the roles cleanly. A license provider verifies the user off-chain and signs the relevant attributes. The credential is registered without exposing its contents, then the user can generate a zero-knowledge proof showing they hold a valid credential without revealing which credential, their identity, or the underlying attributes. The service provider still decides what qualifies and whether access should be granted.
That is a subtle but important distinction from putting KYC data on-chain and calling it compliant. The chain should verify a statement such as “this participant is accredited” or “this holder satisfies the jurisdiction rule,” not permanently expose the passport, address, or birth date behind that statement.
The broader cryptographic direction supports this architecture. W3C’s 2026 Digital Credentials work treats selective disclosure and unlinkable presentations as core privacy properties, while its BBS cryptosuite formalizes derived proofs where holders can reveal chosen claims without making separate presentations trivially linkable.
My view is that Dusk’s difficult problem is no longer whether zero knowledge can hide KYC data. It is designing the policy layer around it: issuer trust, expiry, revocation, jurisdiction changes, wallet binding and anti-correlation.
That is where on-chain compliance becomes interesting: not identity disclosure, but programmable proof of eligibility.
What I find interesting about Dusk’s compliance model is that it treats identity less like something you store and more like something you prove.
Citadel 2 separates the roles cleanly. A license provider verifies the user off-chain and signs the relevant attributes. The credential is registered without exposing its contents, then the user can generate a zero-knowledge proof showing they hold a valid credential without revealing which credential, their identity, or the underlying attributes. The service provider still decides what qualifies and whether access should be granted.
That is a subtle but important distinction from putting KYC data on-chain and calling it compliant. The chain should verify a statement such as “this participant is accredited” or “this holder satisfies the jurisdiction rule,” not permanently expose the passport, address, or birth date behind that statement.
The broader cryptographic direction supports this architecture. W3C’s 2026 Digital Credentials work treats selective disclosure and unlinkable presentations as core privacy properties, while its BBS cryptosuite formalizes derived proofs where holders can reveal chosen claims without making separate presentations trivially linkable.
My view is that Dusk’s difficult problem is no longer whether zero knowledge can hide KYC data. It is designing the policy layer around it: issuer trust, expiry, revocation, jurisdiction changes, wallet binding and anti-correlation.
That is where on-chain compliance becomes interesting: not identity disclosure, but programmable proof of eligibility.
