#dusk $DUSK @Dusk
Been sitting with Dusk's compliance layer for a while, and something I initially couldn't confirm turned out to be directly stated after all.
What's clear: Citadel exists to gate specific actions — proving eligibility like residency or accreditation, without exposing full identity, through a three-party protocol between User, License Provider, and Service Provider.
What I was originally uncertain about: which actions actually require that gate versus which stay open. Dusk's own market-infrastructure documentation answers this directly. It states that servicing and disclosure — reporting, corporate actions, selective access to required information — can be implemented differently by different applications, with Dusk providing the protocol building blocks and execution paths, not a fixed, network-wide rule.
That confirms what I'd only suspected before. The gating decision isn't Dusk's protocol mandating "action X always needs a license." It's each application built on Citadel choosing what to gate. NPEX's regulated dApp, actively rolling out on DuskEVM as of 2026, is the clearest live test of this — though I want to be precise that this rollout is ongoing, not a confirmed, fully-completed deployment I can point to as finished proof yet.
It makes me think the deeper question isn't "what does Citadel gate" — it's that Citadel was never meant to answer that question at the protocol level. The answer was always going to sit with whoever issues the asset on top of it.
So "some actions require a license and others don't" isn't really a Dusk-wide policy. It's a per-issuer configuration choice, using tools Dusk built specifically to be configured that way.
Anyway, time will tell 👍
Been sitting with Dusk's compliance layer for a while, and something I initially couldn't confirm turned out to be directly stated after all.
What's clear: Citadel exists to gate specific actions — proving eligibility like residency or accreditation, without exposing full identity, through a three-party protocol between User, License Provider, and Service Provider.
What I was originally uncertain about: which actions actually require that gate versus which stay open. Dusk's own market-infrastructure documentation answers this directly. It states that servicing and disclosure — reporting, corporate actions, selective access to required information — can be implemented differently by different applications, with Dusk providing the protocol building blocks and execution paths, not a fixed, network-wide rule.
That confirms what I'd only suspected before. The gating decision isn't Dusk's protocol mandating "action X always needs a license." It's each application built on Citadel choosing what to gate. NPEX's regulated dApp, actively rolling out on DuskEVM as of 2026, is the clearest live test of this — though I want to be precise that this rollout is ongoing, not a confirmed, fully-completed deployment I can point to as finished proof yet.
It makes me think the deeper question isn't "what does Citadel gate" — it's that Citadel was never meant to answer that question at the protocol level. The answer was always going to sit with whoever issues the asset on top of it.
So "some actions require a license and others don't" isn't really a Dusk-wide policy. It's a per-issuer configuration choice, using tools Dusk built specifically to be configured that way.
Anyway, time will tell 👍