市場以外の業務システム

QOMM は指図の発行元の一つである。価格を決めて指図を発行する市場、という位置づけである。「誰が、何を、どの条件で動かしてよいか」を決める業務システムなら、他のものも同じことができる。その判断を zkPI に載せ、DeFMI に決済させる。DeFMI は入力を読まない。秘匿の見積も、MPC による値付けも、メイカーとテイカーも要らない。

出典: defmi/doc/ja/DEFMI_ZKPI_USE_CASES.md（2026-08-30 時点の調査）

形が合うとき

次の三つの条件がそろう業務が向いている。

決済の前に、資格、限度、担保、契約条件のいずれかを確認しなければならない。
その確認に使う個人情報、保有、金額、内部の判断を、決済参加者の全員に見せてはならない。
条件が満たされた後は、二つの脚（受け渡しと支払い）のどちらか一方だけが実行されることはない。また、どの指図も二度は使われない。

flowchart LR
    F["ファンド管理者
資格と口数"]
    C["担保・リスクエンジン
必要証拠金"]
    B["銀行と制裁審査
越境支払を承認"]
    R["登録機関、発行者、カストディアン
権利の移転を承認"]
    F --> Z["zkPI
判断とその証明を運ぶ"]
    C --> Z
    B --> Z
    R --> Z
    Z --> D["DeFMI
一度検証し、一度決済する"]
    D --> A["資金、預金、証券、口数、担保
二つの権利を同時に更新"]

実現しやすい順

#	用途	誰が zkPI を発行するか	最も近い先行例	検証すべき差
1	ファンドの申込、解約、キャピタル・コール	トランスファー・エージェント、ファンド管理者、KYC 提供者が共同で発行する。確認する内容: 資格が有効、金額が規則と投資家ごとの上限の範囲内、資金が予約済み、口数が発行可能、基準価額（NAV）の時点が確定	Project Guardian（MAS）が DLT 上で申込と支払を自動化している	資格、個別の上限、金額を決済参加者から隠す。別のファンドシステムが出した一回限りの指図を、運営者のいない台帳が決済する
2	担保と証拠金: 差入、差替、返還	資格・ヘアカット・集中度の承認済み回路を持つ担保エンジン。ポートフォリオを見せずに、要件を満たしていることを証明する	トライパーティ担保、CCP の証拠金請求	秘密のポートフォリオについて、担保が要件を満たすことの証明。同時に届く請求の順序付けと、正本の状態の中で法人ごとの上限を守ること
3	銀行間および越境 PvP	二つの発行者と二つの資金予約を一つの指図に束縛する。制裁と権限の審査は証明として載せる	Fnality、Partior、mBridge、Project Agorá	adaptor signature（片方の署名が完成すると他方の署名も導ける仕組み）による PvP。台帳ごとに無関係な署名を用いる。片脚だけが済んでいる時間（露出窓）は finality（決済の確定）で決まり、証明では決まらない
4	発行、償還、利払、配当	発行者と支払代理人	デジタル債券プログラム（SDX、eWpG の登録簿）	保有者の集合と金額を隠す。コーポレート・アクションの前後で総量が保存されること
5	不動産と高額資産の移転	登録機関とエスクロー業者	権原トークン化の実証	登録簿が外部にあり、DeFMI がそれを写す形の DvP
6	政府・国際機関の約束手形、拠出金、補助金	国庫と支出機関	—	資格を隠したままの条件付き支出
7	債権とインボイス金融	Aethel 型の債権システム	サプライチェーン金融のプラットフォーム	Aethel のページを参照
8	環境・コモディティ証書: 発行と償却	登録簿の運営者	炭素登録簿	償却を一回限りの nullifier（同じ権利を二度使えなくする使用済みの印）として扱う。保有者を隠す
9	保険金請求と給付の支払	保険者と査定者	パラメトリック保険	請求条件を証明し、請求者の情報は出さない

最も実用に近いのは 1 番目である。二つのものが同時に動くだけなので、DeFMI の DvP をそのまま使え、役割も少ない。研究課題として最も強いのは 2 番目、秘密のポートフォリオに対する充足の証明である。長期的に最も大きな事業になるのは 3 番目である。

混同してはならない二つの越境の形

グループ内の PvP/DvP。親会社、子会社、インハウス・バンクは、規則と決裁権限の系統を共有している。そのため、一つの参加者モジュールが会計、財務、カストディをつなぎ、承認済みの指図を DeFMI に渡せる。必要なのは、暗号化した永続キューである。MPC が停止しても指図が失われないようにするためである。守るべき規則は次のとおり。MPC の代わりに手元で計算しない。証明のない送信をしない。再送は要求 id で冪等にする。元の順序を保つ。期限切れの要求を自動で延長しない。復旧後は、カバー・スロット（実の依頼がないときも同じ形で送る空のスロット）を交えた一定間隔の送信に戻す。まとめて送ると、どの要求が本物だったかを告げてしまうからである。
ステーブルコインを資金脚とする独立当事者間。売り手と買い手は何も共有しないので、内部の承認は信頼の根拠にならない。各当事者のモジュールは、取引時点で次のものを束縛する。自身の KYB と署名権限。自身が事前予約した資産または USDC。ステーブルコインのチェーン、コントラクト、発行者、凍結、finality の条件。そして両脚にまたがる一つの取引 id、金額、期限。ステーブルコインの台帳は差し替え可能な資金の経路であり、独自の障害状態機械（reorg、期限切れ、発行者による凍結）を持つ。グループ内決済の設定を変えただけのものではない。

指図の発行元が必ず解く六つの問題

誰の判断が有効か。どの鍵、どの定足数、どの統治か。
証明した条件と決済する対象を、同じものにすること。
同時に出た指図が、共有の上限を合わせて超えないようにすること。
外部台帳との障害の整合。どの障害が原子性を壊すかを定め、壊れた構成を DvP と呼ばないこと。
後から確認できる相手を、正しい相手に限ること。紛争、監査、監督のための scope 付き開示。
法的に finality が成立する時点を定めること。

主張してよいこと

DLT 上の DvP、トークン化預金と証券、支払前のコンプライアンス審査、ZK によるコンプライアンス証明、担保や申込の自動化は、それぞれ単独では新しくない。検証すべきなのは組み合わせである。異なる指図の発行元が、同じ一つの型の指図を発行する。これにより、業務上の判断と決済が分離する。決済は元データを再構成しない。一回限りの権利は、指図をまたいで再利用できない。資金、預金、証券、口数、担保、証書を、一つの指図の境界の下に置く。分散運用でも、発行者・登録機関・清算の権限が証明の中に保たれる。事後の検証は選択的に行える。「世界初」は主張しない。主張があるとすれば、それは機能ごとの比較を終えた後の、統合された構成とその安全性の定義である。

実装の順序

ファンドの申込と解約。発行者、管理者、投資家、KYC の鍵を分ける。資格、申込上限、資金予約、発行可能口数を zkPI に束縛する。資金の note（口座名を持たない残高の単位）と口数の note を同時に更新する。同時の申込超過、期限切れ、再送、片脚の失敗を試験する。
担保と証拠金。適格担保、ヘアカット、集中度限度を承認済みの回路にする。ポートフォリオを見せずに充足を証明する。追加差入、差替、返還を扱う。複数の請求の順序付けと、法人単位の上限。
二通貨 PvP。二つの発行者と二つの予約を一つの zkPI に載せる。発行者の停止、期限切れ、再起動、再送を試験する。ISO 20022 への対応付けは外部アダプタに置き、DeFMI の型を特定の銀行のメッセージに固定しない。
外部台帳との接続。模擬のファンド・担保・銀行の台帳を、独立したプロセスとして立てる。署名付きの予約と確認済みの受領証を扱う。どの障害が原子性を壊すかを明示した一覧を作る。

今あるもの: 型付き zkPI、署名と証明の検証、一回限りの識別子、口座名を公開しない note 台帳、同一台帳内の DvP と PvP、発行者権限、事前予約、照合。いずれも QOMM 以外の業務システムから呼び出せる。ないもの: 実際のファンド管理者、CCP、銀行、CSD、登録機関との接続。外部 KYC。物理 HSM。7 拠点での運用。法的 finality。第三者監査。

← Aethel 計算結果を commitment に束縛する →