「Atomic Settlement」を見て、私は DvP の難題は“資産レグと決済レグを同時に決着させること”だと思っていた。だが @Dusk の市場インフラに関するドキュメントを改めて整理してみると、より厄介な次の層で止まった。つまり、原子性と確定性は“半端な約定”を消せても、機関が失敗後にどうするかを自動で決めてくれるわけではない、という点だ。

Dusk の公式フレームワークは、アクセス判断、アドレスの帰属、制限付き譲渡、支払いの調整、そして最終決済を同一のマーケット・ワークフローにまとめようとしている。さらに DuskDS は、ブロックで ratification（追認・承認）された後、確定的な最終性を提供する。この組み合わせは、従来の証券決済で最も高コストになりがちな種類の問題を変え得る——当事者が複数台帳の間で何度も「資産は本当に渡ったのか」「お金は本当に届いたのか」を確認し続ける必要がなくなる。

しかし、債券の申込みという一度限りの場面に当てはめると、異常がすぐに顔を出す。投資家はまず資格チェックで通過し、現金は留保され、持分は引き渡し待ちになる。それでも提出時には、資格の有効期限切れ、残高不足、署名者のオフライン、托管（カストディ）API のタイムアウト、あるいは外部の支払い状態が同期していない、といったことが起こり得る。もし 2 本のレグが確かに同一の原子条件で制御されているなら、最良の結果は“同時に成功”または“同時に失敗”だ。しかし「同時に失敗する」ことはオンチェーンの結果であって、業務のクローズドループを完成させるわけではない。

私はここに Dusk 方向性の価値があると考えているが、証拠がまだ足りない——そう感じるのはまさにこの点だ。DuskDS の最終性は、失敗の境界をはっきりさせる。最終ブロックに記録された成功または誤りは、長期にわたり未決のまま宙に浮かないし、実行失敗にも照会可能な結果が残る。とはいえ、Dusk Trade の公式サイトでは当日も Building と表示され、waitlist も公開されている。公開資料からは本番環境での DvP 完了率、異常の分布、あるいは人手介入のデータが示されていない。

リスクも具体的だ。第一に、成熟した許可・認可の監査ツールが不足している場合、プライバシーと選択的開示の問題によって異常調査がかえって遅くなる可能性がある。第二に、資産レグと支払いレグが異なるシステムにまたがるなら、原子性の境界は縮小し、人手による補償が再びプロセスに入り込む。技術的な最終性はあっても、業務上の約束がまだ果たされない、という状態は起こり得る。

あなたは、機関による DvP の検収でまず最初に見るべきなのは A 通常パスの速度、B 異常時の自動復旧、どちらでしょうか？それとも C 異なるシステム間の照合でしょうか？#dusk $DUSK