When watching Citadel2 for $DUSK and seeing the point “Do one KYC and reuse it everywhere,” it really clicked for me. I spent some time calming down and reading the documentation and code repositories before realizing there are prerequisite conditions buried in this.
In short, the whole process looks like this: users complete offline identity verification through the LP to obtain encrypted credentials that are anchored on-chain. Then, when accessing different applications later, they prove their compliance via ZK without exposing any private information.
At first, I thought that once you do a KYC and get credentials, you can use them everywhere. But following Citadel’s protocol logic further, I found a key detail: the Service Provider has the right to decide which License Providers it trusts.
Citadel itself does not require all SPs to accept the same credential standard. For example, Business A may trust the LP that it works with, while Business B may not. If you did the KYC in Business A, but Business B doesn’t accept the credentials issued by that LP, you have to do it again. The scope of “one-time KYC” reuse is naturally limited to a “small circle” where the involved parties mutually recognize the same set of LPs. Once you step outside that circle, reuse no longer works $BTR
I originally wanted to see how the institution-focused integration documentation is written. I looked around—W3sper SDK is indeed there—but for the more complete versions of institution-level integration guides and permission management solutions, I couldn’t find anything sufficiently comprehensive. It’s possible I looked in the wrong places, but at least based on publicly available channels, the bar for institutions to connect directly still isn’t low.
Take the EU’s eIDAS as a comparison: in the real world, identity interoperability has already been moving forward, just not relying on ZK. Citadel’s technical approach is fine, but identity protocols depend heavily on network effects. For the system to run, there need to be a large number of licensed LPs, and SPs across different businesses must be willing to accept those credentials. I tried to find examples of external licensed LPs that have already been deployed in practice, but after looking around, I couldn’t find any clear, publicly available information. It’s also possible that the project is still in an early stage and the information hasn’t been widely disseminated yet. But at least what I can see now is that currently most of the push is being driven by #dusk itself, with little visible trace of external licensed participants.
I won’t draw a negative conclusion for now, but I will keep watching two key signals: external licensed LPs getting deployed, and the JS SDK going live officially. Without seeing these changes, “lifelong reusable KYC” still has a long way to go @Dusk .
In short, the whole process looks like this: users complete offline identity verification through the LP to obtain encrypted credentials that are anchored on-chain. Then, when accessing different applications later, they prove their compliance via ZK without exposing any private information.
At first, I thought that once you do a KYC and get credentials, you can use them everywhere. But following Citadel’s protocol logic further, I found a key detail: the Service Provider has the right to decide which License Providers it trusts.
Citadel itself does not require all SPs to accept the same credential standard. For example, Business A may trust the LP that it works with, while Business B may not. If you did the KYC in Business A, but Business B doesn’t accept the credentials issued by that LP, you have to do it again. The scope of “one-time KYC” reuse is naturally limited to a “small circle” where the involved parties mutually recognize the same set of LPs. Once you step outside that circle, reuse no longer works $BTR
I originally wanted to see how the institution-focused integration documentation is written. I looked around—W3sper SDK is indeed there—but for the more complete versions of institution-level integration guides and permission management solutions, I couldn’t find anything sufficiently comprehensive. It’s possible I looked in the wrong places, but at least based on publicly available channels, the bar for institutions to connect directly still isn’t low.
Take the EU’s eIDAS as a comparison: in the real world, identity interoperability has already been moving forward, just not relying on ZK. Citadel’s technical approach is fine, but identity protocols depend heavily on network effects. For the system to run, there need to be a large number of licensed LPs, and SPs across different businesses must be willing to accept those credentials. I tried to find examples of external licensed LPs that have already been deployed in practice, but after looking around, I couldn’t find any clear, publicly available information. It’s also possible that the project is still in an early stage and the information hasn’t been widely disseminated yet. But at least what I can see now is that currently most of the push is being driven by #dusk itself, with little visible trace of external licensed participants.
I won’t draw a negative conclusion for now, but I will keep watching two key signals: external licensed LPs getting deployed, and the JS SDK going live officially. Without seeing these changes, “lifelong reusable KYC” still has a long way to go @Dusk .