署名付きで版管理されたストリーム
条件・版・両当事者の署名とともにストリームを登録します。更新は新しい版になり、古い版は資金調達に使えず、同じ支払義務を別の識別子で二重登録することもできません。
Aethel · zkFMI アプリケーション · æmeth 開発
支払の流れが、そのまま債権になる。
Aethelは、両当事者が署名した支払ストリームを債権に変えます。独立した与信評価者・保証者・資金供給者・回収管理者が、それぞれ自分で署名した権限の範囲で関わります。決済はzkFMIで行い、Aethel自身は資金を保有しません。
債権の組成・与信・資金供給・回収を実際に担当するチームのために。ここにあるのは、マーケットプレイスでも貸し手でもありません。担当チームが自社の提供者を接続する状態機械であり、あとから監査できる記録です。
- 01署名済み支払ストリーム
両当事者が支払予定と条件に署名し、証明者が確認します。更新はすべて新しい版になります。
- 02債権
シリーズの方針がストリームを受け入れます。与信判断・保証・資金供給見積が、それぞれ別の提供者の署名付きで、この債権だけに結び付きます。
- 03決済
発行は型付きのzkPI指図になります。DeFMIが決済し、Aethelは証跡を記録します。完済で終了し、不履行なら保証請求に結び付けます。
Rust の状態機械12 クレート研究実装監査未実施
Aethel とは
請求書の台帳ではなく、支払義務の状態機械。
Aethelは、貸し手・格付けモデル・保証者・市場を固定しません。支払ストリームが業務上何を意味し、誰がそれについて何を決め、各判断が今どの状態にあるかを記録し、価値を動かす処理はすべて決済層へ渡します。
方針を持つシリーズ
債権シリーズが、どのストリームをどの規則で資金調達してよいかを定めます。保証が必須か、相手方がどの資格を証明すべきか、何がいつ失効するか。
一つの文脈に結び付いた判断
与信判断・保証・資金供給見積は、対象の債権、有効期間、nonce、提供者の署名を持ちます。どれも別の債権へ使い回せません。
債権の流れ
五つの段階。どの遷移にも、拒否する理由がある。
コアは決定的です。同じ入力からは必ず同じ状態になります。役に立つのは、何を拒否するかが決まっているからです。
- 01 · 登録
ストリームを証明し、シリーズを開く
ストリーム証明者が支払ストリームとその更新を確認します。シリーズが、対象となるストリームと方針を定めます。
拒否されるもの署名のないストリーム、版の不一致同じ支払義務の二重登録 - 02 · 与信と保証
署名付きの判断、約束された保証
与信評価者がこの債権への判断に署名します。保証者がDeCCPの保証枠に裏付けられた保証を約束します。金額は秘匿できます。
拒否されるもの期限切れの判断方針が保証を求めるのに保証がない権限の異なる署名 - 03 · 資金供給と発行
見積が競い、債権が発行される
資金供給者が実行可能な見積を出します。発行は型付きのzkPI指図になり、DeFMIが決済し、Aethelが証跡を記録します。
拒否されるもの決済証跡より先の確定未登録の提供者からの見積支払義務を超える発行 - 04 · 回収管理
証跡が入り、状態が出る
支払証跡、延滞、解消、許可された回収操作を回収管理者が記録します。再試行された依頼は一度だけ反映されます。
拒否されるもの同じ決済結果の二重反映権限外の回収操作 - 05 · 完済または請求
完済なら終了。不履行なら請求。
完済した支払義務は債権を終了します。不履行の証明が保証請求に結び付き、損失配賦はDeCCPで、決済はDeFMIで行われます。
拒否されるもの不履行証明のない請求権限のない提供者による解放
記録RegisteredStreamReceivableSeriesCreditDecisionGuaranteeCommitmentFundingQuoteReceivableIssuanceDefaultAttestationGuaranteeClaimProviderDefinition
開かれた提供者モデル
六つの権限。どれも他を含意しない。
提供者は狭く限定された権限で登録され、自分が責任を持つ成果物にだけ署名します。与信判断が黙って保証として振る舞うことはなく、保証者が別途認可なしに資金供給見積を出すこともできません。一社が複数の権限を持ってもよく、それぞれ個別に付与・失効します。
| ストリーム証明 | 与信判断 | 保証 | 資金供給見積 | 回収操作 | 発行者の承認 | |
|---|---|---|---|---|---|---|
StreamAttestorストリームとその更新を証明する | ||||||
CreditAssessor一つの債権への判断に署名する | ||||||
Guarantor外部の保証枠から保証を約束する | ||||||
LiquidityProvider実行可能な資金供給見積を出す | ||||||
Servicer許可された回収操作を行う | ||||||
CredentialIssuerDeKYXの発行者鍵を承認する。それ以外は何もしない |
塗りつぶした点が、その権限で署名できる唯一の成果物です。それ以外は慣習ではなく状態遷移で拒否されます。
登録 → 有効 → 停止 → 失効鍵更新: 旧鍵の署名は検証でき、旧鍵での新しい署名は拒否判断や保証の受理前にDeKYXの提示を必須にできる
正本の所在
Aethelは意味を持つ。それ以外は、正本のある場所に置いたまま。
債権には、資金・本人性・保証・トークンが関わります。Aethelはそれぞれを一箇所、正本となるシステムにだけ置き、自分は参照とダイジェストだけを保存します。同じ残高・資格・保証枠を二つ目の台帳へ複製しません。
| 情報 | 正本 | Aethelが保存するもの |
|---|---|---|
| 支払ストリーム、シリーズ、残存元本 | Aethel | 両当事者の署名、版、条件、現在の状態 |
| 与信判断 | 評価者が署名 · Aethelが状態として受理 | 署名付き判断、対象、版、有効期限、提供者参照 |
| 法的名称、登録番号、KYB証跡 | DeKYX 発行者 | 仮名の主体参照と資格のダイジェスト |
| 保証枠と残容量 | DeCCP または保証者 | opaqueなhold IDとcommitment。解放・請求時はsettlement digest |
| 保有者別のトークン残高 | DeFMI 等の外部asset ledger | 発行上限とmint/burnのintent、ledgerのreceipt。保有者別残高は持たない |
| 資金、証券、担保 | DeFMI | note・lock・settlementの参照と確定root |
| 決済指図 | zkPI | 指図ID、nullifier、domain、証明と署名の要約 |
匿名の資格確認
判断や保証を受理する前に、シリーズがDeKYXの提示を必須にできます。提示はこのドメイン・行為・成果物の文・nonce・期限に結び付くので、ある判断のための証明を別の判断へ使い回せません。Aethelは検証済みの主体参照だけを持ち、法的名称は持ちません。
秘匿された保証
保証額は秘匿できます。その場合、AethelとDeCCPは平文の金額ではなく、commitment・状態ダイジェスト・識別子・検証済みの遷移receiptを交換します。
証跡と引き換えの決済
発行と請求は型付きのzkPI指図になります。DeFMIが決済し、ホストが証跡を検証し、その後で初めてAethelが最終状態へ進みます。自分の判断だけで先へ進むことはありません。
企業向けPoC
自社の役割と鍵で動かし、想定する失敗をぶつける。
PoCガイドは、署名済みストリームから決済までの最小シナリオ、拒否されなければならない失敗系、保存すべき証拠、受入基準の例を示します。一つのチームが全役割を演じる場合でも、鍵は役割ごとに分けます。分けなければ権限分離を検証できないからです。
最小シナリオ
- 両当事者が署名する支払ストリームを作る。生の本人情報ではなく主体参照を使う
- 与信事業者を登録する。鍵、資格条件、判断の有効期限、モデルの版
- 債権を組成する。版の一致、期限内の判断、方針が求める保証
- 資金供給とトークン化。発行総数は支払義務を超えず、償還済みの権利は再利用しない
- 回収管理。再試行は一度だけ反映され、結果は保有者へ一度だけ配分される
- zkPIとDeFMIで決済する。Aethelは確定した証跡を受けてから確定する
拒否されなければならないもの
- 与信判断の期限切れ後の債権化
- 保証必須の商品を保証なしで発行
- 権限のない事業者による保証の解除
- 失効したDeKYX資格でのトークン取得
- 同じストリームを別の識別子で二重登録
- 更新前の鍵による新しい与信判断への署名
- 同じ決済結果の二回受信
- 残存する支払義務を超えるトークン発行
受入基準（最低限）
- 与信・保証・資金供給の権限が独立している
- 方針が求める保証を与信判断で代替できない
- DeKYXの失効・鍵更新が新しい処理へ反映される
- zkPIまたはDeFMIが失敗した場合、Aethelの決済状態が確定しない
- 再試行後も一つの業務依頼が一度だけ反映される
- すべての重要な状態遷移を、入力の版と署名まで遡って監査できる
現状と限界
研究実装。境界は明記してある。
- 本番利用に向けた監査は未実施です。
- Aethelは組み込み可能な状態機械であり、サーバーではありません。認証済みAPI、永続化、同時実行制御、鍵管理、DeKYX・DeCCP・zkPI・DeFMIへのadapterはホストアプリケーションが用意します。
- 資格確認はスコープ内の仮名性であり、発行者間の非連結性はありません。発行者をまたぐSybil対策はクレートの外のガバナンス判断です。
- 保証請求と解放は全額を対象とする遷移です。部分保証には拡張した状態モデルが必要です。
- 債権譲渡の法的効力、対抗要件、税務、会計、倒産時の取扱いはコードの外にあり、導入ごとに定めます。
- ビルドの4ゲートに通ることは、暗号・金融・状態機械・ホスト・接続の独立した監査の代わりになりません。
# 4つのゲート。Linux、固定した依存グラフで
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo fmt --all -- --check
cargo build --workspace --release --locked