What caught my attention is that Dusk’s privacy model can leave an authorization event visible while keeping the identity evidence behind it hidden.
In Citadel 2, a user proves with zero knowledge that they hold a registered, provider-signed credential. The contract verifies that proof and records a public session. But Dusk’s docs say that session does not expose the wallet key, the specific license used, the license-provider key, the service-provider key, signed attributes, or the Merkle proof path.
That is a more interesting design choice than simply saying “private KYC.”
I expected the blockchain itself to decide whether a user is compliant. It doesn’t. Citadel proves that the credential/session is cryptographically valid; the service provider still decides which credential issuers it trusts, which attributes satisfy its policy, whether a session is expired or revoked, and whether a session cookie can be reused.
To me, that separation matters for financial applications. Privacy is handled by the proof system, while business and regulatory policy remains configurable at the application layer rather than being frozen into one universal rule.
That also creates a real trade-off: flexibility is useful, but security depends on service providers defining those policies correctly.
For dusk_foundation and DUSK, the part I’m watching is not just whether credentials stay private, but how consistently real applications implement the policy layer around them.
@Dusk $DUSK #dusk
In Citadel 2, a user proves with zero knowledge that they hold a registered, provider-signed credential. The contract verifies that proof and records a public session. But Dusk’s docs say that session does not expose the wallet key, the specific license used, the license-provider key, the service-provider key, signed attributes, or the Merkle proof path.
That is a more interesting design choice than simply saying “private KYC.”
I expected the blockchain itself to decide whether a user is compliant. It doesn’t. Citadel proves that the credential/session is cryptographically valid; the service provider still decides which credential issuers it trusts, which attributes satisfy its policy, whether a session is expired or revoked, and whether a session cookie can be reused.
To me, that separation matters for financial applications. Privacy is handled by the proof system, while business and regulatory policy remains configurable at the application layer rather than being frozen into one universal rule.
That also creates a real trade-off: flexibility is useful, but security depends on service providers defining those policies correctly.
For dusk_foundation and DUSK, the part I’m watching is not just whether credentials stay private, but how consistently real applications implement the policy layer around them.
@Dusk $DUSK #dusk
