Citadelのセッションが決してオンチェーンに載せないもの：ウォレット鍵、使用したライセンス、発行者鍵とサービス鍵、署名された属性、そしてMerkleプルーフのパス。オンチェーンに行くのは「1つのセッション」だけです。公開され、検証可能で、退屈です。

@Dusk はこれを「選択的開示」に分類していますが、プライバシーの切り替えではありません。ライセンス・プロバイダーはオフチェーンであなたをチェックし、属性に署名し、暗号化されたライセンスを公開し、それをCitadelのコントラクトに登録します。その後、あなたはゼロ知識で「登録されたライセンスを持っている」ことを証明します。どのライセンスかではありません。存在することだけです。コントラクトは検証し、セッションを記録し、あなたはそのセッション・クッキーをサービスへ渡します。

そしてドキュメントは、はっきり線を引きます。Citadelは、セッションが暗号学的に有効であることを証明します。サービスのポリシーは決めません。サービスは依然として、どの発行者を信頼するか、どの属性を受け入れるか、セッションが無効化（リボーク）されていないか、そしてそのクッキーが2回使えるかどうかを選びます。

私の仕事は証券取引アプリのテストで、この分岐は机からそのまま写したように見えます。そこでは、意図的に全体像を誰も見ません。ユーザーは自分の注文を見る。バックオフィスはバッチを見る。預託機関（デポジタリー）は決済指図を見る。監督者は必要に応じてレポートを引き出す。1つの取引に対して4つの見え方があり、誰かが証明回路を書くずっと前に整理されていました。

私の見立て：Citadelの価値ある部分は暗号技術ではなく「拒否」です。あなたの適格性を決めるチェーンは、どの取引所（会場）にも採用され得ないものです。適格性は、管轄、製品の条件、そして発行者のリスク嗜好です。これらがハードフォークを必要とするべきではありません。

Dusk上のアプリはコンプライアンス対応になる？いいえ。誰かが依然としてライセンス・プロバイダー役を担い、オフチェーンのチェックを実行し、どのチェックが誤っていたのかを答えなければなりません。今日のツール：Rustライブラリ、ライセンスのコントラクト、ウォレットCLI、そしてJavaScript SDK（今後提供予定として掲載）。$DUSK はガスを支払い、ステーキングによってネットワークを保護します。

では、規制対象の資産におけるそのライセンス・プロバイダー役を誰が持つべきか：取引所（会場）か、発行者か、それともチェックだけを仕事とする第三者か。私は理由がすっきりしないまま、第三者に行き着き続けています。

#dusk