MICHAEL MOORE

14日前、好奇心のまま@Dusk について読み始めました。2週間後もまだ読み続けているとは思っていませんでした。

私を何度も引き戻したのは、大きな見出し一つではありませんでした。実際に探してみると、細かく具体的な設計上の選択が、どれだけ多く繰り返し出てくるか――それでした。Zedgerが配当分配を構築し、送金の上限を直接セキュリティトークンへ組み込んでいたのに、後付けではない。Citadelが、誰なのかを渡さずに資格を満たしていることを証明できるようにしていたこと。以前はパブリックとプライベートの間を移すのに2つのトランザクションが必要だったconvert関数が、今では1つになっていたこと。

特に印象に残ったのは、Dusk自身が「大きなセールスポイントとしての分数所有に異議を唱える」ような自社の記述でした。資料では、価値の本体は“発行から決済まで”などライフサイクル全体を、1つの記録の周りでつなぐことだと言っていました。トークン化された証券を売りに出すプロジェクトから、そんな提案が来るとは予想していなかったのです。

そしてXSC規格そのもの。権限を3つの別々の役割に分散し、単一の当事者が同時に「見て」「承認して」「所有権を付け替える」ことができないようにしている。さらに今週、銀行・取引所・カストディアンがそれぞれ互いのデータを見ないまま、同一の取引を検証しているのを目にしました。

これらはどれも大声ではありません。画期的だと呼べる“決定的な瞬間”は一つもない。あるのは、より静かな14の観察です。まとめて見ると、プライバシーと規制を、対立するものではなく同じ設計上の課題として扱うプロジェクトの姿が描かれている。

きちんとした結論はありません。始めたときよりも長い質問リストを手元に抱えている――そしてそれこそが、ここで終えるためのいちばん正直な場所だと感じます。

他人のドキュメントを14日間読むのは、時間を上手く使ったと表現するのが普通ではありません。でも今回はそうでした。このプロジェクトの次に何が来るかは分かりませんが、少なくとも私は、ただスクロールして通り過ぎるのではなく、実際に探してみたことを嬉しく思っています。

#dusk $DUSK

#dusk 昨夜、Xでアップデートをスクロールしていたら、Duskのある投稿に立ち止まらされました。私はそれを読み進めました。

そして目を引かれたのが、投稿と一緒に共有されていたグラフィックです。

Dusk自身がXで共有した投稿によれば、銀行は支払指図と認可を見ます。取引所は適格性の証明だけを見ます。カストディアンは資産の記録と決済ステータスを見ます。この3者はいずれも、相手が見ているものは見えません。彼らの特定の領域の外にある情報は、当事者それぞれの言葉で「開示されていない（not disclosed）」としてマークされたままになります。

私はこれまで、このような形でのセレクティブ・ディスクロージャー（選択的開示）のことを考えたことがありませんでした。Day 3は、単一の人物が身元をさらすことなく適格性を証明することがテーマでした。今回は違います。同じ取引が複数の機関によって同時に検証され、それぞれが自分の範囲以外は見えないという点が同じです。

これは、ある1人が自分のデータを1つのサービスから隠すよりも難しい連携の問題です。3つの別々の当事者が、誰も全体を見ないまま、その取引が有効であることを同じように信頼しなければなりません。

私にとって不明なのは、ある当事者の狭い見え方だけでは、3つのスライスすべてを同時に見たときに初めて分かる問題を見つけられない場合に、紛争がどう解決されるのかという点です。

$DUSK @Dusk

今日、技術的な内訳（ブレイクダウン）が始まる前の、ダスクの「市場インフラ」ページに戻って確認しました。

ダスク自身のドキュメントによると、規制対象の市場は「トークンを作って送る（transferする）」だけで済むことはほとんどありません。そのトークンを取り巻く手順、適格性（エリジビリティ）、開示（ディスクロージャ）、決済（セトルメント）がそれぞれ別のシステムに分かれていると、参加者は照合（リコンサイル）、手動の統制、そしてオフチェーンでの調整を行って、すべてがきちんと整うようにしなければならなくなります。

これまで私は、トークン化された有価証券の難しさはトークン・コントラクトそのもの、つまりコードを正しく書き、送金（トランスファー）でルールを強制することにあるのだと思い込んでいました。しかし、彼らのドキュメントはそれに反論しています。トークン自体は本当のところ、難しい部分ではありません。難しいのは、その周辺で起こることです。所有権（オーナーシップ）、適格性、決済を、互いに会話するために作られていない複数のシステム間で同期させ続ける必要があるのです。

