#dusk @Dusk
I used to think that "zero-knowledge KYC" simply meant keeping compliance checks hidden from public view. However, after looking more closely at how Citadel operates, I see that the process is more intentional.
Three parties are involved. A License Provider handles verification off-chain, checks documents, confirms eligibility, and then issues an encrypted license on-chain. Personal records never access the public ledger directly. When a Service Provider needs proof of eligibility, the user creates a zero-knowledge proof that confirms they have a valid, unexpired license, without revealing the details behind it.
What struck me is that #Dusk isn’t the one deciding who is compliant. It serves as the system the proof operates on. The actual decision of trust—determining which License Providers are reliable and which credentials meet specific rules—still lies at the application level, with whoever develops the service.
So it's not really about "blockchain solving KYC"; it's more about "prove it once and reuse the proof everywhere," without having to disclose information every time.
What I haven’t figured out is this: if the system relies on License Providers being trustworthy, doesn’t the real risk shift upstream—from "who sees my data on-chain" to "who do I trust to issue the credential in the first place"?
#dusk $DUSK @Dusk
I used to think that "zero-knowledge KYC" simply meant keeping compliance checks hidden from public view. However, after looking more closely at how Citadel operates, I see that the process is more intentional.
Three parties are involved. A License Provider handles verification off-chain, checks documents, confirms eligibility, and then issues an encrypted license on-chain. Personal records never access the public ledger directly. When a Service Provider needs proof of eligibility, the user creates a zero-knowledge proof that confirms they have a valid, unexpired license, without revealing the details behind it.
What struck me is that #Dusk isn’t the one deciding who is compliant. It serves as the system the proof operates on. The actual decision of trust—determining which License Providers are reliable and which credentials meet specific rules—still lies at the application level, with whoever develops the service.
So it's not really about "blockchain solving KYC"; it's more about "prove it once and reuse the proof everywhere," without having to disclose information every time.
What I haven’t figured out is this: if the system relies on License Providers being trustworthy, doesn’t the real risk shift upstream—from "who sees my data on-chain" to "who do I trust to issue the credential in the first place"?
#dusk $DUSK @Dusk