Went into @Dusk 's Citadel protocol assuming identity-on-chain meant uploading some version of your ID for a provider to read later. The actual flow is narrower. Nothing about you gets stored raw — a License Provider verifies you once, off-chain, then issues a license on-chain tied to that verification. What you actually use afterward is a zero-knowledge proof that says "I hold a valid license," not the data that earned it.
Three roles make this work: the User requesting a license, the License Provider issuing it after verification, and the Service Provider who just confirms the proof is valid. When a user wants access, they submit a ZK proof on-chain, which opens a session and generates a cookie — shared privately with the Service Provider, who checks it against on-chain records and grants or denies access. The Service Provider never sees the original verification data at all.
The comparison that stuck with me: less like handing your ID to every building's front desk, more like a hospital confirming you passed a health screening and giving you something that only proves that fact — not your test results, not your history.
Where "less disclosure" stops being automatically reassuring: everything depends on who's allowed to become a License Provider, how a wrongly-issued license actually gets revoked, and whether a Service Provider quietly collects extra data off-chain anyway. The underlying research treats revocation and unlinkability as designed protocol properties, not afterthoughts — but design guarantees and real-world integration depth aren't the same thing to verify.
For $DUSK, what Citadel is actually worth watching isn't "uses zero-knowledge proofs" as a headline. It's how many real License Providers and Service Providers integrate, and whether proving eligibility without revealing identity holds up once real institutions rely on it.
@Dusk $DUSK #dusk
Three roles make this work: the User requesting a license, the License Provider issuing it after verification, and the Service Provider who just confirms the proof is valid. When a user wants access, they submit a ZK proof on-chain, which opens a session and generates a cookie — shared privately with the Service Provider, who checks it against on-chain records and grants or denies access. The Service Provider never sees the original verification data at all.
The comparison that stuck with me: less like handing your ID to every building's front desk, more like a hospital confirming you passed a health screening and giving you something that only proves that fact — not your test results, not your history.
Where "less disclosure" stops being automatically reassuring: everything depends on who's allowed to become a License Provider, how a wrongly-issued license actually gets revoked, and whether a Service Provider quietly collects extra data off-chain anyway. The underlying research treats revocation and unlinkability as designed protocol properties, not afterthoughts — but design guarantees and real-world integration depth aren't the same thing to verify.
For $DUSK, what Citadel is actually worth watching isn't "uses zero-knowledge proofs" as a headline. It's how many real License Providers and Service Providers integrate, and whether proving eligibility without revealing identity holds up once real institutions rely on it.
@Dusk $DUSK #dusk
