Six things a Citadel session never puts onchain: your wallet key, the license you used, the issuer and service keys, the signed attributes, and the Merkle proof path. What does go onchain is one session. Public, verifiable, dull.
@Dusk files this under selective disclosure, and it isn't a privacy toggle. A License Provider checks you off-chain, signs your attributes, publishes an encrypted license, and registers it in a Citadel contract. Later you prove in zero knowledge that you hold a registered license. Not which license. Just that it exists. The contract verifies, records a session, and you hand a session cookie to the service.
Then the docs draw a line, plainly. Citadel proves the session is cryptographically valid. It does not decide service policy. The service still picks which issuers it trusts, which attributes it accepts, whether the session is revoked, whether that cookie works twice.
My day job is testing a securities trading app, and that split reads like something copied off my desk. Nobody there sees the whole picture, on purpose. The user sees their own order. Back office sees the batch. The depository sees a settlement instruction. The supervisor pulls a report on request. Four views of one trade, sorted out long before anyone wrote a proof circuit.
My take: the valuable part of Citadel isn't the cryptography, it's the refusal. A chain that decided eligibility for you is one no venue could adopt. Eligibility is jurisdiction, product terms and issuer risk appetite. None of that should need a hard fork.
Does that make an app on Dusk compliant? No. Someone still has to be the License Provider, run the off-chain checks, and answer when a check was wrong. Tooling today: a Rust library, the license contract, a wallet CLI, and a JavaScript SDK still listed as coming. $DUSK pays gas and secures the network by staking.
So who should hold that License Provider role for a regulated asset: the venue, the issuer, or a third party whose only job is checking? I keep landing on the third, without a clean reason.
#dusk
@Dusk files this under selective disclosure, and it isn't a privacy toggle. A License Provider checks you off-chain, signs your attributes, publishes an encrypted license, and registers it in a Citadel contract. Later you prove in zero knowledge that you hold a registered license. Not which license. Just that it exists. The contract verifies, records a session, and you hand a session cookie to the service.
Then the docs draw a line, plainly. Citadel proves the session is cryptographically valid. It does not decide service policy. The service still picks which issuers it trusts, which attributes it accepts, whether the session is revoked, whether that cookie works twice.
My day job is testing a securities trading app, and that split reads like something copied off my desk. Nobody there sees the whole picture, on purpose. The user sees their own order. Back office sees the batch. The depository sees a settlement instruction. The supervisor pulls a report on request. Four views of one trade, sorted out long before anyone wrote a proof circuit.
My take: the valuable part of Citadel isn't the cryptography, it's the refusal. A chain that decided eligibility for you is one no venue could adopt. Eligibility is jurisdiction, product terms and issuer risk appetite. None of that should need a hard fork.
Does that make an app on Dusk compliant? No. Someone still has to be the License Provider, run the off-chain checks, and answer when a check was wrong. Tooling today: a Rust library, the license contract, a wallet CLI, and a JavaScript SDK still listed as coming. $DUSK pays gas and secures the network by staking.
So who should hold that License Provider role for a regulated asset: the venue, the issuer, or a third party whose only job is checking? I keep landing on the third, without a clean reason.
#dusk
