Spent some time actually working through how Citadel's licensing flow resolves compliance without an identity leak, and the mechanism is more interesting than the "privacy-preserving KYC" one-liner suggests.
A License Provider — think a regulated onboarding entity — checks a user off-chain the normal way, then signs an attestation over specific attributes and registers an encrypted license on-chain. The user never re-uploads documents to every service they want to use. Instead, when a Service Provider needs proof of eligibility, the user generates a zero-knowledge proof that they hold a valid, provider-signed license — without revealing the wallet, the underlying attributes, or which specific license produced the proof. The Service Provider verifies the proof and records a session, not an identity.
What's actually being decentralized here isn't the compliance decision — it's the disclosure event. The trust question doesn't disappear; it relocates. The Service Provider still decides which License Providers it trusts and which attributes satisfy its rules. Citadel doesn't replace regulatory judgment, it removes the requirement that judgment be exercised on raw personal data every single time.
The detail worth flagging: this is a repeat verification model, not a one-time badge. Sessions expire, get revoked, or need refreshing as eligibility conditions change. For a security-token platform, that recurring proof-of-still-qualified is arguably closer to the actual product than the privacy layer sitting on top of it — a regulated venue doesn't just need to know you were eligible once, it needs continuous assurance nothing material has changed.
So the honest framing is: Citadel moves the single point of trust from "every counterparty who sees your data" to "the handful of License Providers whose signature everyone accepts." Is that a smaller attack surface, or just a more concentrated one?
#dusk $DUSK @Dusk
A License Provider — think a regulated onboarding entity — checks a user off-chain the normal way, then signs an attestation over specific attributes and registers an encrypted license on-chain. The user never re-uploads documents to every service they want to use. Instead, when a Service Provider needs proof of eligibility, the user generates a zero-knowledge proof that they hold a valid, provider-signed license — without revealing the wallet, the underlying attributes, or which specific license produced the proof. The Service Provider verifies the proof and records a session, not an identity.
What's actually being decentralized here isn't the compliance decision — it's the disclosure event. The trust question doesn't disappear; it relocates. The Service Provider still decides which License Providers it trusts and which attributes satisfy its rules. Citadel doesn't replace regulatory judgment, it removes the requirement that judgment be exercised on raw personal data every single time.
The detail worth flagging: this is a repeat verification model, not a one-time badge. Sessions expire, get revoked, or need refreshing as eligibility conditions change. For a security-token platform, that recurring proof-of-still-qualified is arguably closer to the actual product than the privacy layer sitting on top of it — a regulated venue doesn't just need to know you were eligible once, it needs continuous assurance nothing material has changed.
So the honest framing is: Citadel moves the single point of trust from "every counterparty who sees your data" to "the handful of License Providers whose signature everyone accepts." Is that a smaller attack surface, or just a more concentrated one?
#dusk $DUSK @Dusk