このことによって、ここで言う「インフラ」がそもそも何を意味するのかが見え直されます。普通の金融の横に「スマートコントラクトの標準」が並ぶ話ではありません。資産だけでなく、調整（コーディネーション）そのものを、ひとつのシステムの中に閉じ込めようとする試みなのです。

それでも分かっていないのは、その照合（リコンサイル）の問題のうち、どれくらいが実際には解消されるのか、それとも単に、より前段（イシューアが最初にワークフローをどう設定するか）へ移動するだけなのか、という点です。
#dusk $DUSK @Dusk

#dusk 今日は、実際のXSC標準文書そのもの（要約ではなく元の資料）を探しに行った。

DuskのXSC標準文書のセクション2.1によると、その標準では4つの明確な役割を定義している。契約所有者（Contract Owner）、契約利用者（Contract User）、プラットフォーム利用者（Platform User）。そして第三者（Third Party）カテゴリはさらに3つの具体的な役割に分かれている。閲覧のみ（View Only）、共同署名（Co-sign）、そしてガード（Guard）。

これは文書の中で意図的に、直接示されている。暗号化されたデータを見るには1つの役割が必要である。機密性の高い行為を承認するには別の役割が必要である。契約の所有権を再割り当てするにはさらに別の役割が必要だ。

自分はこれを、たいていのトークン標準が権限をどう定義しているかと比べ続けている。通常は、単一のオーナーまたは管理者アドレスがすべてに広範な権限を持つ形だ。権限を3つの異なる、より狭い役割に分割するというのは別の設計判断であり、同じ契約に対して異なる、限定された関係をそれぞれ複数の規制当局が持つ必要があることに起因している。

ただし、文書が明示していないのは、「ある法域（jurisdiction）が、どの機関にどの役割を割り当てるのか」や、「規制当局が3つのうち複数を同時に保有することがあるのか」といった点だ。設計として権限が分割されていて、1つのアドレスに集中していない——その部分こそ、腰を据えて考える価値がある。$DUSK @Dusk

#dusk 私はDuskの市場インフラのページで、同じセクションを2回読み返しました。
そこには、規制対象資産が通過する6つの段階が記載されています。発行体のセットアップ、投資家のオンボーディング、譲渡のコントロール、取引、決済、そしてサービシングと開示です。単体で見れば、そこは特に変わったところはありません。

私を止めたのは、そのリストの直前の1行でした。
Dusk自身のドキュメントによれば、目的は、すべてのワークフローを非公開にすることでも、すべてのワークフローを公開にすることでもありません。何が可視で、何が機密で、そして特定の当事者に何が開示されるのかは、アプリケーション全体で一度に決まるのではなく、段階ごとに決まるのだということです。

私はプライバシーを、製品全体に対して選ぶ設定だと捉えていました。しかしこれは、各ステップごとにリセットされる「ダイヤル」に近いものとして再解釈させる内容でした。たとえばオンボーディングは、投資家の身元を守るため機密のままにするかもしれません。一方で決済は、規制当局が「実際に行われた」と信頼できる程度に可視である必要があるかもしれません。

ページだけでは分からないのは、その段階ごとの判断を実際に誰が行っているのかです。発行体がワークフローを設計するのか、それともプロトコルがビルダーを促すようなデフォルトに近い何かなのか。

$DUSK @Dusk

#dusk $DUSK @Dusk 何か小さなものが、Duskの最新の進捗アップデートを読んだ後、ずっと私のところへ戻ってきた。目を通したセーフガードの一覧の中に、ひとつの行があった――「価値を移動するPhoenixのトランザクションは、今ではデフォルトで秘匿される」。Dusk自身が2026年7月に出したアップデートによれば、これは、ウォレットによって作成・検証・取り扱いが行われるプライベート取引のあり方をより強固にする、より大きなハードニングの一環として実装されたものだ。

私は「デフォルトで秘匿される」というその一文を、アップデート全体の他の部分よりも長く噛みしめた。「今では（now）」という語が果たしている役割が大きすぎて、私はそれが静かに対比しているものは何なのか、と気になってしまう。
この問いの重みは、金融アプリケーションのために作られたシステムであるなら、他の場面よりもずっと増す。送金という、ごく当たり前のことをウォレットが実行するのに、送信者が設定を正しく選べているかに依存すべきではない。実際に体験するのは、だいたいの場合デフォルトの挙動だ。

そのアップデートでは、この変更が近いネットワークのアップグレードに合わせて適用され、さらに不正形（malformed）なトランザクションデータの拒否が厳格化されるとも述べられている。ただ、私にまだ分からないのは、その「デフォルト」という状態を、アップデートが何に対して比較しているのか、あるいはそもそもその問いの立て方が正しいのかどうかだ。