$DUSK @Dusk I went down a bit of a Dusk docs rabbit hole tonight and ended up connecting two things I initially thought were completely unrelated: Citadel 2 and Dusk Improvement Proposals (DIPs).
Citadel 2 tackles a very practical identity problem.
A trusted License Provider verifies a user off-chain and signs the relevant attributes. The user can later generate a zero-knowledge proof showing they hold a valid registered license, without putting their personal details or the exact license used on-chain.
What I found important is that Citadel doesn't decide whether someone gets access.
The Service Provider still decides which providers it trusts, which attributes are acceptable, and whether a session is expired or revoked.
Then I looked at the DIP process.
DIPs are Dusk’s structured way of proposing protocol changes, covering everything from consensus and transaction processing to new standards and features. A proposal moves through Idea → Draft → Feedback → Staging → Active, with technical specifications, rationale, security considerations, testing, and implementation details forming part of the process.
If a technical proposal reaches staging, it can be tested on Nocturne before being incorporated into production after consensus.
The connection I see is pretty interesting:
Citadel 2 is about proving the right thing without exposing unnecessary identity data.
DIPs are about changing the protocol through a process where the proposed changes can be examined and challenged.
One focuses on privacy-preserving identity.
The other focuses on how the underlying protocol evolves.
For infrastructure aimed at regulated applications, I think both sides matter.
Privacy needs strong cryptography.
Protocol evolution needs strong review.
#dusk
Citadel 2 tackles a very practical identity problem.
A trusted License Provider verifies a user off-chain and signs the relevant attributes. The user can later generate a zero-knowledge proof showing they hold a valid registered license, without putting their personal details or the exact license used on-chain.
What I found important is that Citadel doesn't decide whether someone gets access.
The Service Provider still decides which providers it trusts, which attributes are acceptable, and whether a session is expired or revoked.
Then I looked at the DIP process.
DIPs are Dusk’s structured way of proposing protocol changes, covering everything from consensus and transaction processing to new standards and features. A proposal moves through Idea → Draft → Feedback → Staging → Active, with technical specifications, rationale, security considerations, testing, and implementation details forming part of the process.
If a technical proposal reaches staging, it can be tested on Nocturne before being incorporated into production after consensus.
The connection I see is pretty interesting:
Citadel 2 is about proving the right thing without exposing unnecessary identity data.
DIPs are about changing the protocol through a process where the proposed changes can be examined and challenged.
One focuses on privacy-preserving identity.
The other focuses on how the underlying protocol evolves.
For infrastructure aimed at regulated applications, I think both sides matter.
Privacy needs strong cryptography.
Protocol evolution needs strong review.
#dusk