昨晚、資産決済の自動化スクリプトを一式走らせたあと、暇つぶしに @Dusk の Zedger で使われている証券トークンのモデルを掘り返してみた。ところが、インタラクションの細部を読んでいて、古いタイプの（コード書き）人間としては一瞬「ん？」となりかけた——Dusk 上で証券資産を振り込む際、受取人側が明示的に「同意」をタップしないと、送金が本当に完了したことにならず、資産がずっと元のアドレスにぶら下がったままになるのだ。以前 EVM チェーンで「発行＝即チェーンに載って、秒で着金」みたいな体験に慣れていたせいで、最初の反応はこうだった。これ、わざわざ手間を増やす設計じゃないか？ 発メールでの確認が当たり前だった時代に逆戻りしてるんじゃないのか？

でも自分は常に「命あっての物種」を信条にしているので、落ち着いてこのロジックを従来の証券の登記・決済（クリアリング＆セトルメント）の流れと突き合わせてみたら、ようやく腑に落ちた。コンプライアンスが絡む金融では、株式の名義移転は一方的な送金ではなく、登記・決済機関が買い手の資格を確認したうえで、名簿を書き換えるものだ。Dusk はここを協定（プロトコル）層に「双方向の確認」として直接埋め込んでいる。ホワイトリスト要件に合わない、または当事者が主導で署名していない場合、その“株主”としての身分は受け取れない。

よく考えると、これによって致命的な痛点が三つすべて潰されている。第一に粉塵攻撃で、従来はどんなゴミみたいなエアドロ風トークンでもあなたのアドレスに押し込めてしまうことがあったが、Zedger では拒否される。第二にコンプライアンス上の責任分界で、同意なしの保有は成立せず、責任の境界がはっきりする。第三に決済の揉め事で、従来の DvP（同時決済、貨幣と証券の引き換え）の時間差によるごたごたを根本的に解消し、署名した時点で決着するので、中間状態で揉める余地がなくなる。

ただし開発者の観点では、懸念もある。1件ごとに署名インタラクションがもう一回増えるので、高頻度のスクリプト稼働やバッチ自動化で日常的に処理する人にとっては、摩擦コストが現実に効いてくる。今後 Dusk が「厳格で明示的な承認」と「大量の自動化決済」の間で、どんなエンジニアリング上のバランスを取るのか——それは引き続きコードベースを注視したい。

皆さんは、この種の「合規のために多少の操作の滑らかさを犠牲にする」確認（受領確認）設計を、機関投資家は納得して買うと思う？ コメント欄で話そう。

@Dusk #dusk $DUSK