原文
論文: 既存のEthereum Request for Comments (ERC)標準の組み合わせでは、権原付き資産レイヤー全体をカバーできていないようです。具体的には、構造的な資産とトークンのバインディング、決定論的なドキュメントバンドルコミットメント、方向性のある転送ドメインルール、コンプライアンスイベント記録、オプションのアテステーション（証明）付き影響スナップショット、標準化された陳腐度報告などが含まれます。このレイヤーを6つの候補Ethereum Request for Comments (ERC)インターフェースに分割しました。それぞれが単独で展開され、価値を追加するように設計されています。構成はオプションであり、この分割自体がフィードバックを求めている部分です。
詳細は以下の資料をご覧ください。先行技術の修正や共同執筆を歓迎します。
概要
私たちは、EVM (イーサリアム仮想マシン)上の権原付き資産インフラストラクチャ向けに、6つのドラフトEthereum Request for Comments (ERC)インターフェース群を提案しています。これには、不動産、利権、天然資源の権利、その他、法的な権原が台帳とは独立して存在する金融商品が含まれます。
ERC-3643、ERC-7943、ERC-4626、ERC-7208などの既存の標準は、トークンの動作方法、コンプライアンスチェックの公開方法、ボールトシェアの仕組み、オンチェーンデータの構造化方法の重要な部分を記述しています。しかし、私たちが知る限り、分数化された金融商品を特定の法的にアンカーされた資産にバインドし、その裏付けとなるアサーションをプラットフォーム間で検証可能にするレイヤーは標準化されていません。
これらの提案は、契約上のトークン化と権原のトークン化の間の領域を占めます。これらはオンチェーンで法的権原を作成するものではありません。それには法令と制度的認識が必要です。より狭い技術的目標は、権原付き資産に関するアサーションをポータブルで、検証可能で、密かに改訂することが困難にすることです。
- 提案1 — 資産アンカーレジストリ — 資産とトークンのバインディング
- 提案2 — 正規ドキュメントバンドルアンカー — 決定論的なドキュメントアンカリング
- 提案3 — 方向性転送ドメインレジストリ — 方向性のある転送ドメイン
- 提案4 — 主体リンク型コンプライアンスイベントログ — オンチェーンコンプライアンスイベント記録
- 提案5 — 主体リンク型影響スナップショットログ — 影響スナップショットロギング
- 提案6 — 主体リンク型NAVスナップショットオラクル — 標準化された陳腐度報告
必須スタックなし。 これらは個別のインターフェースであり、モノリシックなプロトコルではありません。プロジェクトは、これらのいずれかを単独で展開できます。ファンドは、提案1、2、または他のレイヤーなしで、主体キー付き陳腐度報告のために提案6を採用できます。提案1は、デプロイメントがレコード間で共有subjectIdを必要とする場合のオプションのアイデンティティルートであり、他の前提条件ではありません。参照リポジトリの各パッケージは独立してビルドおよびテストされます。
スコープ外: オンチェーンの法的権原。ERC-3643、ERC-7943、ERC-4626、ERC-7540、またはERC-7208の置き換え。単一のRWAプラットフォーム (Real World Assetプラットフォーム)プロトコルの規定。オフチェーンアサーションが真実であることの証明。これらのインターフェースは、アサーションの検証と監査を容易にします。これらはレジストリ、裁判所、カストディアン、監査人、評価機関、コンプライアンスプロバイダー、または規制当局を置き換えるものではありません。
規範的な詳細は、個々のドラフト仕様とパッケージのREADMEに記載されています。このスレッドはアーキテクチャに関するものです。先行技術、スコープ、命名、およびEthereum Request for Comments (ERC)プルリクエストの前にこのファミリーを異なる方法で分割すべきかどうかについてフィードバックを求めています。
資料
- 参照実装 — Foundryモノレポ (
erc-asset-registry、erc-document-bundle-anchor、erc-transfer-domain、erc-compliance-event-log、erc-impact-snapshot、erc-nav-oracle) - UIスイートの例 — 6つのドラフトインターフェースのインタラクティブデモ（非規範的なプロトコルスタック/アーキテクチャビュー）
- 技術ホワイトペーパー — 動機、先行技術、規制コンテキスト、および6つのインターフェースの構成
- 権限の所在 (SSRN) — トークン化モデルの完了ベースの分類法。法的、契約上、台帳上の権限がどこにあるか、そして権原付き資産レイヤーが依然としてほとんどオーダーメイドである理由を明確にします。
- セキュリティレビュー — Verichains監査レポート
- 正式なEthereum Request for Comments (ERC) — この議論からのフィードバックを組み込んだ後、個別のMagiciansスレッドとethereum/ercsプルリクエストが続きます。これらのリンクが利用可能になり次第、この投稿を更新します。
インターフェース番号とERC-XXXX定数は、割り当てられるまで暫定的なものです。仕様は議論に基づいて変更される可能性があります。
なぜ今なのか
本番環境でのデプロイメントはもはや理論的なものではありません。Baillie Giffordは、EVM (イーサリアム仮想マシン)とSolana上で完全にネイティブな英国規制のトークン化ファンドを立ち上げました。ドバイ土地局は、VARAと協力して限定的な不動産トークン化パイロットを立ち上げました。
一方、トークン側の標準は統合されつつあります。ERC-3643とERC-7518 (レビュー) は、許可された転送パターンをカバーしています。ERC-7943は、最小限のベンダーニュートラルなRWAプラットフォーム (Real World Assetプラットフォーム)コンプライアンスインターフェースとして現在ファイナルです。ERC-4626、ERC-7540、ERC-7575はボールトメカニズムをカバーしています。ERC-7208はオンチェーンデータコンテナインフラストラクチャを提供します。
これらのレイヤーは有用であり、これらの提案はそれらと連携するように意図されています。しかし、発行者ごとにほとんどオーダーメイドのまま残っているのが権原付き資産レイヤーです。これは、トークンを特定の法的にアンカーされた資産にバインドすること、決定論的な法的文書コミットメント、方向性のあるコリドールルール、および会場間でポータブルなコンプライアンス、影響、陳腐度履歴を扱うものです。
そのレイヤーをオーダーメイドのままにしておくと、すぐにコストが発生します。買い手は特定の区画や利権へのバインディングを検証できません。デューデリジェンスチームは、発行者のプラットフォームをリバースエンジニアリングすることなく文書コミットメントを再現できません。規制当局や監査人は、会場間でポータブルなコンプライアンス履歴を持てません。DeFiプロトコルは、カスタムアダプターや陳腐度セマンティクスなしでは陳腐度を安全に利用できません。
既存の標準がカバーするもの
ERC-3643、ERC-7518 (レビュー)、ERC-7943、ERC-4626、ERC-7540、ERC-7575、およびERC-7208は有用な既存のレイヤーです。私たちはそれらの代替案を提案しているわけではありません。
私たちの見解では、それらは主にトークンの動作、コンプライアンスの公開、ボールトのメカニズム、またはデータコンテナを記述しています。それらは、資産バインディング、決定論的な法的文書コミットメント、方向性のあるコリドールルール、証拠となるコンプライアンスログ、影響記録、または主体キー付き陳腐度のための共通の権原付き資産レイヤーを定義していません。
それが提案されたギャップです。もし私たちが見落としている先行技術、特にこれらの提案のいずれかを吸収または置き換えるべき活発な作業があれば、正式なEthereum Request for Comments (ERC)を提出する前にそれを見つけたいと考えています。
6つの候補インターフェース
仮のタイトルのみ。番号は提出時に割り当てられます。
提案1 — 資産アンカーレジストリ
レジストリスコープのバインディングは、アンカーを(token, bindingScope, tokenId)タプルにリンクし、法的根拠と裏付けとなる証拠に対して個別のコミットメントを持ちます。各アンカーは一度だけバインドでき、各タプルはレジストリ内で最大1つの有効なバインディングを持つことができます。無効化された履歴バインディングは引き続きクエリ可能です。バインディングフィールドはバインディング後に不変です。ライフサイクルの非アクティブ化と管理者のみのバインディング無効化は明示的な状態遷移です。どちらも履歴バインディングフィールドを書き換えることはありませんが、バインディング無効化は代替アンカーのためにトークンバインディングスロットを解放できます。分数請求が100%を超えないなどの割り当ての整合性は、レジストリではなくトークン実装と法的構造に属します。
意図された貢献は狭いです。資産バインディングを、発行者のメタデータや提供文書で主張されるだけでなく、レジストリ側の記録とトークン側の宣言の両方に対してクエリ可能かつ構造的に検証可能にすることです。
提案2 — 正規ドキュメントバンドルアンカー
オフチェーン文書セットを記述するマニフェストの決定論的なコミットメント。同じ正規化された文書表現、正規エントリフィールド、順序付けルール、およびスキーマバージョンが与えられた場合、互換性のある実装は同じバンドルハッシュを導出します。
この提案は、バンドル構造をファイル正規化から分離します。仕様はJSONおよびXML正規化プロファイルを定義しますが、正規化はオフチェーンで実行されます。Solidity参照パッケージは、結果のドキュメントエントリハッシュを受け取り、正規順序付けを適用または検証し、バンドルハッシュを導出します。それ自体はJSONまたはXMLを正規化しません。PDFおよび画像プロファイルは意図的に延期されています。堅牢なプロファイルが存在するまで、バイナリ文書は生バイトモードを使用すべきです。この提案は単独で存在し、資産レジストリには依存しません。
提案3 — 方向性転送ドメインレジストリ
コリドールレベルのルール：2つのドメイン間の転送が資産クラスに対して許可されているかどうかを、個々の保有者がKYCを通過しているかどうかとは独立して判断します。ルートは方向性があります。逆方向の許可には別の登録が必要です。
このレジストリは助言的であり、それ自体でトークン転送を強制するものではありません。強制を必要とする利用側のトークンまたはアプリケーションは、転送とアトミックにisRoutePermitted()を呼び出す必要があります。ERC-165はレジストリインターフェースのサポートを通知できますが、トークンがレジストリを参照し、その決定を強制することを証明することはできません。レジストリのガバナンス、レジストラモデル、および取り消しセマンティクスについてフィードバックを求めています。
提案4 — 主体リンク型コンプライアンスイベントログ
資産またはトークンのライフサイクル全体にわたる、追記専用の属性付きコンプライアンス履歴：発行、検証、転送チェック、凍結、凍結解除、規制保留、執行、償還、修正、およびカスタムイベント。
修正は新しいエントリとして追加されます。修正されたイベントのcorrectedByIndex前方ポインタが一度設定され、修正にリンクされることを除いて、既存のイベントコンテンツは変更されません。修正エントリのcorrectsIndexは元のイベントを指し戻します。意図された貢献は、規制当局、監査人、および取引相手が独自のオフチェーンログ形式に依存することなく読み取ることができる証拠記録です。機密データはオフチェーンに残すべきです。オンチェーン記録は、コミットメント、適切な場合は役割ラベル付きの当事者、ペイロードプロファイル、および証拠ハッシュを保持すべきです。
これはRWAプラットフォーム (Real World Assetプラットフォーム)に特化したものではありません。権原付き資産以外の規制されたトークンも同じ監査履歴問題を抱えているため、最も広範な採用経路となる可能性があります。
提案5 — 主体リンク型影響スナップショットログ
改ざん防止された影響スナップショット。必須のゼロ以外の方法論コミットメント、修正の来歴、および方法論のバージョン管理と肯定的または否定的なアテステーション（証明）のためのオプションの拡張ポイントを備えています。コアインターフェースは、定義された期間にわたる測定指標を記録し、フォークのない修正をサポートします。
これは、報告された測定値が真実であることを確立するものではありません。これは、サイレントな改訂を防ぎ、対応する拡張機能が使用されている場合に、修正と方法論の履歴を可視化します。目標は、ToucanやRegenなどの炭素および影響エコシステムからの作業を補完することであり、重複させることではありません。正式な提出前に、これらのコミュニティからのフィードバックを求めています。
提案6 — 主体リンク型NAVスナップショットオラクル
明示的な根拠、通貨、プロバイダーの帰属、修正チェーン、および2つの個別の陳腐度チェックを備えた主体キー付き陳腐度報告：
- 公開の陳腐度: プロバイダーは期待されるハートビート内で公開しましたか？
- 評価の陳腐度: 基礎となる評価自体は十分に最近行われましたか？
どちらも非流動資産の陳腐度にとって重要です。プロバイダーは古い評価を時間通りに再公開できますが、公開の鮮度だけでは評価が新鮮であることにはなりません。この提案は、ERC-4626/7540/7575ボールトメカニズムとERC-7726共通クォートオラクルAPIを補完します。これは評価を報告するものであり、実行可能な価格を作成するものではありません。
単独でデプロイ可能：ファンドまたはボールトは、提案1またはこのセットの他のインターフェースをデプロイすることなく、提案6を通じて主体キー付き陳腐度を公開できます。
オプションの構成
独立性が第一。 これらのインターフェースのいずれも、他のインターフェースを必要としません。強制的なデプロイ順序や必須のフルスタックはありません。
| 必要なもの… | デプロイできるもの… | なしで… |
|---|---|---|
| 主体キー付き陳腐度のみ | 提案6 | 提案1〜5 |
| ポータブルなコンプライアンス履歴のみ | 提案4 | 提案1〜3、5〜6 |
| 決定論的なドキュメントコミットメントのみ | 提案2 | 提案1 (任意のbytes32主体を使用) |
| 資産とトークンのバインディングのみ | 提案1 | 提案2〜6 |
| 方向性のあるコリドールルールのみ | 提案3 | 提案1〜2、4〜6 |
| 影響スナップショットのみ | 提案5 | 提案1〜4、6 |
例 — 陳腐度のみ: ERC-4626ファンドは、自身のsubjectId（ボールトアドレス、ISINハッシュ、またはその他の不透明な識別子）をキーとして陳腐度スナップショットを公開します。資産アンカーレジストリは決してデプロイしません。
例 — フル権原付き資産スタック: デプロイメントが共有の主体ルートを望む場合、提案1のanchorIdは、提案2、4、5、6のsubjectIdとして機能できます。これは構成パターンであり、要件ではありません。
説明的なスタックの例:
ERC-3643利権トークンは、資産アンカーレジストリに関連付けられています。そのanchorIdは、正規の法的文書バンドル、コンプライアンスイベントログ、影響スナップショットログ、および担保統合によって使用される陳腐度スナップショットオラクルをキーとして使用されます。各コンポーネントは独立してデプロイ可能です。
非規範的なプロトコルスタックおよびアーキテクチャビューについては、ライブのUIスイートを参照してください。インターフェースは、有用な場合にレイヤーで構成されます。いくつかは単独で有用です。
先行技術
ERC-3643 / ERC-7943 / ERC-7518 (レビュー) — 準拠したトークンの動作と転送制御。これらは補完的です。資産バインディングとライフサイクルデータレイヤーは、そのコアスコープ外に残ります。
ERC-1643 / ERC-5289 — ドキュメントレジストリと公証人ワークフロー。提案2は、ドキュメント参照ストレージまたは公証のみではなく、決定論的なクロスプラットフォームバンドルハッシュを特定することで異なります。
ERC-1404 / ERC-1462 / ERC-1592 — トークンローカルな転送制限とセキュリティトークン転送セマンティクス。提案3は、保有者レベルのチェックを超えるトークン非依存のコリドールレジストリです。
ERC-8106 — 助言的なコンプライアンスイベントとエンティティ分類を発行します。提案4は、修正セマンティクス、証拠コミットメント、および権限帰属を備えた証拠となる追記専用ログです。異なるユースケースです。
Toucan / Regen — 炭素および生態資産の方法論追跡。提案5は、任意の定量的指標と方法論のバージョン管理に一般化されますが、確立されたドメイン固有の方法論作業を重複させるべきではありません。
ERC-6956 / ERC-7929 — 物理オラクルバインディングとトークン間階層。提案1は異なる信頼モデルを使用します。法的/証拠コミットメントと相互アンカー・トークン検証を備えたスタンドアロンレジストリです。これらは補完的であると信じていますが、統合パスが見つかる場合はお知らせください。
ERC-7208 — オンチェーンデータコンテナ。データレイヤーとして構成可能です。提案1は、一般的なデータストレージではなく、法的な資産バインディングに特化しています。
ERC-7726共通クォートオラクル / ERC-7540 / ERC-7575 — 共通クォートオラクルAPI。非同期ボールト。マルチアセットボールト。提案6は、公開と評価の陳腐度セマンティクスを備えた非流動資産の主体キー付き陳腐度に対応します。
発行者陳腐度フィード / ボールトレジストラ / オーダーメイドのRWAプラットフォーム (Real World Assetプラットフォーム)スタック — 生産パターンは存在し、場合によってはうまく機能します。問題は、共通の読み書きインターフェースがエコシステム全体でのアダプター作業とベンダー依存を減らすかどうかです。
ERC-6065 — 不動産に特化したERC-721メタデータ。権原付き資産と部分的に重複しますが、資産クラスが狭く、分数化された金融商品のバインディングに焦点を当てていません。
私たちが求めていること（と求めていないこと）
求めていること
個別のEthereum Request for Comments (ERC)スレッドを作成する前のアーキテクチャレビュー：
- 境界はどこに移動すべきか — 統合、狭める、または削除すべきか？
- 提案を吸収または置き換えるべき、私たちが見落とした先行技術は何か？
このスレッドでは求めていないこと
- Ethereum Request for Comments (ERC)番号の割り当て
- 参照実装の管理者復旧と信頼モデルの詳細 (→ 提案1スレッド)
- 規範的なPDF/画像プロファイル (→ 提案2スレッド)
- 監査結果の要約または修正のウォークスルー (→ 個別のEthereum Request for Comments (ERC)プルリクエスト)
未解決の質問
- 提案の分割 (アーキテクチャ) — これら6つのインターフェースは適切な境界か、それともファミリーは異なる方法で分解されるべきか？
- 提案3のガバナンス (トークン / コンプライアンスインテグレーター) — パーミッションレスチェーン上の方向性ドメインレジストリにとって、どのようなレジストラ/ガバナンスモデルが理にかなっているか？
- 提案4のプライバシー (規制 / プライバシーレビュー担当者) — コミットメントのみのコンプライアンスイベントログは、実際のGDPRまたは同等のレビューの下で検証されているか？
- 提案5の重複 (影響 / 炭素コミュニティ) — 影響方法論の作業はどこで止まり、オンチェーンの方法論バージョン管理されたロギングはどこから始まるべきか？
- 提案1とERC-6956/ERC-7929の比較 (バインディング / オラクル設計者) — 補完的なレイヤーか、それとも提案1のスコープを再検討すべき兆候か？
- レイヤーモデル (アーキテクチャ) — コンプライアンス、資産バインディング、ライフサイクル証拠、およびボールトメカニズムのスタックは、重要なレイヤーを見落としているか、または誤って配置しているか？
- Ethereum Request for Comments (ERC)提出のグループ化 (アーキテクチャ / EIPエディター) — ethereum/ercsへのプルリクエストの前に、どの提案（もしあれば）を最初に統合すべきか？
著者
Chris Turner、David Hay (LinkedIn)、Reagan Simpson、Collins Musyimi。
規制された仮想資産および権原付き資産のユースケース向けインフラストラクチャを構築するKulaで開発されました。参照実装はオープンソースです。私たちはKula専用のスタックではなく、エコシステムインターフェースを提案しています。Kula以外の追加の共同執筆やコミュニティ貢献も歓迎します。
この議論からのフィードバックを組み込んだ後、個別のMagiciansスレッドとEthereum Request for Comments (ERC)プルリクエストが続きます。
1投稿 - 1参加者