JP2022536447A - 分散台帳プラットフォームでデジタル流動性トークンを管理するためのシステム、方法、及び記憶媒体 - Google Patents

Abstract

分散台帳の非代替性トークン、任意の２つの別個の資産の表現についての流動性ファンクションを表現するデータ構造を作成及び管理するための、装置、コンピュータ可読媒体、及びコンピュータ実装方法。表現は、台帳、ネットワーク、管轄域、利用可能性などを含め、異なる特性を持つ、異なる資産又は単一の資産タイプであってもよい。流動性ファンクションは、資産を変形又は交換するためのメカニズムであり、価格決定ファンクション、手数料、及びデリバリーのメカニズムを含む。流動性トークンの投資パフォーマンスは、資産のペアの流動性の需要に比例することができる。

Description

本出願は、２０２０年４月１７日に出願された米国特許出願第１６／８５１，１８４号の一部継続出願である。本出願は、２０１９年４月２９日に出願された米国仮特許出願第６２／８３９，９６９号の非仮特許出願の利益を主張するものであり、その開示は参照により本明細書に組み込まれる。

本開示は、トークン化された資産に関するデータを管理するためのシステムを構成するための、システム、方法、及び記憶媒体に関する。

著作権の注意
本特許文書の開示の一部には、著作権保護の対象となる内容が含まれる。特許商標庁の特許ファイル又は記録に現れる限りにおいては、著作権の所有者は、誰でも当該特許文書又は特許開示を複製することについて異議を唱えないが、それ以外の場合、如何なる場合でもすべての著作権を留保する。

経済において、「流動性」とは、資産（アセット）がその価格に影響を及ぼさずに市場で迅速に買われ得る又は売られ得る程度を指す。流動性はまた、ある資産の価値が損失なく別の資産に移転／変換され得る効率と説明することもできる。その中心部では、流動性は「欲求の二重の一致」、つまり取引する同時的な希望を有する、消費者及び資産の提供者の両方を市場が含む見込みに着目する。二重の一致がない場合、売り手（又は買い手）は、所望の取引に関わりたがっているパーティを見つけるよう積極的に価格を調節しなければならない。反対取引に関わる個人が支払う価格に対して調節されなければならない価格の程度は、市場の効率を反映することになる。所望の取引をサポートするために著しい価格シフトを必要とする市場は、非効率的であり、流動性が限定されていると言える。市場は、あらゆる所与の取引について、その価値の等価な購入又は販売の価格の差が類似している場合、効率的な流動性及び価格競争を有していると言われる。多くの市場は、流動的ではなく、効率的な価格決定を有していない。これらの市場に参入することは、投資家が参加するのに保険料を支払わなければならないため、困難な場合がある。

出願人は、分散台帳技術（ＤＬＴ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｌｅｄｇｅｒ Ｔｅｃｈｎｏｌｏｇｙ）及びトークン化の使用を介してエコシステム内で流動性の管理を高度化及び自動化するための、新規で有用な技術を開発した。ブロックチェーンなどの分散台帳技術（ＤＬＴ）は、デジタル・トークンによって表現され、またそこにカプセル化される代替性資産及び非代替性資産を用いて、非中央集権化されたコンピュータ・ネットワーク全体で価値を移転するように実装されている。取引は、合意メカニズムを通じて達成される確認に基づいて、台帳に記録される。ＤＬＴは、市場の効率を向上させる可能性を有する。しかしながら、多くの市場活動を、中心となる信頼できる仲介なしに非中央集権化されたネットワークに適合することは、多くの技術上の障害を引き起こしてきた。例えば、中央集権化されたマーケット・メーカーがないと、流動性は失われる可能性がある。

米国特許出願公開第２０１９０１６４１５１（Ａ１）号

ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｂｌｏｂ／ｍａｓｔｅｒ／ＥＩＰＳ／ｅｉｐ－７２１．ｍｄ ｈｔｔｐｓ：／／ｅｉｐｓ．ｅｔｈｅｒｅｕｍ．ｏｒｇ／ＥＩＰＳ／ｅｉｐ－１６１６ ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｉｓｓｕｅｓ／１６４３ ｈｔｔｐｓ：／／ｈａｃｋｅｒｎｏｏｎ．ｃｏｍ／ｈｏｗ－ｔｏ－ｍａｋｅ－ｓｍａｒｔ－ｃｏｎｔｒａｃｔｓ－ｕｐｇｒａｄａｂｌｅ－２６１２ｅ７７１ｄ５ａ２ ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＡＣＩＤ＿（ｃｏｍｐｕｔｅｒ＿ｓｃｉｅｎｃｅ） ｐａｙｍｅｎｔ ｄｅｌｉｖｅｒｙ

開示される実装形態は、資本市場に対する新規なコンポーザブル資産クラス、及び流動性を効率的に最大化することにより効率的なネットワーク化売買システムを作成するための新規な技術プラットフォームを定義するデジタル「流動性トークン」を含む。得られるシステムは、次のことを確実にすることによって、売買参加の市場における不一致を滑らかにする：１）常に市場価格が存在する；２）市場への又は市場からの、買い又は売りの動きは常に可能であるが、小規模である；３）価格の動きは流動性自体への需要を反映する；４）市場への、及び市場からの動きは、最小の摩擦を招く；５）市場を操作する試みは、価値の損失につながる；６）情報の不一致は、システムからの最小の価値の流出につながる；７）流動性の提供者は、市場における流動性の需要から恩恵を受ける機会を有する。

流動性トークンの保有者は、特定の市場における流動性の需要に基づいて、価値（例えば、配当、自己資本成長など）を受け取る。トークンそれ自身は、価値のペア同士の間で市場が作り出すファンクションにおいて、所有権を表現する。流動性への需要が高まるほど、収益は大きくなる。次に、収益の増加は、より多くの資本をトークンに引き寄せる。内部的なバランシング・ファンクションは、資産フローと市場需要との間で平衡を維持する。流動性トークン（それぞれが具体的なペアの流動性への需要を表現している）のエコシステムを通じて、資本はエコシステム内のすべての資産クラスに対して流動性への需要のバランスを取るようフローする。

実装形態は、コンポーザブルなトークン化資産を活用して、市場流動性を実現及び管理する技術プラットフォームを提供する。その中心部で流動性ファンクションを分離することによって、出願人の技術は、金融サービス全体に適用可能な流動性サービス向けの基礎的なインフラストラクチャを確立する。

開示される実装形態の一態様は、資産のトークン化ペアを作成する方法であって、方法は、流動性トークンを作成することを含み、流動性は、資産ペアのための流動性ファンクション、及び流動性ファンクションによって作り出される収益の有益な所有権、及び流動性をサポートするために必要な資産の所有権、を表現するデジタル・トークンである。流動性トークンは、クラス定義に従って非代替性トークンとして作成され、流動性トークンは一意なトークン識別子を含み、流動性トークンは、流動性トークンの所有権を代替性トークンに割り振ることによってデジタル代替性トークンでラップすることが可能であり、それによって資産及び流動性トークンによって表現される収益の部分所有権を可能にするデータ構造を作成する。流動性トークンは、流動性ファンクション及び資産管理をサポートするために、スマート・コントラクト・ウォレットに割り振ることができる。

開示される実装形態の別の態様は、資産のトークン化ペアを作成する方法であって、方法は、クラス定義に従って資産ペアのそれぞれの側のデジタル・トークンを作成することであって、それぞれのデジタル・トークンは一意なトークン識別子を含む、作成することと、デジタル・トークンを、対応する資産と関連付けて、一意なレコードとして資産レジストリのメモリ・デバイスに登録することと、デジタル・トークンのそれぞれの所有権を、非代替性トークンによって所有される個々のウォレットに割り振ることと、非代替性トークンの所有権を代替性トークンに関連付けられるウォレットに割り振ることによって、非代替性トークンを代替性トークンでラップすることであって、それにより資産ペアの資産の間に流動性を与えることによって生成される収益を表現するデータ構造を作成する、ラップすることと、を含む。

開示される実装形態の別の態様は、資産のトークン化ペアを表現するデータ構造であって、データ構造は、非一時的な媒体に記録され、資産ペアのそれぞれの側のデジタル・トークンであり、それぞれのデジタル・トークンは、クラス定義に従って作成され、それぞれのデジタル・トークンは、対応する資産と関連付けて、一意なレコードとして資産レジストリのメモリ・デバイスに登録される一意なトークン識別子を含む、デジタル・トークンを含み、デジタル・トークンのそれぞれの所有権は、非代替性デジタル・トークンによって所有される個々のウォレットに割り振られ、代替性デジタル・トークンは、非代替性トークンを代替性トークンに関連付けられるウォレットへ所有権割り振りすることを通じて、非代替性デジタル・トークンをラップし、それにより資産ペアの資産の間に流動性を与えることによって生成される収益を表現するデータ構造を作成する。

開示される実装形態による、トークン化された資産を作成、構成、及び管理するためのコンピューティング・アーキテクチャの概略図である。 開示される実装形態による、基本的な非代替性資産トークン及びその高レベル・インターフェースの概略図である。 開示される実装形態による、資産トークン販売及び購入の処理フローの図である。 開示される実装形態による、資産バリュエーション・ファンクションのインターフェース仕様の図である。 開示される実装形態による、バリュエーション処理のフローの図である。 開示される実装形態による、基本的なファンド・トークン及びその高レベル・インターフェースの概略図である。 開示される実装形態による、他のトークンを所有するトークン・ウォレットの実例を図示する概略図である。 部分所有権をサポートするための非代替性資産から代替性資産トークンへの接続の概略図であり、開示される実装形態による、基本的な非代替性資産トークンの概略図である。 開示される実装形態による、切り離した資産管理ロジック及びファンド構造を用いて自動化することができる基本的なファンド運用の図である。 開示される実装形態による、ファンド構造を処理するためのコンピューティング・プラットフォームを構成するための方法のフロー・チャートである。 開示される実装形態による、異種ネットワーク間で通信を実現するための方法のフロー・チャートである。 開示される実装形態による、異種ネットワーク間で通信を実現するためのコンピュータ・アーキテクチャの概略図である。 開示される実装形態による、ノード・グラフの概略図である。 ブリッジ・メタデータ・スキーマの概略図である。 開示される実装形態による、クロス台帳変異を達成するためのサブ取引のチェーンの実例の概略図である。 開示される実装形態による、単純な価値移転の実例の概略図である。 開示される実装形態による、チェーン化された取引の実例の概略図である。 開示される実装形態による、実例の取引チェーン構築処理の概略図である。 開示される実装形態による、チェーン化された移転の概略図である。 図１９Ｂと併せて、開示される実装形態による、チェーン化された移転についての状態図の実例の図である。 図１９Ａと併せて、開示される実装形態による、チェーン化された移転についての状態図の実例の図である。 開示される実装形態による、担保契約移転を達成するブリッジ用の運用の実例の概略図である。 開示される実装形態による、決済移転を達成するブリッジ用の運用の実例の概略図である。 開示される実装形態による、資産ペアの価格決定メカニズムの図である。 開示される実装形態による、１ペアの資産同士での流動性をサポートする従来的なシステムの基本的な要素の図である。 開示される実装形態による、価格決定ファンクションの図である。 開示される実装形態による、資産トークンを定義するデータ構造の図である。 開示される実装形態による、ラップされた流動性トークンに流動性を与えるためのメカニズムの図である。

図１は、開示される実装形態による、資産をトークン化して管理するためのコンピュータ・アーキテクチャ１００を図示している。いくつかの実装形態では、アーキテクチャ１００は、クライアント／サーバ・アーキテクチャ、ピアツーピア・アーキテクチャ、及び／又は他のアーキテクチャに従って、１つ又は複数のリモートのコンピューティング・プラットフォームと通信するように構成することができる１つ又は複数のコンピューティング・プラットフォームを含んでもよい。プラットフォームは、１つ又は複数の命令モジュールを含み得る機械可読命令によって構成されてもよい。命令モジュールは、非一時的なメモリに記憶されるコンピュータ・プログラム・モジュールを含んでもよい。

ＥＴＦなどの投資ファンドは、本明細書では、開示される実装形態を用いて管理することが可能な資産の実例として用いられる。開示される実装形態に従ってＥＴＦファンドを作成して開始するために、発行者は以下を含む複数ステップの処理に従う：（１）ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）の所定の仕様（本明細書では「ＩＡｓｓｅｔＴｏｋｅｎ」仕様と称される）を使用してファンド資産をトークン化する；（２）ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）の所定の仕様（本明細書では「ＩＡｓｓｅｔＦｕｎｄ」仕様と称される）を使用してファンド自身をトークン化する；（３）資産管理、列挙、及びネスト化を可能にする新規なトークン・データ構造を使用して、ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔファンクション（以下で詳細に説明する）を使用してトークン化された資産をファンドに付加する；（４）所望であれば、ＩＡｓｓｅｔモジュール１０２（以下で詳細に説明する）のＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェース（以下で詳細に説明する）を使用して非代替性トークンを代替性トークンに付加して、部分所有権及び簡略化された取引をサポートする。開示される実装形態のトークンは、本明細書では時に「ＩＡｓｓｅｔトークン」と称されることに留意されたい。これらの仕様、インターフェース処理ステップ、及びデータ構造のすべては、非中央集権化的なシステムにおけるファンド管理を容易にし、本明細書で詳細に説明される。様々なファンクション及びインターフェースを実装するソース・コードの実例が、本特許出願の明細書の一部であるＡｐｐｅｎｄｉｘに含まれている。

資産レジストリ・モジュール１０４は、資産を表現するトークンを発行して追跡するスマート・コントラクト、ＡｓｓｅｔＲｅｇｉｓｔｒｙを含む。これらのトークンは、資産同士の関係を管理して、バリュエーション・ファンクションなどの基本的な資産ファンクションを公開するためのインターフェースを実装する。資産は、ＡｓｓｅｔＣｌａｓｓＲｅｇｉｓｔｒｙモジュール１０６において追跡することが可能なクラスに割り振られてもよい。本明細書で使用される場合、用語「クラス」は、オブジェクト指向プログラミングの分野では周知であり、オブジェクト（特定のデータ構造）を作成するための「ブループリント」を称することができ、状態の初期値（メンバ変数又は属性）及び挙動の実装（メンバ関数又はメソッド）を与える。

資産クラス割り振りにより、トークンはそのクラスに特有の性質及びファンクションを公開することができる。ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８は、開発者が新しいインターフェース及び実装形態を公表して、クラス内のすべての資産の挙動を高度化又は拡張、例えば、アップグレード）できるようにする。ＩＣｏｎｔｒａｃｔＷａｌｌｅｔモジュール１１０は、資産、クラス、又はその資産を介してウォレットの機能性を提供する他の要素を表現する個々のトークンに付加することができるスマート・コントラクトベースの暗号ウォレットを実装して管理する。ＡｔｔｒｉｂｕｔｅｓＲｅｇｉｓｔｒｙモジュール１１２、ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙモジュール１１４、ＵｐｄａｔｅｓＲｅｇｉｓｔｒｙモジュール１１６、及びＰｏｌｉｃｙＥｎｇｉｎｅモジュール１１８は、以下で説明される方法で資産（及び他のサービス）によって使用される。

トークンが発行されると、ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４のＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトは、資産クラスをトークンに割り振り、ＩＣｏｎｔｒａｃｔＷａｌｌｅｔインターフェースを実装する新しいスマート・コントラクトをデプロイし、それによりウォレットをトークンに関連付ける。結果として、それぞれ作成されたトークンは、その識別子によってトークンにリンクされる一意なウォレット・アドレスを有することになり（図２に示される通り）、割り振られた資産クラスの性質及びファンクションを実装することができる。ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４は、ＩＷａｌｌｅｔＣｏｎｔｒａｃｔインターフェースを動作させて、ウォレットに関するアクションについてのポリシーを施行する。典型的には、ポリシーは、トークンの所有者のみが、ウォレット・コントラクトを介してアクションを実行できるようにする。ウォレットは、トークン、及び任意選択でＥｔｈｅｒ（ＥＴＨ）などの暗号通貨の移転又は受け取りの機能性をサポートする。ウォレットは、ＥＲＣ－２０、ＥＲＣ－７２１、ＥＲＣ－１４００及び他の標準的なインターフェース・トークンと互換性のあるトークンをサポートすることができる。

ＩＣｏｎｔｒａｃｔＷａｌｌｅｔモジュール１１０によって実装されるスマート・コントラクトは、ウォレットを運用して、ＵｐｄａｔｅｓＲｅｇｉｓｔｒｙモジュール１１６（すべての他のシステム・コンポーネント同様）を介してアップグレード可能性をサポートする。この構造により、変更された又はアップグレードされた挙動を実装する新しいウォレットのスマート・コントラクトの登録が可能となる。トークンの所有者、又は他の被指定者は、新しいウォレットのコントラクトをトークンに割り振るよう選択して、アップグレードされたファンクションを実装することができるか、又は場合によっては、そのような割り振りを拒否してもよい。ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８は、ＡｓｓｅｔＣｌａｓｓ（ＡｓｓｅｔＣｌａｓｓレジストリ・モジュール１０６から）又はＡｓｓｅｔインスタンス（ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４から）用にカスタマイズされたファンクションを提供するスマート・コントラクト・インターフェースを記憶する。それぞれのトークンは、属性、ファンクション、及びクラスの実装ロジックへのアクセスを提供するクラスに割り振ってもよい。Ａｓｓｅｔ又はＡｓｓｅｔＣｌａｓｓ所有者（又は被指定者）は、インターフェース・レジストリから実装形態を選ぶことができる。開発者は、所有者の資産についてのカスタム・ロジックを公開するために、所有者が選択できるように、カスタム実装形態を伴う新しいスマート・コントラクトをＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙモジュール１０８にサブミットすることができる。

スマート・コントラクトは、個々の資産を表現する非代替性トークンの発行を可能にするＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４を実装する分散台帳上にデプロイすることができる。本明細書では、ＡｓｓｅｔＲｅｇｉｓｔｒｙモジュール１０４を実装するスマート・コントラクトの物理的なデプロイメントを詳細に説明していないが、そのようなデプロイメントは当業者に十分に理解される従来的な技法を用いることができるためである。

トークン所有者モジュール１２０は、資産レジストリ１０４で資産（例えば、非代替性トークンによって表現される）に対して制御を行使するパーティのシステムに関連付けられる。この制御は、資産に対して制御権限を有する代替性又は非代替性トークンを介して割り当てられる権利を通じて直接的又は間接的にウォレットを介して行使されてもよい。

ポリシー・エージェント・モジュール１２２は、トークンの挙動を統制するポリシーを公表する権限を有するパーティのシステムに関連付けられる。トークン所有者は、公表されたポリシーを指定して、トークンに対して又はトークンを通じて実施される具体的なアクションを統制してもよい。ポリシー施行の詳細は、Ｃｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎの開示において、開示される。検証エージェント・モジュール１２４は、属性、つまりシステムにおけるオブジェクトの特性又は性質を作成するパーティのシステムに関連付けられる。検証エージェントは、オブジェクトに関する価値を属性付けるために証明する能力を有する。例えば、法律事務所は、規制ポリシー施行の目的で、ファンド資産が投資会社法（１９４０Ａｃｔ）ファンドである検証エージェントとして機能することができる。クラス・エージェント・モジュール１２６は、資産クラス・トークンに対する制御を行使するパーティのシステムに関連付けられる。この制御を使用して、クラス・エージェントは、クラスに関するすべての資産トークンに適用される属性及びインターフェースを選択することができる。認証エージェント・モジュール１２８は、コントラクト開発者によって公表されるスマート・コントラクト・コードが説明されるようなファンクションを実施すること、セキュアであること、及び欠陥がないことを認証するパーティのシステムに関連付けられる。コントラクト開発者モジュール１３０は、資産クラスに関するファンクションを実施するために資産トークンによって使用されるスマート・コントラクト・コードを開発するパーティのシステムに関連付けられる。これらのファンクションは、認証エージェントによって認証されると、クラス・エージェントによって追加され、アップグレードされ、又は除去されてもよい。システム開発者モジュール１３２は、資産レジストリ・モジュール２２０４又はコントラクト・ウォレット・モジュール１１０などのシステムのコア要素に更新を公表するように認可されたパーティのシステムに関連付けられる。

本明細書で開示されるモジュールは、単一の処理ユニット又は複数の処理ユニット内部に実装することが可能であり、モジュールのうちの１つ又は複数は他のモジュールから離れて実装してもよいことを諒解されたい。別のモジュールによって提供される機能性の説明は、説明を目的としたものであり、限定的であることを意図されていないが、モジュールのいずれも説明されるものより多い機能性、又は少ない機能性を提供してもよいからである。例えば、モジュールのうちの１つ又は複数は、取り除いてもよく、その機能性の一部又はすべては、モジュールのうちの他のものによって提供されてもよい。

図２は、開示される実装形態による、トークン・データ・レコード（トークン及び関連データ構造）２００の概略表現である。資産レジストリ１０４は、例えば、Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ（ＥＲＣ７２１）標準インターフェース（又は他の分散台帳で等価なもの）を実装して、非代替性トークンの発行を可能にすることができる。（例えば、ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｂｌｏｂ／ｍａｓｔｅｒ／ＥＩＰＳ／ｅｉｐ－７２１．ｍｄを参照）。追加的に、資産レジストリ１０４は、分散台帳などの非中央集権化された環境における資産管理用のファンクションを容易にする、本明細書で説明される新規なインターフェースを実装する。ファンクションには、資産バリュエーション・ファンクション２０２、所有権移転ファンクション２０４、及びデータ管理ファンクション２０６を含むことができる。以降で詳細に説明される、これらのインターフェース及び関連するデータ構造は、再帰的である可能性がある構造において、複合トークン、つまり他のトークンを含む又は他のトークンにリンクされるトークンの作成を可能にする。この新規な構造は、以降で非常に詳細に説明され、非中央集権化されたコンピュータ・アーキテクチャ上での、ファンドの実装形態、他の資産を含む複合資産を可能にする。

ＥＲＣ－７２１のトークン仕様と一致して、資産レジストリ・モジュール１０４は、非代替性トークンの発行を容易にし、各トークンは一意な資産を表現している。発行されたトークンごとに、資産レジストリ・モジュール１０４は、資産トークンの一意な識別子、資産クラス・レジストリ・モジュール１０６からの資産クラス、資産名称及び説明、トークンのウォレット２１０のアドレス（以降で説明する）、並びに資産に望まれるような他のデータなど、データ２０８を記録する。資産レジストリ・モジュール１０４によって記憶されるトークン・データ・レコード２００は、非代替性トークンを定義する。トークンには、米国特許出願公開第２０１９０１６４１５１（Ａ１）号において開示された方法を用いて追加的な属性及び価値が割り振られてもよい。デジタル・トークンは、ＩＡｓｓｅｔインターフェース・モジュール１０２のＩＡｓｓｅｔインターフェースを実装することができ、以降で説明するやり方で非中央集権化されたコンピューティング・プラットフォーム上で資産管理を容易にするファンクション２０２、２０４、及び２０６など、ファンクションのセットを公開する。データ構造２００を用いて、任意の価値の資産を「トークン化」することができる。つまり、資産の所有権を反映し、ファンド運用などのスケーラブルな運用をサポートするために必要とされるサポート用本質的な資産管理ファンクションに連結される、分散台帳上の一意なレコードとして発行することができる。以降で詳細に説明されるように、ＩＡｓｓｅｔインターフェース・モジュール１０２は、資産が次のことをできるようにする具体的なファンクションをサポートする：一貫性のあるデータ及びバリュエーション情報を提示すること；ファンド及び他の資産管理構造に参加すること；資産特有ロジックを実装すること；及び／又はネイティブな資産管理機能で作成されたのではない価値証書を表現する他のトークンをカプセル化すること。

上述のように、また図２及び図３で示されるように、トークン２００は暗号ウォレット２１０に関連付けられる。開示される実装形態にはインターフェース仕様及びデータ構造が含まれ、スマート・コントラクト及び／又は別個のトークンが、暗号ウォレットに関連付けられるようにする、つまり暗号ウォレットを所有できるようにする。この新規な構造は、トークンが他のトークンを所有すること、及び他のトークンをその所有権に追加又はそれから除去することを可能にして、他のトークン又はエンティティに対応するウォレット２１１と対話することにより、他のエンティティと取引を行うことを可能にする。他のトークンを含んでいる対応するウォレットを所有することにより、トークン・イン・トークン構造を表現しているトークンは、本明細書では「複合トークン」と称する。

資産レジストリ中の非代替性トークンには、資産レジストリ１０４によって、ＩＡｓｓｅｔＷａｌｌｅｔＦａｃｔｏｒｙインターフェースを用いてＩＡｓｓｅｔＲｅｇｉｓｔｒｙ．ＩｓｓｕｅＡｓｓｅｔファンクションを実装することにより、発行時にウォレット２１０が割り振られる（図２）（コード実例についてはＡｐｐｅｎｄｉｘ参照）。このインターフェースは、コントラクト・レジストリ１０８に記憶されるＩＣｏｎｔｒａｃｔＷａｌｌｅｔインターフェースを実装するスマート・コントラクトを、一意なトークンＩＤと関連付けて発行する。このインターフェースを実装するコードの実例は、Ａｐｐｅｎｄｉｘで見ることができる。

ウォレット・コントラクトのインターフェースは、ＩＡｓｓｅｔＷａｌｌｅｔラッパー、つまり、ＩＡｓｓｅｔトークンの所有者又はスマート・コントラクト・ロジックで実装されるような他のパーミッション構造体による使用のため、ＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトを介して利用可能な、付録で公表されるＩＡｓｓｅｔＷａｌｌｅｔインターフェース仕様に準拠するファンクションのセットを用いて実行することができる。署名者が、資産レジストリ１０４によって指定されるように、ファンクションを実行するよう認可されていない場合、例えばスマート・コントラクト・ロジックとして実装される場合、提案される動作（例えば、「トークンを送る」）は、許可されず、よって発生しない。ＩＡｓｓｅｔＷａｌｌｅｔは、付加されるコードのＧｅｔＷａｌｌｅｔファンクションを介してそのウォレット・アドレスを公開する。このアドレスは、分散台帳上のあらゆるウォレットと同じ方法で、取引の発信元又は目的地として使用することができる。

この構造では、ウォレットをトークンにリンクすることにより、以下のような有用な効果がもたらされる：トークンに対応する資産に代わって、実施されるアクションの完全なトレーサビリティ；ある戦略に基づいて売買する資産管理スマート・コントラクトを通じてアクションを自動化する能力；あるエンティティと取引しているかのように、資産のウォレットとの取引を行う能力；資産ウォレットを介する運用を含め資産運用にロバストなポリシーを挿入する能力（米国特許出願公開第２０１９０１６４１５１（Ａ１）号で開示されるようなもの）。

図３に示されるように、トークンに対応するウォレットが他のトークンを所有することが可能な「トークン・イン・トークン」構造により、トークン化された複合資産の作成が可能となる。複合資産の１タイプは、ファンド、他の資産を含む金融資産である。ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースをサポートするＩＡｓｓｅｔトークンとして発行されると、トークンは資産管理取引をサポートして、ファンド・マネージャによって手動で、又は分散台帳上のスマート・コントラクトベースのアルゴリズムを介して自動的に、ファンド管理戦略の実行を可能にする。このモデルを使用して、複合資産は、トークン化され、暗号通貨、他の資産トークン（単純、又は複合）、又はトークン化された資産の株などの資産を含むこと、追加すること、又は除去することが可能である。

さらには、トークン・イン・トークン構造は、ＩＡｓｓｅｔトークン・インターフェースで資産管理をサポートしていないサード・パーティのトークンを「ラップ」するために使用して、個々の資産としてファンド構造内で管理できるようにすることができる。サード・パーティのトークンをラップすることは、ＩＡｓｓｅｔトークンのウォレットへの単純な移転を通じて達成することができる。これにより、あらゆるトークン又はスマート・コントラクトを資産としてラップ及び処理できるようにして、自動化された資産管理及びファンド運用のための一貫した構造を公開する。これらの技術的な要素が整うと、複雑な自己処理ファンドを迅速に開始することが可能である。例えば、ＥＴＦ構造では、個々の資産を表現する１つ又は複数の非代替性トークンを、ＩＡｓｓｅｔＲｅｇｉｓｔｒｙ．ＩｓｓｕｅＡｓｓｅｔファンクションを使用して資産レジストリ・モジュール１０４を介して発行することができる（コード実例についてはＡｐｐｅｎｄｉｘ参照）。それぞれのトークンは、ＩＡｓｓｅｔインターフェースを実装し、これはＩＡｓｓｅｔＴｒａｎｓｆｅｒａｂｌｅインターフェースを介して実装された所有権移転ファンクションを用いて基本的なＥＲＣ７２１仕様を拡張して、資産管理をサポートし、透明性を向上させ、マーケットプレイスでの資産の購入と販売をサポートする。

図４は、資産所有権の移転ファンクション（図２の２０４として示される）の処理フロー４００を概略的に示している。上述のように、トークンは、ＥＲＣ７２１標準インターフェースを実装することができ、このインターフェースは、従来的な所有権及びＥＲＣ７２１仕様で定義される移転ファンクションを含む。トークンはまた、米国特許出願公開第２０１９０１６４１５１（Ａ１）号で開示されるコンプライアンス意識フレームワークを実装することもできる。本明細書で開示される実装形態は、このフレームワークを、体系立った資産の購入、販売、及びリンクを可能にするためのファンクションで拡張する。

図４の４０２に示されるように、トークンの売り注文は、パラメータ（ｕｉｎｔ ｔｏｋｅｎｉｄ．ｕｎｉｔ ｐｕｒｃｈａｓｅ Ｔｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒＩｄ）を含むデータ構造に対して演算するｃｒｅａｔｅＳｅｌｌＯｒｄｅｒファンクションを用いて作成することができる。ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションは、ｏｒｄｅｒ ｉｄに対して演算し、Ｂｏｏｌｅａｎを返す。ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションがＦＡＬＳＥを返すと仮定すると、トークンの買い手は売り注文を受け入れ、ａｃｃｅｐｔＳｅｌｌＯｒｄｅｒファンクションが実行される。４０４に示されるように、ｃａｎｃｅｌＳｅｌｌＯｒｄｅｒファンクションがＴＲＵＥを返す場合、つまり売り注文がキャンセルされた場合、注文処理は、販売で終了する。

４０６に示されるように、トークン購入では、ｃｒｅａｔｅＰｕｒｃｈａｓｅＯｒｄｅｒファンクションがパラメータを含む（ｕｉｎｔ ｔｏｋｅｎｉｄ，ｕｎｉｔ ｐｕｒｃｌｌａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｎｉｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）データ構造に対して実行され、注文識別情報を（ｕｉｎｔ ｏｒｄｅｒｉｄ）の形式の注文ＩＤとして返す。ｃａｎｃｅｌＰｕｒｃｈａｓｅＯｒｄｅｒファンクションは、パラメータ（ｏｒｄｅｒｔｄ）に対して実行され、Ｂｏｏｌｅａｎを返す。戻り値がＦＡＬＳＥである場合、購入は、パラメータ（ｏｒｄｅｒｉｄ）に対するａｃｃｅｐｔＰｕｒｃｈａｓｅＯｒｄｅｒファンクションの実行によって受け入れることができ、購入がクリアされる。代替的に、４０８に示されるように、購入はパラメータ（ｏｒｄｅｒｉｄ）に対してｒｅｊｅｃｔＰｕｒｃｈａｓｅＯｒｄｅｒファンクションを実行することによって拒否される。代替的な手法として、売り注文は、ｐｕｒｃｈａｓｅＦｒｏｍファンクションをパラメータ（ａｄｄｒｅｓｓ＿ｉｒｏｍ，ａｄｄｒｅｓｓ＿ｔｏ，ｕｉｎｔ２５６＿ｔｏｋｅｎＩｄ，ｕｉｎｔ＿ｏｒｄｅｒＩｄ，ｂｙｔｅｓ ｄａｔａ）を含むデータ構造に対して実行することによって、ペイロード中にｏｒｄｅｒＩＤを含む資産レジストリ・ウォレットへの支払いを行うことによって実行されてもよい。

上述のように、トークン同士の取引は、個々のトークンに関連付けられるウォレットのおかげで達成される。トークンのウォレット・アドレスは、例えばＡｐｐｅｎｄｉｘにあるコードを実行することによって実装することが可能なＩＡｓｓｅｔＷａｌｌｅｔ．ＧｅｔＷａｌｌｅｔインターフェースを介して取得されてもよい。配分ロジックは、資産によって内部的に、又はインターフェースを使用して外部的に開始されてもよい。

金融市場における透明性という重要な態様は、投資家及び投資予定者が資産のメタデータ、文書、及びサポート・データ・フィードを見る能力である。この情報は、投資家に公正な市場価格に対する彼ら自身のセンスをみがくための手段を与え、同様に、市場における価格を評価する責任をタスクとされたアセット・マネージャなどの仲介のパフォーマンスを評価するメカニズムを提供する。従来的に、そのような情報は、静的なやり方で照合されなければならず、したがってデータの時間ベースのレポーティングは先行技術のシステムでは実用的ではない。開示される実装形態は、資産デュー・ディリジェンス用の包括的なデータ構造を含み、スケーラブルな透明性；ＲＭＢＳポートフォリオに欠落しているファンクション及び先行技術の他の複雑な資産を提供する。

透明性は、資産の性質又は属性を、作成する、維持する、及び検査する能力を必要とする。資産のタイプは広範にわたるため、それに従って資産の属性はさらに幅広く変化する。広範囲な資産の全体に対するデータ分析をサポートするべく、あらゆる認可されたパーティによって証明された通りにあらゆる資産のあらゆる性質を管理するために、一貫性のあるフレームワークが必要とされる。実装形態は、資産の性質を管理する基本的なメカニズムとして、属性管理（ＥＲＣ１６１６）仕様（ｈｔｔｐｓ：／／ｅｉｐｓ．ｅｔｈｅｒｅｕｍ．ｏｒｇ／ＥＩＰＳ／ｅｉｐ－１６１６）を含む。開示される実装形態はまた、この仕様をＣｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎフレームワーク（米国特許出願公開第２０１９０１６４１５１（Ａ１）参照）を介して、これらの属性に基づいてスケーラブルな信用証明及びポリシー施行を含むよう拡張することが可能である。

追加的に、資産デュー・ディリジェンスは、しばしば文書及びデータ管理を必要とする。分散台帳は、文書化及びデータ並びにこのデータにアクセスするためのアクセス可能なフレームワークをサポートするために不変な記録を提供することができるという点で、文書管理に具体的な利点を提供する。実装形態は、文書管理（ＥＲＣ１６４３）仕様（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ＥＩＰｓ／ｉｓｓｕｅｓ／１６４３）を含む。開示される実装形態はまた、非代替性トークンを使用してサポート・データのスキーマ及び他の特性を説明する非代替性トークンを介して、サポート・データセットをトークン化するためのメカニズムを含む。この仕様は、配分制御及び機密データの監査を実現するための認可トークンの使用を含む、高度なデータ承認技法をサポートする。ポリシーベースのデータ・アクセス及び管理は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号によって示される、非中央集権化されたアクセス制御によって示される技法を用いて達成することができる。

アセット・マネージャの１つの最も重要な信託責任は、管理する資産のバリュエーションを評価して公表することである。このことは、マネージャに利用可能な情報に基づいて、アセット・マネージャの価値の理解の記録を投資家に提供するが、この情報は、ほとんどの資産では、評価の時点で投資家によって入手可能な情報を上回っている。図５は、開示される実装形態の資産バリュエーション・ファンクションについて処理フロー５００及び関連するデータ構造の実例を図示している。これらのファンクションは、資産バリュエーションの公表及びアクセスのための、一貫性のあるメカニズムを提供する。バリュエーション用の共通インターフェースは、分析ツールの統合を簡略化する。これはまた、異種資産のバリュエーションを容易にし、多様化したファンドの形成を促進する。上述のように、資産トークンはバリュエーション・インターフェースを公開して、投資家が資産価値の現在の評価を見ることを可能にする。ある範囲の既知の会計技法を使用して資産価値を評価することができる。使用される技法は、資産のｖａｌｕｅＴｙｐｅ属性フィールドで指定される。資産トークンは、価値評価をサポートするために、内部ロジックを有することができる。資産バリュエーション・ファンクションは、Ａｐｐｅｎｄｉｘにあるコード実例を実行することによって、実装することができる。

図５に示されるように、リクエスト側（投資家など）は、トークン１に対してｇｅｔＶａｌｕａｔｉｏｎリクエストを行うことができ、トークン１のバリュエーションはトークン１によって返される。リクエストには、適用されるバリュエーション・モデルが含まれる可能性がある。必要であれば、トークン１によってどのバリュエーション・モデルがサポートされるかを確かめるために、ｇｅｔＳｕｐｐｏｒｔｅｄＶａｌｕａｔｉｏｎＭｏｄｅｌリクエストを行うことができる。資産バリュエーションを生成するためのロジックは、実装形態及び資産クラスによって変わってもよい。

一実装形態では、バリュエーションは証明として、つまり検証済パーティによって完全な帰属が割り振られた属性値として、資産所有者、マネージャ、又は他の認可されたパーティによって公表される可能性がある。他の実装形態では、バリュエーション・データは、資産 レジストリ・モジュール１０４（図１）のスマート・コントラクト・コードによって、又は資産クラス・レジストリ・モジュール１０６（図１）のクラスに割り振られた通りに生成される。このロジックは、価値を評価するために資産のリアルタイム属性、為替価格などの外部のデータのソースに到達するための「オラクル」、又は他のソースを使用することができる。例えば、ローンを表現する資産トークンでは、ＰＡＲバリュエーションは、ローン・トークンの属性（図１の属性レジストリ・モジュール１１２で見つかる）、ローンの未払い元本である。ローンによって返済が処理されると、この属性に割り振られた価値は、ローン処理スマート・コントラクトによって変化し、属性は異なる値となる。関連する値をｓｅｔ及びｇｅｔするための、属性レジストリ・モジュール１１２の実装形態及びメカニズムに関する詳細は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号に開示されている。

一実装形態では、バリュエーション・タイプ「ＰＡＲ」へのリクエスト（ＧｅｔＶａｌｕａｔｉｏｎ）は、ＡｓｓｅｔＲｅｇｉｓｔｒｙスマート・コントラクトの実装形態を介して、属性レジストリ・モジュール１１２（図１）の「ＰＡＲ」Ｖａｕｌｅ属性を指すように構成される。この属性は、現在の元本、つまりローンの未払い残高を含み、これがリクエストに応答して返される。いくつかのバリュエーション結果は、バリュエーションを生成するためにデータの複雑なリアルタイム分析を必要とする場合がある。バリュエーションを取得するための別個のメカニズムを図示するために、ローンの純資産価値（ＮＡＶ：Ｎｅｔ Ａｓｓｅｔ Ｖａｌｕｅ）計算が、割引キャッシュ・フロー及びローン受け取り側の支払い挙動に基づいて決定されてもよい。具体的には、バリュエーション・タイプ「ＮＡＶ」に対するバリュエーション・リクエストは、コントラクト・レジストリ・モジュール１０８（図１）を介してＡｔｔｒｉｂｕｔｅＣｌａｓｓ「Ｌｏａｎ」に割り振られたスマート・コントラクト・コードを利用して、現在の利率、ローンの利率、及び資産ウォレットで観察することができるキャッシュ・フローに基づく借主の支払い履歴に基づいてローンの純現在価値を計算してもよい。

別の実例として、「ＭＡＲＫＥＴ」値は、分散台帳の外部のソースからデータを取得するために一般的に使用される方法である、オラクルを活用してもよい。別個に開示されるように、属性レジストリ・モジュール１１２は、最新の価値、この場合では資産の現在の為替価格を取得するための命令を含む。明瞭さのためにいくつかの実例を与えたが、実装形態はそれらに限定されない。しかしながら、資産ごとに構成され得るこのデータを取得するための方法を割り振るための手段は、「自己レポーティング資産」、つまり自身のデータ構造内に自身のバリュエーションを計算して公表する手段を含む資産を提供するための新規なメカニズムを提供する。開示される方法は、監査又はレポーティング・システムの、バリュエーション・データのソースの具体的な実装形態への依存性を解消する。これは、多くの異なるバリュエーション・データのソースを含むファンドなど、複雑な資産のバリュエーションを生成するために必要とされる、複雑なシステム統合を解消する。開示される技法なしには、投資家はこのデータを取得するための手段を持たないことが多い。透明性が欠落することの結果として、２００８年の世界的な金融危機で実証されたような破滅的な影響を及ぼす可能性がある。

リクエストのデータ構造が、５０２に示される。重要なことに、複合資産の場合では、トークン１は、子トークンを所有することができるか、及び又は上述のやり方で別のトークンの「ラッパー」として機能することができる。そのような場合、トークン１は、リクエスト側への応答に先立つバリュエーションと類似のやり方で、すべてのそのようなトークン、図５ではトークン２をクエリする必要がある。５０４で示されるように、トークンが発行されると、トークン発行者ファンクションを通じてバリュエーションをセットすることが可能である。

開示される実装形態はバリュエーション用に共通のインターフェースを公開しているが、上述のように、サポートされる範囲の資産タイプのバリュエーションを計算するために異なる技法を使用することが可能である。ある資産タイプのバリュエーションを計算するための一意なスマート・コントラクト・ロジックは、（ｈｔｔｐｓ：／／ｈａｃｋｅｒｎｏｏｎ．ｃｏｍ／ｈｏｗ－ｔｏ－ｍａｋｅ－ｓｍａｒｔ－ｃｏｎｔｒａｃｔｓ－ｕｐｇｒａｄａｂｌｅ－２６１２ｅ７７１ｄ５ａ２）で開示されるような既知のｐｒｏｘｙ技法を介して参照することができる。例えば、多くの資産はＰＡＲ価格、つまりその額面をサポートしている。ほとんどの管理資産は、市場価格、流動性、割引キャッシュ・フロー、又はその内容の他の評価値に基づいて計算されるＮＡＶを有している。資産が定期的に売買される場合、この資産は市場価格と価値を有する。ＰＡＲ、ＮＡＶ及び市場価値は、同じ資産でも異なる場合がある。例えば、ローンは、未払い元本に基づいたＰＡＲ価格、割引キャッシュ・フロー及び債務不履行の確率に基づいたＮＡＶ、並びに資産が容易に売買される場合又は最近購入された場合は市場価値を有する。これらの価値の違いは、資産パフォーマンス、格付けエンティティ、又はそのアセット・マネージャの価値評価における信頼に対する変化する市場認識に対する洞察を与えることができる。

資産バリュエーションは、一度だけ、定期的に、又は継続してほぼリアルタイムに評価されてもよい。データ・フォーマットは、価値評価がどれくらい古いか、及びどれくらいの間隔でそれが有効なままであると期待されるかを知るためのビューワ（例えば、及び所有者又は他の市場関係者）情報を提供する。追加的に、仕様は、バリュエーション履歴の標準化フィードへのリンクを提供することができる。これは、レビュワーに資産の履歴的なパフォーマンスを見るツールを与える。リンクは、データへの直接的なアクセスの代わりに設けられるが、履歴的な分析に必要な記憶、探索、及びインデックス付け用のツールは資産トークンが記憶されるツール（本実装形態では分散台帳）とは異なる可能性があるためである。

開示される実装形態はデータ通信を改善して、それによりマネージャに利用可能な情報と投資家に利用可能な情報とのギャップを埋めることができるが、データのフローは、図１のポリシー・エンジン１１８においてアーキテクチャによって、例えば設計による決定ギャップを作成するよう制御することができる。例えば、特定の情報に関するデータ・フローの限度は、所望の限度又は投資家の利益になる限度であってもよい。例えば、アセット・マネージャは、「フロント・ランニング」（経済上の利点を得るために、大規模な非公表注文の直前に、ブローカ又はトレーダーが売買を行う慣行）を防止するために、又はその他の方法で投資パフォーマンス若しくは投資技法を保護するために、一般提供からの特定情報を保留したいと思う場合がある。投資家は、パフォーマンスと透明性との間でトレードオフを行うよう選ぶ場合があり、アセット・マネージャは機密性の必要に対してバランスの取れた市場需要に基づく開示を余儀なくされる。

図１に関して上述したように、資産がいったんＩＡｓｓｅｔモジュール１０２のＩＡｓｓｅｔＴｏｋｅｎインターフェースを使用してトークン化されると、ＥＴＦ自己レポーティング・ファンドなどのファンドを開発する際の次のステップは、開示される実装形態によると、ＩＡｓｓｅｔモジュール１０２のＩＡｓｓｅｔＦｕｎｄインターフェース構造を使用するファンド・トークンの発行である。この構造は、ＩＡｓｓｅｔＴｏｋｅｎ構造及びファンクションをＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースで拡張する。ファンド・トークンは、資産クラス・レジストリ・モジュール１０６のＩＡｓｓｅｔＲｅｇｉｓｔｒｙインターフェースを介して発行されるが（他のトークン同様）、資産クラス・レジストリ・モジュール１０６からの、このクラス用の値を割り振ることによって、「Ｆｕｎｄ」に等しいタイプ・パラメータが割り振られる。もちろん、ファンドは他の資産を含むことができる資産である。個々の資産に利用可能な同一のファンクションがファンドに適用される。しかしながら、ファンドは、ファンド内に含まれる資産を管理するために必要なファンクションを提供することによって、ＩＡｓｓｅｔトークンの基本的なロジックを拡張する。

図６に示されるように、開示される実装形態のファンド資産トークン６００は、図２の資産トークン２００に類似している。しかしながら、ファンド資産管理トークンは、資産管理ファンクション２１２を含む。資産管理ファンクションは、資産レジストリ・モジュール１０２のＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔインターフェースを介して実装され、処理スマート・コントラクトが割り振られ、トークン・ウォレットを利用するため、すべての取引は分散台帳に記録することができ、不変である。このことは記録管理、監査、及びレポーティングを簡略するための透明性を与える。資産管理インターフェースは、一貫性のある取引インフラストラクチャを提供して、それぞれの資産クラス又はファンド管理戦略に特有のロジックの開発を合理化している。このことは、中心部のトークン構造及びインターフェース・フットプリントを変更することなく置換、拡張、又はアップグレード可能な内部ロジックにより実行される新しい資産タイプのための管理戦略のデプロイメントを容易にする。さらには、この実装形態は、共通の資産管理ファンクションを介して広範な資産タイプをサポートし、本実装形態の特性である。

より具体的には、ファンド・トークン６００のファンド・トークン仕様は、基本的な資産インターフェースを拡張して、認可されたエンティティがＩＦｕｎｄＭａｎａｇｅｍｅｎｔ．ＧｅｔＡｓｓｅｔｓインターフェースを使用してファンド内のすべての資産を列挙できるようにする。ファンド内の資産を列挙することにより、それぞれがＩＡｓｓｅｔインターフェースをサポートして、ビューワが含まれる資産の利用可能な情報を掘り下げることが可能となる。例えば、次のファンド管理ファンクション及び関連データ構造を、サポートすることが可能である。
・ａｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎｅｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔｏｒｄｅｒｉｄ）；
・ｃａｎｃｅｌＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒｅｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｒｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎｅｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎｉｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔｅ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒｅｄ）；
・ｃａｎｃｅｌＲｅｍｏｖｅＡｓｓｔＲｅｑｕｅｓｔ（ｏｒｄｅｒｅｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｇｅｔＡｓｓｅｔｓ（）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎ（ｕｉｎｔ［］）；／／付加された非代替性トークンのアドレスのアレイを返す
・ｅｖｅｎｔ ＡｓｓｅｔＡｄｄｅｄ（ｕｉｎｔ ｔｏｋｅｎｅｄ）；
・ｅｖｅｎｔ ＡｓｓｅｔＲｅｍｏｖｅｄ（ｕｉｎｔ ｔｏｋｅｎｅｄ）

それぞれのファンクションの実例は、Ａｐｐｅｎｄｉｘに含まれている。ファンド・トークンが発行されると、ファンド作成処理における次のステップは、資産をファンドへ移転することである可能性がある。ファンドは、ゼロから多くの資産まで含む可能性があることに留意されたい。資産は、トークンの資産管理ファンクション、ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ及びＲｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔを使用して購入される又はファンドから清算される。あらゆるトークン取引と同様、資産管理アクションは分散台帳に記録される。これらのファンクションは資産レジストリによるインターフェースとして公開され、ＩＡｓｓｅｔトークン・ウォレット及び資産所有権移転ファンクションを利用して、図２のトークン２００に関して上述したのと類似のやり方で資産取引を実行する。

非代替性ファンド・トークン６００は、売買及び他の取引を容易にするために、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェースを使用してトークン２００などの代替性トークンに連結する（つまり、代替性トークンで「ラップ」する）ことができる。あらゆる資産トークンは、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェースを実装する代替性トークンでラップして、資産の部分所有権を容易にし、株主への配当配分、株主投票、コーポレート・コミュニケーションなどの非代替性トークン用に構築されたコーポレート・ファンクション用のロジックを再使用することができる。ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅ構造を実装するトークンは、ＥＲＣ２０標準（イーサリアム代替性トークン）を拡張する新しいスマート・コントラクト・インターフェース（ＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ、ＲｅｍｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ）を含む。これらのインターフェースにより、代替性トークン発行者が、ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅインターフェース内の定義されたファンクションを使用して非代替性資産トークンを移転することによって、１つ（且つ、１つだけ）の資産トークンを代替性トークン・シェルに／から追加又は除去できるようになる。

代替性トークンの実装形態はまた、インターフェース（ＩＡｓｓｅｔＭａｎａｇｅｍｅｎｔＦｕｎｇｉｂｌｅ．ＧｅｔＡｓｓｅｔ）を含み、認可されたパーティが代替性トークンによって表現される株式の基礎となる資産を検査することを可能にしている。非代替性トークンによって公開される、バリュエーション・ファンクションは、代替性トークンに連結され、株主（代替性トークンの所有者）が基礎となる資産のうち自身の所有割合を容易に計算することを可能にしている。例えば、基礎となる資産のＮＡＶが１，０００，０００ドルであり、ウォレットがその資産の流通における全株式１０００のうち１００（１０％）を保有している場合、１００株式を表現するそのウォレット中の代替性トークンの全ＮＡＶは、１００，０００ドルである。

代替性トークンを、資産及びその管理に特有な非代替性トークンに取り込まれるロジックから分離することによって、実装形態は最大の再使用を容易にして、資産特有コードの開発及び検証を簡略化する。追加的に、この手法は資産構造を保持して、合併、又は税務上の理由、ガバナンスの理由若しくは責任の理由から株式獲得の代わりに資産獲得が所望される獲得手法を容易にする。資産獲得は金融では一般的な技法であり、データ・モデル及び開示される実装形態のアーキテクチャがない場合、実用的なタスクにはならない。リンクされたトークン手法は、為替売買ファンドへの、及び為替売買ファンドからの資産の移転を容易にして、親ファンドから切り離された時の資産の流動性を可能にしているが、証券化のためにファンドによって購入されると便利な管理が可能となる。

図７は、例えばファンド・トークンによって表現されるファンドの部分所有権を可能にする取引のために非代替性資産トークンを代替性トークンでラッピングするためのデータ・モデル７００の概略図である。「部分所有権」とは、代替性の資産が細かく分割できるために、２者以上の資産の所有者が存在できるような状況を指す。７０２に示されるように、基本的なトークンのタイプは「ウォレット」、「代替性の株式」、及び「非代替性の資産」である。７０４で示されるように、トークンに関連付けられるウォレットは、例えば図１に関して上述したメカニズムを通じて代替性の株式及び／又は非代替性の資産を表現する他のトークンを所有することができる。これにより、非代替性トークンのラッパーの配当配分及びコーポレート・ガバナンス・ファンクションを利用することができるため、資産非代替性トークンの構造及びスマート・コントラクト・コードが簡略化される。ファンド内の株式は、代替性トークンによって表現され、７０６に示されるように１つ若しくは複数のウォレットによって、又は資産によって所有することができる。代替性トークンにリンクされるスマート・コントラクトは、７０８に示されるように、ファンド内の代替性資産についての所有権及び管理ファンクションを公開する。ファンクションは、Ａｐｐｅｎｄｉｘにも示されているが、以下を含むことができる：
・ａｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏｋｅｎＩｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎＩｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒｉｄ）；
・ｃａｎｃｅｌＡｄｄＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒＩｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｒｅｒｎｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｕｉｎｔ ｔｏＫｅｎＩｄ，ｕｉｎｔ ｐｕｒｃｈａｓｅＴｏｋｅｎＩｄ，ｆｌｏａｔ ｐｒｉｃｅ，ｕｉｎｔ ｅｘｐｉｒｅｓ，ａｄｄｒｅｓｓ ｂｕｙｅｒ，ｂｙｔｅｓ ｄａｔａ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｕｉｎｔ ｏｒｄｅｒ１ｄ）；
・ｃａｎｃｅｌＲｅｒｎｏｖｅＡｓｓｅｔＲｅｑｕｅｓｔ（ｏｒｄｅｒ１ｄ）ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎｓ（ｂｏｏｌ）；
・ｇｅｔＡｓｓｅｔ（） ｅｘｔｅｒｎａｌ ｒｅｔｕｒｎ（ｕｉｎｔ）；／／付加された非代替性トークンのアドレスを返す
・ｅｖｅｎｔ ＡｓｓｅｔＡｄｄｅｄ（ｕｎｉｔ ｔｏｋｅｎＩｄ）；
・ｅｖｅｎｔ ＡｓｓｅｔＲｅｒｎｏｖｅｄ（ｕｎｒｔ ｔｏＫｅｎＩｄ）；

例えば、資産は、ローン返済が受け取られると、資産を所有するウォレットを支払う自己処理ローンであってもよい。このウォレットが代替性トークン・スマート・コントラクトによって所有されている場合、これらの売り上げは、代替性トークンの所有者に比例して配分されてもよい。親子トークン構造はまた、代替性トークンにおける確立された取引ロジック及び交換ファンクションの再使用を容易にしつつ、資産特有ファンクションにおける特殊化、この場合ではローン処理を可能にする。上述のように、ファンドは代替性トークン及びリンクされた管理スマート・コントラクトによって定義されるため、ファンドはゼロ（ヌル）資産を有することができる。

ＩＡｓｓｅｔＦｕｎｄトークンは、資産、他のファンドのための資産トークン、他の資産の代替性の株式、又はファンド資産の株式、のうちのいずれかを含んでもよいため、実装形態は、図８に示されるように資産のネスト化をサポートしており、図８はそのようなネスト化のためのデータ・モデルの概略的表現である。ネスト化は、ファンド・オブ・ファンド構造及び大規模なポートフォリオの多様化技法を容易にする。８０２に示されるように、トークン・ウォレットは、ファンド内の株式を表現する代替性トークンを所有することができ、このファンドは８０４に示されるように、非代替性の資産を所有する。さらには、８０４に示されるように、非代替性トークン（例えばファンドを表現する）、代替性トークン、及び他の資産（この実例では、暗号通貨ｅｔｈｅｒなど）が、非代替性トークンによって所有され得る。図１、図２、及び図６に関して上述したウォレット構造及びアーキテクチャは、この再帰的な所有権構造が非中央集権化されたシステムに関連して使用することができるデータ・モデルによって表現できるようにする。

ＩＡｓｓｅｔＦｕｎｄがＩＡｓｓｅｔ構造を拡張してＦｕｎｄ管理ファンクションを実装するのと同じ方法で、ＩＡｓｓｅｔ構造は他の資産タイプに対して拡張して、トークンの多型性を可能にすることができる。例えば、実装形態は、ＩＡｓｓｅｔＬｏａｎトークン、つまり図１の資産クラス・レジストリ・モジュール１０６からのクラス・タイプＬｏａｎを有するＩＡｓｓｅｔトークンを発行することができる。このクラスは、自己処理ローン、つまり、ＩＡｓｓｅｔウォレット及び割り振られたＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌスマート・コントラクト・ロジックを介して内部的に支払いを処理するローンを実装することができる。支払い処理向けのカスタムのスマート・コントラクトは、それらの所有者によってＡｓｓｉｇｎＷａｔｅｒｆａｌｌＰｒｏｃｅｓｓインターフェースを用いてローンに割り振ることができる。継承を通じて導出クラスによってファンクションを置き換えられるようにするこの慣行は、オーバーローディングとして知られている。インターフェース構造を使用するオーバーローディングにより、同じファンド内で異なるローン処理戦略の実行が可能となる。

ＩＡｓｓｅｔ構造を継承することによって、ＩＡｓｓｅｔＬｏａｎトークンは、そのウォレットへの支払いをあらゆる受け入れ通貨で受け取り、そのあらゆる未払い元本への更新を含めて支払いを処理し、手数料を処理して、その売り上げを所有者に渡すことができる。すべての取引及び支払いは、台帳上で検査することができ、透明性及び資産バリュエーションに必要とされるデータを与える。ＩＡｓｓｅｔＦｕｎｄの資産管理ファンクションを使用して、ＩＡｓｓｅｔＬｏａｎトークンは、ファンド・トークンに付加されてもよい。ローン・トークンは、証券化されたファンドを作成するための、多くのＩＡｓｓｅｔＬｏａｎトークンのうちの１つであってもよい。ローン支払いは、それぞれのローンによって自動的に処理され、売り上げは親ファンドに渡され、そこでさらに管理手数料、配当配分、及びＩＡｓｓｅｔＦｕｎｄトークンによって管理されるような他のファンド・ファンクションとして処理することができる。この構造は、完全に透明であり、無期限にスケーリングできる自己処理型の証券化されたローン・プールを作成する。

自己処理、自己処理における自己レポーティング・ローン資産、自己レポーティング・ファンドは、世界的な金融危機の発端となった大規模な証券化ローン（例えば、ＲＭＢＳ）ファンドには存在しない透明性を与える。類似の技法を使用して、あらゆるタイプの資産のファンドを作成することができ、投資家に新しい投資機会の多様なセットへのアクセスを提供する。さらには、上述のデータ・モデル及びアーキテクチャは、より高度化されたファンド管理戦略の自動化を簡略化する。図９は、発行市場及び流通市場における資産管理用の、一般的な取引を伴うファンド管理環境９００を概略的に図示している。実装形態は、上で開示されるＩＡｓｓｅｔ及びＩＡｓｓｅｔＦｕｎｄインターフェースの使用を通じて運用のそれぞれをサポートする。図９のそれぞれの取引を以下で説明する。

資産収入から資本準備金への処理（１）：資産プール（リース、債券、債務証書、配当支払い株式など）内の収入を得る資産は、内部的な自動化されたモデル又は外部モデルを使用して収入を処理する。これらの利益は、配分用の資産ウォレットを介して処理され、資産パフォーマンスの完全なトレーサビリティを提供する。ファンド・トークンの所有者が、ＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌリクエストを、そのＩＡｓｓｅｔインターフェースを介して実行すると、ファンドによって所有されるＩＡｓｓｅｔのそれぞれに対してＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌリクエストが呼び出される。このリクエストの結果、ファンドの資産は利益をファンドの資本準備金（ＩＡｓｓｅｔウォレット）に移転する。ファンドは、内部的なウォーターフォール・ロジックを実行してこれらの利益を処理する。ウォーターフォールのロジックは、革新的又は繰返し可能なファンド管理戦略をサポートするための、プラグインのスマート・コントラクトであってもよい。処理が完了すると、ファンドは、トークンの処理ロジックによって定義される通りにトークンの所有者に移転される（これによってトークンの所有者によってさらなる配分ロジックが実行される場合がある）。

ポートフォリオ・ヘッジ／管理手数料の処理（２）：典型的には、ファンドのウォーターフォールは、資産管理手数料の支払いを含み、またヘッジ及び保険などのファンド運用向けの他の内部的なサービスを伴ってもよい。これらの手数料は、ウォレット移転ロジックを使用して資本準備金（資産ウォレット）から支払われ、ウォーターフォール・ロジックのスマート・コントラクトを介して実行されてもよい。ファンドの一貫した額面価格を維持するために、これらの支払いは、資産収入又は他のソースへ、資産収入又は他のソースから補充されなければならない。

償却／ターンオーバを補充する処理（３）：資産は、所与の期間（残りの価値をゼロとする）で償却される場合がある。償却は、ローンの債務不履行又は資産のアンダーパフォーミングにより生じる。一定の額面価格を維持するために、ウォーターフォールを処理する一部として資本準備金からの資産を使用して、償却は補充されなければならない。「リスクのある」収入の流れ、つまり今後の期間に債務不履行になり得る延滞ローン、又はアンダーパフォーミングの資産をサポートするために、十分な残高が資本準備金に（配分されずに）保たれるべきである。

資産の満了を補充する処理（４）：満了する、非流動性資産で構成されるファンドなど、あるタイプのファンドでは、資産から収入が処理されると、資産残存価値（収益力）が減少する。例えば、ローンの元本を減少させる住宅ローンの支払いは、結果として資産の収益力、その残存価値を減少させる。ファンドの一貫した収益力を維持するために、残存部分は、資産の購入を通じて、類似又はより良好な収益力で置き換えられるべきである。収益力が実現されると、結果として資産プールの残存価値が減少し（満了）、一方でファンド資本準備金におけるキャッシュが増加する。資本準備金資産を使用する資産購入は、ＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＯｒｄｅｒファンクションを使用する。含まれているファンドへの資産分配から収入をＲｅａｌｉｚｉｎｇするための資産購入は、典型的には資産の収入源リスクに比例してポートフォリオの全体的なＮＡＶを増大させる（資本準備金残高の増大が、資産プールのＮＡＶの減少を超える）。すぐに満了する資産（貿易金融）から構成されるポートフォリオでは、所与の期間にかなりの満了を迎える。満了割合が高いほど、ファンドの弾力性が大きくなる（ファンドの弾力性は、基礎となる資産の弾力性に関係する）。

クーポン又は配当配分の処理（５）：ファンドは、クーポン収入又はキャッシュ配当を所有者／株主に提供することができる。「キャッシュ」は、あらゆる資産（フィアット、暗号通貨、又は他の資産タイプ）であってもよいが、典型的には、流動的で、ファンドの株とペアで容易に売買され、資産収入と同一の資産タイプである。クーポン配分は、他のファンド支払いより先に優先的に支払われるが、配当配分は、他のウォーターフォール責任が満足された後に残る売り上げから成る。ファンドの安定性を確保するために、クーポン配分は、特に資産収入が揮発性又は不確実性の場合、ファンド資産からの全体的な期待収入未満であるべきである。配分は、ＰｒｏｃｅｓｓＷａｔｅｒｆａｌｌメソッドを介して行われる。ＣＡＴ代替性トークンは、株主配分ファンクションを含む。資産トークンを代替性トークンに付加することによって、ファンド株主への配分は、自動的に大規模に処理することができる。多くのファンドは、クーポン配分又は配当支払いを提供しない。これらの場合では、資産収入は、ファンドの額面価格を上昇させる。

現物株配当の処理（６）：ファンドは、キャッシュの配当ではなく、ファンドの株式を使用して配分を支払ってもよい。この戦略は、税務目的又は流動性を向上させるために、一部のファンドで用いられる。資本準備金からのファンドは、配分される株式を購入するために使用されてもよい。これらの株式は、いくつかの戦略を用いて購入することができる：流動的な流通市場から、ファンドＮＡＶにおける発行市場での流動性準備金プール（後述）から、又はファンドＮＡＶと一貫する株式トークンを発行することによって。株式の購入、償還、及び配分モデルの柔軟性により、ＩＡｓｓｅｔＦｕｎｄ構造が、ＥＴＦ、ミューチュアル・ファンド、又はクローズドエンド型のファンドを含むあらゆる既存のファンド管理戦略をサポートすることが可能となる。これはまた、税務又は流動性の恩恵のために、ファンド収益最適化戦略をサポートする。

発行市場購入の処理（７）：ＩＡｓｓｅｔＦｕｎｄトークンは、部分所有権を容易にするために、代替性トークンに付加されてもよい。投資家は、代替性トークン・インターフェースによってサポートされるＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔ及びＳｈａｒｅＰｕｒｃｈａｓｅＳｗａｐＲｅｑｕｅｓｔメソッドを使用して発行市場においてファンド株式を購入又は売却することができる。オープンエンド型のファンド、つまり株式数が基礎となる資産の市場需要に基づいて変わり得るファンドでは、リクエストをサポートするために、株式が発行される（購入）、又は買い戻される（償還）。ファンドの運用モデルに基づいて、株式は、資産又は資産の相当金額（ＣＩＬ：ｃａｓｈ－ｉｎ－ｌｉｅｕ）と引き換えに購入側パーティに渡される。ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔは、ＣＩＬ取引である。このタイプの取引では、株式はファンドの権利行使価格、つまりファンドのＮＡＶを株式の総数で割った価格で売却される。ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔが行われ、ＮＡＶが割り振られ、購入者は、注文を遂行するために必要な「キャッシュ」資産を供給することによって、遂行しなければならない。ＩＡｓｓｅｔＦｕｎｄトークンは、キャッシュを受け取り、資産マーケットプレイスからの、又はＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔファンクションを使用して、基礎となるものを購入又は割り振らなければならない。ＳｈａｒｅＰｕｒｃｈａｓｅＳｗａｐＲｅｑｕｅｓｔは、株式購入に使用される資産がファンドの投資テーゼ又はインデックス（ファンドの基礎となる資産に対する株式の割合）と一貫性のある、取引で使用される。

発行市場償還の処理（８）：この取引は、発行市場購入取引とは反対である。代替性トークンの株式は、キャッシュ（ＳｈａｒｅＲｅｄｅｅｍＲｅｑｕｅｓｔ）又は基礎となるファンドからの資産（ＳｈａｒｅＲｅｄｅｅｍＳｗａｐＲｅｑｕｅｓｔ）と引き換えにファンドに売却される。資本準備金におけるキャッシュに応じて、ＣｒｅａｔｅＳｅｌｌＲｅｑｕｅｓｔを使用してＩＡｓｓｅｔＦｕｎｄトークンから資産を清算する必要がある場合がある。

一実装形態は、弾力的な証券化を可能にするために、代替性トークンの一部として流動性リザーバの確立を含む。流動性リザーバは、資本からファンドへの純流入又は流出に基づいて、発行市場取引（又は、別個の実装形態では流通市場限度注文）を価格決定するスマート・コントラクトである。リザーバは、株式のプール及び注文を遂行することができるキャッシュを維持する。価格は、ファンド・マネージャによってセットされた通りの所望の残高からの準備金プール残高の偏差に基づいてＮＡＶ付近で調節される。例えば、ＳｈａｒｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔの不均衡による資本の著しい流入は、リザーバ内のキャッシュ・プールを増加させるが、利用可能な株式プールは減少させる。価格決定アルゴリズム（ファンド・マネージャ戦略に基づくスマート・コントラクトのプラグイン）は、準備金プール内の株価を上昇させ、償還の見込みを増大させるが、新規購入の需要は低下させる。アルゴリズムは、リザーバを残高に戻す投資家需要の変化に直面すると流動性の価格を調節するように反応する。

資産購入の処理（９）：一部のポートフォリオでは、ポートフォリオのマネージャは、資本準備金からのキャッシュを使用して資産を購入する。これらの購入はＩＡｓｓｅｔ ＣｒｅａｔｅＰｕｒｃｈａｓｅＲｅｑｕｅｓｔを使用する。例えば、満了する資産は、資産収入によって補充される資本準備金からのキャッシュで置き換えることが可能である。ＮＡＶ評価及びヘッジ戦略は、これらの決定が全体的なポートフォリオ・アルファに反映されるため、ポートフォリオ・マネージャの、主要な責任である。

資産清算の処理（１０）：準備金残高が清算しきい値を下回ると、アクションがトリガされ、資産を売却してポートフォリオの流動性要件を回復するようポートフォリオ・マネージャに要求する。これらのトリガは、スマート・コントラクトを介して定められる場合があり、ＩＡｓｓｅｔ ＣｒｅａｔｅＳｅｌｌＲｅｑｕｅｓｔを通じて実行される。

スワップ処理（１１）：他のポートフォリオでは、資産はスワップ、つまり収入を得る株式と資産の収益力に対する権利との交換を介してポートフォリオに参加している。いくつかのポートフォリオは、資産を獲得するために両方の技法を使用してもよい。スワップの使用はポートフォリオにさらなる流動性をもたらすため、キャッシュ購入の代わりに、スワップの使用が好まれる。

リザーバ補充処理（１３）：収入を生み出す資産のファンドに適用される弾力的な証券化モデルでは、株主の持続的な撤退に基づいてリザーバのキャッシュ・レベルが低い場合、キャッシュ配分を使用して、リザーバにおける流動性を回復することができる。このステップにおいて、回復するリザーバ流動性の量は、アルゴリズム的に、リザーバ残高、資本準備金及び市場状況の関数で決定される。著しい流動性の回復が必要とされる場合、満了資産を補充するためのリソースが利用不可能になる場合があり、ポートフォリオの額面価格の減少につながる。収入レベルが清算しきい値を下回ると、これは以下で説明するような資産清算ステップをトリガする。

弾力的なポートフォリオ成長処理（１４）：持続的な購入注文の不均衡による、ＮＡＶを上回る持続的な価格は、リザーバにおけるキャッシュの不均衡を作り出す。この価格がＮＡＶをしきい値で超えると、資産は資本準備金に移転されて、ファンドにさらなる資産を購入してファンドの全体的なＮＡＶの成長を推進してもよい。このモデルを使用して、ファンドのＮＡＶは、認可された関係者の使用又は新規株式の発行しに、弾力的に成長することができる。

弾力的なポートフォリオ低減処理（１５）：投資家の流動性ニーズは、キャッシュ・プールからの価値の純流出となる場合がある。ＮＡＶを下回る価格決定をもたらす持続する不均衡は、ファンドからの資産を清算して、キャッシュ・プールを回復させるために必要なキャッシュを提供する必要性をシグナリングする。ポートフォリオのアンダーパフォーマンスが持続することは、ファンド・マネージャの制御下での資産のパフォーマンスに基づき、ファンド・マネージャの影響をきれいに引き下げた管理下において制御された資産の清算を行うことになる。専門的にはクローズド型のファンドであるが、投資家需要及び資産パフォーマンスに基づく額面価格の弾力的な変動は、オープン型ファンドの望ましい特性を与える。

弾力的な証券化は、非流動性の資産を含むファンドのサイズをきれいに成長及び低減できるようにする処理である。処理は、非流動性資産の為替売買を容易にするためのファンド構造を提供するよう市場のニーズに対処し、ある為替に対する流動性資産売買と、基礎となるファンドにおける非流動性の資産との間に流動性バッファを与えてＳＥＣ Ｒｕｌｅ ２２ｅ－４に関する懸念に対処する。

リンクされたＩＡｓｓｅｔＦｕｎｄとＩＡｓｓｅｔ構造の柔軟性は、一般的且つ高度なファンド管理戦略を実行するメカニズムを提供する。構造により、一般的な資産管理ファンクションを自動化して、革新的なファンド管理戦略を投入しつつ、透明性並びに簡略化された監査及びレポーティングを提供することが可能となる。代替性トークンを非代替性のＩＡｓｓｅｔＦｕｎｄトークンにリンクすることは、ファンド株式の新しい有用性を実現する。株式は、収入（配当）又は成長のために保持されてもよい；支払いのために移転されてもよい；担保としてエスクローに保持されてもよい；認可された流通市場でＵＳＤ、ＢＴＣ、ＥＵＲ又は他の証券との交換を通じて現金化されてもよい；及び／又は代理投票を通じてファンド・ガバナンスに参加するために使用されてもよい。

開示される実装形態は、スワップ・メカニズムを介してファンド株式を使用してファンド資産を購入又は資産プールから償還できるようにする。このことは「バッキング」モデルを作成し、トークンの発行及び破壊を使用して、アセットが追加されること、又はファンドから除去されることを可能にしている。追加的に、実装形態は、流動性プールを含み、資本のファンドへの純流入及び流出を管理してもよい。流動性アルゴリズムを適用して、株価を設定して償還を管理するのを支援し、ファンドの株式用の流通市場の形成を容易にすることができる。このモデルは、繰返し可能であり、ほぼあらゆるファンド構造を満たすために使用することができる：貸与、債務証券、売掛金、定期金賠償、ファクタリング、貿易金融、保険、リースなど。

開示される実装形態によって自動化されるファンド構造の一実例として、クローズドエンド型のＬｅｎｄｉｎｇ Ｐｏｏｌファンドをファンドのスマート・コントラクトを活用して作成することができる。プールは、既存の資産、ウエアハウス・ローン、再担保契約、又は資本形成から繰り入れられる。最初、プールは貸与に必要な資本（フィアット又は暗号通貨）だけを含んでいる。ファンドのスマート・コントラクトのフォーマットを使用して、Ｐｏｏｌは、ＮＡＶ及びＰＡＲ価格（プール内のすべての資産のＮＡＶとＰＡＲ価格の合計）を公開して、サポート文書及び資産の一覧をリアルタイムに公表する。すべてのファンド取引は、不変な台帳に記録される。プールは、ポートフォリオ・マネージャ、資産マネージャ、及び任意選択で他のサービス（ヘッジ、資産保険など）を有し、ローンは、認可されたエージェント及び自動化された処理を通じて支出されたファンドによって始まる。始まりでは、ローンは、資産としてファンドに追加される。開示される実装形態を使用して、すべての資産（利用可能な貸与資本、売掛金、及び他の資産）は、認可されたパーティによってリアルタイムに閲覧することができる。

ローンは、ＩＡｓｓｅｔスマート・コントラクトを拡張するスマート・コントラクトとしてプールから始まる。このことは、証券化、ファンド運用、及び準拠した移転を容易にする。資産オブジェクトとして、それらはサポート文書、取引履歴、及びリアルタイムの資産ＮＡＶ＆ＰＡＲ価格を認可された閲覧者に公表する。ローン・トークンは、ＩＡｓｓｅｔ構造を活用してローン特性を公表し、独立的な分析及びバリュエーションを可能にする。ローン・トークンは、ＥＲＣ－２０、ＥＲＣ－７２１、又は移転を統制するために他のトークンにラップされてもよい。

ローン・トークンに組み込まれるのは、バリュエーション及び支払い処理ロジックである。支払いは、ローンに特有のアドレス（例えば、ＱＲコードで指定される実例）への単純な移転を介して行われる。支払いは、処理されて、売り上げは、ファンドであってもよい資産の所有者に転送される。ローンごとのＰＡＲ価格（ローン元本）及びＮＡＶ（キャッシュ・フローのリスク調節済ＮＰＶ）は、それぞれの支払いに伴いリアルタイムで更新される。ローンごとの取引履歴は、不変な台帳に記録され、認可されたユーザによる分析用に利用可能である。

プール支払い処理は、自動化され、透明である。ファンド内の個々のローン資産の返済からの売り上げは、さらなる処理のために、Ｒｉｓｋ Ｐｏｏｌに移転される。リスク・プール処理ロジックは、カスタマイズ可能なスマート・コントラクトを活用して償還、ローン償却、Ｐｏｏｌ資本補充、管理手数料、及び透明且つ検証可能なウォーターフォールにより配当＆クーポン支払いを自動化する。配当及びクーポン支払い、並びに他の配分は、スマート・コントラクトに具体化されるファンド・ロジックを使用して自動的にファンド所有者に移転される。

高度化された流動性及びリスク管理では、資産はポートフォリオから売却されてもよい（又は購入してポートフォリオに入れてもよい）。サポートされる資産取引は、ローン市場を介した購入／販売、償還及びファンド・トークンを使用したスワップを含む。他の取引は、回収及び償却を含む。配当支払いは、暗号通貨、フィアット、又は現物プール・トークンで行うことができる。トークンの発行は、発行市場の提供を通じて、オークション、又は既存利率のトークン化を通じて発生してもよい。株主（トークン保有者）は、クーポン＆配当配分を自動的に、株式所有権に比例して受け取る。結果は、配当支払いトークンである。資産に裏付けされるセキュリティ・トークンは、革命的な金融商品である。トークンは、（１）配当を受け取るために保持することができる；（２）支払いとして移転することができる；（３）担保契約としてエスクローに保持されてもよい；及び／又は（４）認可された流通市場におけるフィアット通貨、暗号通貨、又は他の証券との交換を通じて現金化することができる。

弾力的な証券化メカニズムを使用して、トークンの需要の増加は、資本の流入となる（ミューチュアル・ファンドの需要の増加に類似するモデルにおいて）。追加的な資本は、貸与プールＰＡＲ価格の拡大につながり、貸与向けにより多くの資産を提供する。このモデルは、無期限に、成長することができる。同様に、アンダーパフォーマンス又は他のファクタによって生じる資本の撤退は、ポートフォリオＮＡＶの制御されたドローダウンをもたらす。このモデルは、繰返し可能であり、ほぼあらゆる証券化ニーズを満たすために使用することができ、貸与、債務証券、売掛金、定期金賠償、ファクタリング、貿易金融、保険、リースなどを含む。

図１０は、トークン化された資産に関連するデータを管理するためのデータ記憶及び検索システムを構成するための方法１０００を図示している。１００２において、クラス定義に従って、デジタル・トークンが作成され、このトークンは一意なトークン識別子を含む。１００４において、デジタル・トークンは、資産と関連させて一意なレコードとして資産レジストリのメモリ・デバイスに登録される。１００６において、クラス定義に従って、通信インターフェースがデジタル・トークンに関連付けられる。通信インターフェースは、資産レジストリによって実装される通信仕様に準拠することができ、所定のファンクションのセットを公開するように構成される。所定のファンクションは、資産所有権移転ファンクション、資産バリュエーション公表ファンクション、資産属性決定ファンクション、及び資産特有処理ロジックを含むことができる。

１０１０において、暗号ウォレットをデジタル・トークンに関連付けることができる。ウォレットは、資産レジストリに記録されたトークンのファンクションを行うように構成される。デジタル・トークンが非代替性である場合、１０１２において代替性のデジタル・トークンを作成することが可能である。１０１４において、暗号ウォレットを代替性のデジタル・トークンに関連付けることができる。ウォレットは、トークンのファンクションを行うように構成される。１０１６において、非代替性デジタル・トークンを代替性デジタル・トークンでラップするために、非代替性デジタル・トークンの所有権は、代替性デジタル・トークンに移転することが可能であり、それによって、マルチパーティ配当配分、コーポレート・ガバナンス、及び株式売買などの共有所有権に関連付けられるファンクションを含む非代替性デジタル・トークンによって表現される資産の部分所有権が可能となる。

上述のトークンは、ＤＬＴネットワーク内で、及び複数のＤＬＴネットワーク又は他の移転ネットワークの間で、価値を移転するために使用することができる。図１１は、開示される実装形態による、変形取引を行うための異質なＤＬＴシステムをインターフェースする方法を図示している。１００２において、２つの異なるＤＬＴネットワークなど、少なくとも２つの異種ネットワークにまたがる、所望の／リクエストされるクロス台帳取引を説明する情報が受信される。１００４において、マルチネットワークのグラフ構造が読み取られる。グラフ構造は、ネットワークにまたがるブリッジに対応するノードをクロールすることによって作成することが可能である。グラフ構造の各ノードは、関連付けられた属性変数のセットをノード・メタデータとして有することができる。属性変数は、対応するネットワークにネイティブな価値の単位（トークン）、トークンを実装するスマート・コントラクトの識別情報、ブリッジに使用されるウォレット又は口座、ユーザに利用可能な価値ソース、並びにＡＰＩ及び他のネットワークへのネットワーク・インターフェースを含むことができる。１００６において、ノード巡回アルゴリズムに従ってグラフ構造を巡回して、所望の取引を容易にするブリッジ・ノードを検出することによって取引を成し遂げるために、取引ルーティング情報が生成される。１００８において、取引ルーティング情報を使用して選好に基づいてソースによって移転経路が選択され、移転が開始される。所望の移転経路は、リクエストされたクロス台帳取引の適正な実行を確実にする、サブ取引のチェーン化されたセットを含むことができる。１０１０において、クロス・ネットワーク取引を達成するために、指定されたインターフェースを使用してサブ取引が実行される。サブ取引は、異質なネットワーク上で、文法独立的な実行命令を基礎となる移転ネットワークによって認識される具体的な命令にコンバートするオントロジ・マッピングを使用して実行される。包括的な取引、及びすべてのサブ取引は、サブ取引に関与する台帳とは別個であってもよい台帳に記録することができる。独立的な台帳は、ゼロ知識証明を利用して不変性を実現しつつ取引プライバシーを維持することができる。サブ取引のチェーンは、ソース・ネットワーク、宛先ネットワーク、及びソース・ネットワークと宛先ネットワークとの間の接続として機能する他のネットワークにおける取引を含むことができることに留意されたい。

図１２は、図１１の方法及び他の変形移転を達成するための、開示される実装形態によるコンピュータ・アーキテクチャを概略的に図示している。アーキテクチャ２０００は、取引サービス・バス・モジュール２００２、チェーン化移転ハンドラ・モジュール２００４、計画サービス・モジュール２００６、ブリッジ・サービス・モジュール２００８、価格決定及び流動性モジュール２０１０、独立取引台帳モジュール２０１２、及びアウト・オブ・バンド移転／補充モジュール２０１４から成る。アーキテクチャ２０００の各モジュールは、必要であればネットワーク化されたコンピューティング環境を通じて他と通信することができる。

本明細書において説明されるモジュールは、単一のコンピュータ処理装置又は複数のコンピュータ処理装置内でコンピュータ実行可能コードとして実装することができる。モジュールのうちの１つ又は複数は、分散アーキテクチャとして他のモジュールから遠隔に実装されてもよい。別のモジュールによって提供される機能性の以下の説明は、説明を目的としたものであり、限定的であることを意図されていないが、モジュールのいずれも説明されるものより多い機能性、又は少ない機能性を提供してもよいからである。例えば、モジュールのうちの１つ又は複数は、取り除いてもよく、その機能性の一部又はすべては、モジュールのうちの他のものによって提供されてもよい。

上述のように、ネットワーク間（クロス台帳）取引などの変形取引の自動化された実行は、価値の移転など、提示されるクロス台帳取引の詳細を指定する取引データ構造を受信したことに応じて、達成される。データ構造は、取引詳細を含むことができ（例えば、ソース、宛先、金額、通貨）、移転を開始する権限を持つパーティにより作成することができる。例えば、取引データ構造は、（ＴｒａｎｓａｃｔｉｏｎＴｙｐｅ＝Ｔｒａｎｓｆｅｒ，ＴｒａｎｓａｃｔｉｏｎＣｕｒｒｅｎｃｙ＝Ｅｔｈｅｒ，Ｓｏｕｒｃｅ＝［ｗａｌｌｅｔ １ ａｄｄｒｅｓｓ］，Ｄｅｓｔｉｎａｔｉｏｎ＝［ｗａｌｌｅｔ ２ ａｄｄｒｅｓｓ］）であってもよい。

取引サービス・バス・モジュール２００２は、取引データ構造を解析して、グラフに基づいて、指定された取引を実行するために複数のネットワークを巡回するための１つ又は複数の存在可能な経路（予想される価格、手数料、及び取引回数を含む）を決定する。経路決定は、ルート計画サービス・モジュール２００６によって決定されたネットワークのモデルに基づいて行われ（以下で詳細に説明されるやり方で）、複数のサブ取引から構成される取引チェーンを含み、各サブ取引はソース及び宛先を有する。経路上で資産変形が必要とされる場合、価格決定及び流動性モジュール２０１０は、ブリッジ・メタデータに基づいてブリッジ巡回に必要とされるソース資産と宛先資産との比率を指定する（以下で説明する）。チェーン化移転ハンドラ・モジュール２００４は、ネットワーク移転、確認、及びブリッジ巡回（以下で説明されるブリッジ・サービス・モジュール２００８によって指定される通り）のシーケンスとしてサブ取引（プライバシーを保護するよう所望される場合、ゼロ知識証明を用いて）を実行し、最終的に指定された変形取引の価値移転に作用する。アウト・オブ・バンド移転モジュール２０１４を使用して、非ネットワーク（手作業の、又は非金融商品の）移転を含むことができる。アウト・オブ・バンド移転モジュール２０１４を使用して、必要であれば、サブ取引における流動性の消費に基づいて口座リソースをリバランスすることができる。取引記録は、独立取引台帳モジュール２０１２によって記録することができる。開示される実装形態は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号に記載されるコンプライアンス・フレームワークを活用して、クロス台帳取引をセーフガードし、異種ネットワーク上でコンプライアンス検証を行うことができる。

上述のネットワークのモデルは、ソースと宛先との間で価値の移転のために存在可能な経路を識別するよう、様々なネットワーク（クロス台帳取引に参加することを期待され得る）及びブリッジ・ノードをクロールするマルチエージェント・システムを利用してルート計画サービス・モジュール２００６によって作成される。ネットワーク間トポロジは、ノードのグラフ構造として記憶することができる。ノード属性変数は、以下でさらに詳細に説明するが、特定のネットワークにネイティブな価値単位（トークン）の説明、巡回方法、ブリッジに使用される口座、手数料及び価格決定方法、並びに関連ＡＰＩ及び外部ソースとの通信を目的としたネットワーク・インターフェースを含むことができる。

図１３Ａは、実装形態による、ルート計画サービス・モジュール２００６によって巡回される、ネットワーク間トポロジの単純なグラフ構造３０００の抽象化の概略図である。例えば、ネットワーク３００２はビットコインのブロックチェーンであり得、ネットワーク３００４はイーサリアム・プロトコルのブロックチェーンであり得、及びネットワーク３００６はステラ・プロトコルのブロックチェーンであり得る。図１３Ａには、３つの異種ネットワーク（３００２、３００４、及び３００６）が図示されているが、実装形態には、あらゆる数の、又はあらゆるタイプの異種ネットワークを含むことができる。図１３Ａでは、各ネットワークが図示されるブリッジ・ノードを有し、各ノードはネットワーク同士の通信を提供するブリッジの一面を表現している。ノードＢは、ＤＬＴネットワーク３００２内のブリッジ・ノードであり、ノードＭは、ＤＬＴネットワーク３００６内のブリッジ・ノードであり、ノードＹは、ＤＬＴネットワーク３００４内のブリッジ・ノードである。各ブリッジ・ノードは、対応するＤＬＴネットワーク内の口座／ウォレットに対応する。ブリッジ・ノードのペア・ブリッジ。例えば、ノードＢ及びノードＭは、ＤＬＴネットワーク３００２とＤＬＴネットワーク３００６との間のブリッジを定義する。各ブリッジ・ノードは、上述の属性変数のセットを示す対応するメタデータ・レコードを有する。さらには、ブリッジ特性データは、ブリッジ・メタデータとして記憶される。図１３Ａ中、線で結ばれるブリッジ・ノードの各ペア、及び関連するメタデータ（ノード・メタデータ及びブリッジ特性メタデータ）が、ブリッジを定義する。もちろん、グラフ内にはあらゆる数のノード及びブリッジ・ノードがあってもよく（通常、数千）、図１３Ａは例示目的のため単純なグラフである。

実例として、メタデータ・レコード３０１０は、ノードＢに関連して記憶され、メタデータ・レコード３０１２は、ノードＭに関連して記憶され、ブリッジ特性メタデータ・レコード３０１４はノードＢとノードＭとの接続を定義するよう記憶される。したがって、ブリッジは、グラフ構造３０００のメタデータ・レコード３０１０、３０１２、及び３０１４（まとめて「ブリッジ・メタデータ」）によって定義される。ブリッジ・メタデータのさらに詳細なスキーマ３１００を、実装形態に従って、図１３Ｂに示す。スキーマ３１００は、ウォレット属性３１０２（ノード・メタデータとしてグラフに記憶することができる）、トークン属性３１０４（ノード・メタデータとしてグラフに記憶することができる）、データ型属性３１０６（ブリッジ特性メタデータとしてグラフに記憶することができる）、及びインターフェース３１０８（価格決定モデル及び他のロジックを含み、ブリッジ特性メタデータとしてグラフに記憶することができる）を含む。図１３Ａのメタデータ・レコード３０１０、３０１２、及び３０１４は、３つの別個のレコードとして図示されているが、その中のデータは単一のブリッジ・メタデータのレコードに組み合わされてもよく、又はグラフ３０００のアーキテクチャに基づいて追加的なレコードに分けられてもよい。開示される実装形態は、メタデータを指定するために標準的なスキーマを使用する。ブリッジは、異種ネットワーク間の接続経路として機能する。グラフは、取引経路が、クロス台帳取引チェーンにおいて（又は、特定の場合では、以下で議論するように台帳内取引において）ブリッジを配置して使用できるようにする。メタデータ・レコード３０１０、３０１２、及び３０１４は、ブリッジ・ファンクションと関連して以下でさらに詳細に議論する。

グラフ３０００のデータは、ブリッジ・サービス・モジュール２００８によって記憶され、ルート計画サービス・モジュール２００６によって巡回される。取引サービス・バス・モジュール２００２は、変形取引を成し遂げるために必要とされるサブ取引を含む、最適化された取引ルーティング情報を提供する。ルートを提示されると、ソース口座は、グラフ、並びに取引回数、コンバージョン・レート、及び手数料ロードのうちの１つ又は複数などのユーザ選好に基づいて、チェーン化された取引を開始することができる。チェーン化移転ハンドラ・モジュール２００４は、提案されたサブ取引を含む取引実行を管理して、最終的なデリバリーを通じて適正な移転の実行（又はロールバック）を確実にする。ルート計画及び経路最適化を、以下でより詳細に説明する。

取引サービス・バス・モジュール２００２は、価値移転の文法独立的なモデル、移転メッセージング規約と関連項目のカタログ、及び様々なネットワークの異質な実装形態を文法独立的なモデルにコンバートするための変換スキーマとして機能する、金融オントロジを実装する。チェーン化移転ハンドラ・モジュール２００４は、提示されたサブ取引を文法独立的な命令からネットワーク特有実装形態に変換する取引サービス・バス・モジュール２００２を介して異質なネットワーク上でサブ取引を実行する。

金融オントロジは、金融取引に共通の言語を提供する抽象レイヤである。オントロジは、金融システムで遭遇する、サービス、ファンクション、及びオブジェクト向けのインターフェースを定義する。オントロジは、個々のサービス・プロバイダの実装形態同士の様々な違いを分離する相互運用性レイヤを提供し、個々のコンポーネントが緩く連結される柔軟なモジュール型システムを用意する。オントロジにより、個々の金融サービスが共に機能するように設計されていなくても、個々のサービスをより複雑な金融システムにコンポーズすることが可能となる。支払いのチェーン化は、あらゆる移転ネットワークをあらゆる他の移転ネットワークに接続するように設計されているため、共通のサービス定義は、相互接続しているＮシステムの複雑性をＮ階乗（Ｎ！）からＮに減ずる。したがって、オントロジは、大きな集積物を扱いやすくするように設計される。本技術の標準的なファンクション及びインターフェースを、以下で議論する。

しかしながら、扱いやすさのために基礎となるプロバイダごとに共通の抽象化を開発することは、個々のプロバイダの表現度（つまり、一意のプロバイダによって公開され得る特殊な特徴）を低減させる可能性がある。開示されるフレームワークは、表現度が扱いやすさのために失われないことを保証する２つのメカニズムを有する。まず、「ラッパー」は、具体的なプロバイダ／ネットワークに一意な、又はプロバイダ／ネットワークのサブクラスに一意な特徴を公開することができる。この場合、依存的なクライアントは、実装形態に特有なラッパーで直接的にインターフェースして、これらの一意な特徴を活用してもよい。しかしながら、このことは、クライアントとサービス実装形態との間に直接的な依存性を作り、この依存性はクライアントをサービス実装形態に密に連結してモジュール性及びスケーラビリティを限定する。実装者は、一意な機能性を得るためのトレードオフが、具体的なプロバイダ／ネットワークへの依存度を高める価値があるかどうかを判断することができる。追加的に、オントロジは、ローカルで定義された仕様の追加的なデータを汎用インターフェースで搬送できるようにするデータ構造を含む。中心部のデータ構造は、パーサーがデータを検査し、フォーマットが認識された場合はそれを解析できるようにする、型及びデータ情報を含む仕様を有するＯｔｈｅｒＤａｔａフィールドを含む。この構造は、システムのすべての部分で使用される構造において追加的なデータを搬送できるよう要求される場合がある、システム同士のポイント・ツー・ポイントの通信を可能にする。結果として、チェーン化移転ハンドラに見られるようなファンクションを協調させることは、具体的な移転プロバイダの一意な特徴を犠牲にすることなく、ファンクションをグローバル範囲で実施することができる。

上述のように、ブリッジ・サーバ・モジュール２００８は、論理インターフェースであるブリッジを様々なＤＬＴネットワーク間に設け、それらの間で取引と価値を中継する。ブリッジは、異種の資産及び価値の単位を表現するトークンのタイプを受け入れることができる。ブリッジ・サーバ・モジュール２００８は、ブリッジを実装して、モデル及びノード・メタデータに基づいて論理的なクロス台帳接続を作成する。本質的に、ブリッジは、移転挙動を定義するデータ構造である。ブリッジ・サーバ・モジュール２００８は、メタデータ・レコード３０１０、３０１２、及び３０１４を読み取り（図１３Ａ）、ブリッジ型を判定し、Ｖｏｓｔｒｏウォレットを割り振り、Ｎｏｓｔｒｏウォレットを割り振り、手数料を識別し、価格決定モデルを決定し、必要であればｏｕｔ－ｏｆ－ｂａｎｄ補充を割り振り、以下で説明するやり方で、変形ロジックを識別して付加する。ブリッジ・オペレータ、つまりブリッジでまたがっているネットワーク両方を介して動作する適当なパーミッションを有するエンティティ又はシステム処理は、メタデータ・レコード３０１４で示されることが可能である。ブリッジ口座は、ソース・ネットワークと宛先ネットワークとをリンクするよう作成されるか、又は割り振られる。ブリッジ内のソース口座は保管口座であることが多く、２ｗａｙのブリッジ・サポート用にアクティブであるべきであり、また宛先はアクティブであるべきであり、特定のタイプの移転用にリンクされた発行者を必要とする場合がある。

ブリッジ・サービス・モジュール２００８によって、価格発見（ペッグ、フロート、為替）、会計（変換、証書）及び移転（イン・バンド、アウト・オブ・バンド）において、ある範囲のオプションを伴って、様々なクラスのブリッジを作成して記憶することができる。これらのクラスは、共通の相互接続パターンを提供して、ネットワーク間での価値の移動を実行及び記録するための、繰返し可能な処理を容易にする。含まれるブリッジ・クラスは、メタデータ・モデルによって指定される通りに、価格発見、会計及び移転などの分野のオプションからコンポーズされる（例えば、イン・バンドとアウト・オブ・バンドの組み合わせ）。異種ネットワークは、ブリッジを使用して一緒に接続されるため、ブリッジは、ネットワーク間での価値のフローを容易にしており、メタデータによって指定されるように、サービスのための料金を抽出することができる。ブリッジは、ネットワーク間又は価値の単位間に接続を作成し、これは以下を制御することによって異なる送信ネットワーク全体で価値移転を受け取って中継する：
・送信モード：担保契約（参照による）、決済（価値による）、リンケージ、又は売買－変形（資産の変更、分割）
・価格決定：為替、アルゴリズム的、ペッギング
・シンクロニシティ：同期又は非同期（ヘッジ＆リスク管理を伴う）
・手数料、資本供給ロジスティックス、及び流動性管理

各ブリッジは、インバウンド口座及びアウトバウンド口座を含む（例えば、図１３ＡのノードＢ及びノードＭに、それぞれ関連付けられる）。口座は、取引チェーンの一部として運用される「システム」パーミッションを有するブリッジ・オペレータによって所有される可能性がある。これらの口座は、ブリッジの作成の間に、ブリッジ・メタデータ中の設定パラメータとして提供される。インバウンド口座及びアウトバウンド口座によってサポートされる価値単位は、ブリッジによってサポートされる接続を定義する。サポートされる接続は、移転ルーティングに必要である。取引がビットコイン台帳（ＤＬＴネットワーク３００２）から始まり、ステラ・ネットワーク（ＤＬＴネットワーク３００６）にクロスする図１３Ａの実例を使用して、ブリッジのインバウンド（Ｖｏｓｔｒｏ）口座（例えば、図１３ＡのＢ）は、取引チェーンにおける最初のサブ支払いの宛先口座となる。この口座は、「Ａｃｔｉｖｅ」な口座、つまり「ロールバック」機能が必要とされない限り、動作するのに権限を含む口座である必要はない。ブリッジのアウトバウンド（Ｎｏｓｔｒｏ）口座（例えば、図１３ＡのＭ）は、価値をチェーン又は最終宛先に送るために使用される。Ｎｏｓｔｒｏ口座は、Ａｃｔｉｖｅであるべきで、このことは処理スレッドが口座から取引を開始する権限を有するべきであることを意味している。ダーク・プール取引、つまり事前位置付けされた価値での取引では、チェーン化取引を開始することに先立って、インバウンドのブリッジ口座に十分な価値が存在しなければならない。ブリッジは、ブリッジ・サーバ・モジュール２００８から、ルート計画及び支払い実行のためにチェーン化移転ハンドラ・モジュールによって使用されるリストにロードすることができる。ブリッジを実行するために使用されるクラスは、設定によって決定される。

所望の宛先価値単位の場合、１つのウォレット型から別のウォレットへの可能なルートのリストは、利用可能なブリッジによって使用されるインバウンド及びアウトバウンドのウォレットについて、ブリッジ・メタデータで示される、サポートされるトークンを評価することによって決定することができる。ルート計画サービス・モジュール２００６は、ソースから宛先への経路をマッピングする際、このリストを使用する。例えば、図１３Ａのグラフ３０００は、ＤＬＴネットワーク３００２とＤＬＴネットワーク３００６との間の２つの可能なルートを示している。第１のルートは２で示され、第２のルートは１と３との組み合わせで示されている。

ブリッジ設定の詳細に加え、ブリッジ・クラスの動作可能な属性は、依存性投入の詳細により決定され、ブリッジ・メタデータとして記憶することができる。開示される実装形態におけるブリッジ動作のバリエーションは、メタデータで定義される６つの属性に分けることができる：送信モデル、価格決定モデル、補充モデル、シーケンス、方向、及び手数料。送信モデルは、ブリッジ・ウォレットを介して、どのように台帳を一緒にリンクするかを定義している。５つのタイプの送信モデルを実装することができる：担保契約（Ｄｅｐｏｓｉｔ）、決済（Ｗｉｔｈｄｒａｗａｌ）、及び移転（ＮｏｓｔｒｏＶｏｓｔｒｏ）、Ｔｒａｎｓｍｕｔｅ（台帳変化）、及び変形。使用されるモデルは、所望の移転モード、発行／買戻し動作を実施するブリッジ・オペレータの能力、保管ウォレットの利用可能性、及び他のビジネス要件に基づいて決定することができる。

価格決定モデルは、ブリッジによって受け取られるソース・トークンごとに送られる宛先台帳トークンの数の比率を定義している。価格決定モデル実装形態は、Ｌｉｎｋ（１：１）、Ｐｅｇ（固定比率）、Ａｌｇｏｒｉｔｈｍｉｃ（依存性投入のプラグイン）、又はＥｘｔｅｒｎａｌ（取引所などのサード・パーティのソースから得る）を含む。補充モデルは、過剰な不均衡フローが起こりリソースを再配置しなければならなくなった時に、アウトバウンドのウォレットを再補給するために使用されるメカニズムを定義する。補充モデルの実装形態は、次を含む：Ｎｏｎｅ、Ｍａｎｕａｌ、Ｔｒａｎｓｆｅｒ、及びＥｘｃｈａｎｇｅ。ブリッジは、シーケンス（Ｓｅｒｉｅｓ／Ｐａｒａｌｌｅｌ）及び方向（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ／Ｂｉｄｉｒｅｃｔｉｏｎａｌ）を有し、それらがどのように実行することができるかを示している。

マルチ台帳の発行の場合では、ブリッジは、クロス台帳変異を実装することができる。これは、所有権の公的な記録が移転用に使用されている１つの台帳ではなく別個の台帳にある場合、又は公的な記録が影響を受ける台帳の所有権の記録の合計である場合に使用することができる。変異により、トークンが複数の台帳上で発行できるようになる、及び／又は１つの台帳上で発行されたトークンが別の台帳に「フロー」することができる手段を提供する。トークンが台帳から台帳へ移動すると、流通におけるトークンの総数は一定なままであるが、所有権の記録は台帳から台帳へと移動する。

例えば、台帳から出て行くファンドは、ソース台帳ベース・ウォレットに送られる。この移転はまた、トークンを移動させずにトークンを保留するエスクロー取引であってもよい。等価な数のトークンが、発行者（ウォレット、口座、又はスマート・コントラクト）から宛先台帳上の流通に、又はＣｏｌｄウォレットからプロバイダＢ上のアウトバウンド・ウォレットに、宛先へのデリバリー用に発行される。デリバリーに成功すると、ソース台帳で呼び出された流通からトークンを除去するＩＩｓｓｕｅｒ．Ｄｅｓｔｒｏｙファンクション。

クロス台帳変異を達成するためのサブ取引のチェーンの実例、つまり別の破壊に対応する１つの価値の単位の作成を、図１４のフローチャートに図示する。変異取引の実例は、有益な所有権を表現する株式の、１つの台帳から別の台帳への移動である。４００２において、プロバイダＡを使用して価値がソース・ウォレットからベース（エスクロー）ウォレットに送られる。このウォレットは、ブリッジ・インバウンド・ウォレットである。４００４において、トークンは、プロバイダＢ発行者ウォレットから発行され、プロバイダＢのベース・ウォレットに送られる（ブリッジ属性に基づくブリッジ・アウトバウンド・ウォレット）。４００６において、プロバイダＢのベース・ウォレットは価値をプロバイダＢの宛先ウォレットに送る。４００８において、取引が完了すると、プロバイダＡのベース・ウォレットから等価な数のトークンが破壊される。この処理は、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳及び宛先台帳上の取引を検出して属性付けるメカニズム、並びにプロバイダＢ上でトークンを作成して、プロバイダＡ上のベース・ウォレットからトークンをバーン（破壊）するメカニズムを有していると仮定していることに留意されたい。これらの権限へのアクセスは、ブリッジ・メタデータによって示すことができる。また、発行者ウォレットを通じて直接トークンを発行してバーンすることによって、ステップ４００４から４００８をスキップすることが可能である。

場合によっては、トークンに表現される権利をある形式から別の形式にコンバートすることが望ましい場合がある。例えば、コンバーチブル・ノートで表現されるローン権利をエクイティ・ポジションにコンバートすることが望ましい場合がある。この場合、前の変異ファンクションを使用して、固定比率変形（例えば、１株負債＝１株出資、又は１０株負債＝１株出資）を使用することができる。しかしながら、共通の株式における権利を、様々に作用する別個のトークンに分割することが有用な場合があり、一方は投票権利を表現し、他方は収入又はエクイティ売り上げの有益な所有権を表現する。この場合、カスタムの取引変形ブリッジが要求される。インバウンドのウォレットに運ばれるトークンのそれぞれのタイプに対して、２つ以上のタイプの株式が生成され、宛先に運ばれてもよい。Ｔｒａｎｓｆｏｒｍ取引の基本的なシーケンスは、Ｔｒａｎｓｍｕｔｅ取引と同じであるが、ブリッジは、アウトバウンド取引に対して２つ以上のタイプの金融商品を発行するための命令を実行しなければならず、各金融商品を所望の宛先ウォレットに運ばなければならない。反対取引は、権利を新しい複合権利に組み合わせるために行われてもよい（例えば、投票と有益な所有権とを共通株式に組み合わせる）。変形ブリッジは、台帳内ブリッジであることができる。つまり、複数のネットワークにまたがっている必要がない。

交換ブリッジは、Ｐｒｉｃｅ Ｄｉｓｃｏｖｅｒｙ又はファンドのＭｏｖｅｍｅｎｔが、インライン又はアウト・オブ・バンド（ＯＯＢ：Ｏｕｔ Ｏｆ Ｂａｎｄ）で交換を伴う特殊な種類のブリッジである。この場合、ソース取引に要求されるファンド額は、ある交換に対する等価な売買の現在のＴｏｔａｌ Ｖｏｌｕｍｅ Ｐｒｉｃｅ（オーダー・ブックの全体）に依存する。次いで、ファンドは、バッチでインライン補充又はアウト・オブ・バンド補充される。場合によっては、インバウンド移転は、インライン取引用の取引所口座向けであってもよい。この場合、Ｎｏｓｔｒｏ口座は、やはり取引所にある。Ｎｏｓｔｒｏ口座は、取引所がプロバイダ・ネットワークを介して利用可能ではないが異なる通貨がサポートされている場合、Ｖｏｓｔｒｏ口座と同一のプロバイダを使用してもよい。図２０及び図２１に関して、他のタイプのブリッジを以下で議論する。

開示される実装形態は、「ＩｎｆｉｎＸｃｈａｎｇｅ（商標）」としても知られる、インターフェースとＤＬＴのデータ構造取引サービス・バスとをマッピングしてサービングするライブラリを含むインターフェース・アーキテクチャ、取引サービス・バス・モジュール２００２、及び従来的な価値移転ネットワーク（例えば、イーサリアム、ＰａｙＰａｌ、ＳＷＩＦＴ）、及び価値移転モデルを含む。上述のように、ブリッジによって要求されるインターフェースは、ブリッジ・メタデータにおいて特定される可能性がある。これらのインターフェースは、変換取引に使用される手順を実行するために必要なファンクションを公開する。ＩｎｆｉｎＸｃｈａｎｇｅラッパーは、統合のためにハブ・アンド・スポーク・モデルを実装し、それを通じて、チェーン化移転ハンドラ・モジュール２００４などの依存的なサービスは、ラップされた移転ネットワーク全体で取引を編成するために必要なインターフェースを一度だけ統合する必要がある。

取引サービス・バス・モジュール２００２は、台帳内取引用の共通インターフェースを提供する抽象レイヤとして実装することができる。ソース台帳又は宛先台帳のいずれかとしてクロス台帳取引に参加するために、取引プロバイダを、ＩｎｆｉｎＸｃｈａｎｇｅラッパー内にラップすることができる。ラッパーは、取引を実行してネットワークのアクティビティに反応するために、基礎となる移転プロバイダと一体化する実行ファイルである。ラッパーは、金融オントロジで定義された通りに共通インターフェースを公開する。これらのインターフェースは、ビジネスと取引プロバイダの具体的な実装形態の詳細からのチェーン化に関連付けられる取引ロジックとを切り離し、取引パターンの広範な再使用を可能にする。

取引プロバイダ／ネットワークは、実装形態及び統合パターンが広範に変化する。例えば、ブロックチェーン・ネットワークは、ノードと対話するクライアントを必要とする一方で、多くの支払いネットワークはＡＰＩを公開する。ＡＰＩは、ＲＥＳＴ、ＳＯＡＰ、ＲＰＣ、及び他のパターンを使用して実装される。企業会計システムは、統合に特定のパターンを持たないリレーショナル・データベースで実行されることが多い。取引サービス・バス・モジュールのライブラリは、基礎となるサービスと対話するために共通パターンを提供するために、これらのスタイルのうちいずれかで実装される取引プロバイダと統合するよう開発することができる。

各プロバイダに接続する取引サービス・バス・モジュールのライブラリが、抽象ファクトリ・パターンを使用してチェーン化移転ハンドラ・モジュール２００４に投入されてもよい。抽象ファクトリ・パターンは、共通のテーマを持つ個々のファクトリのグループを、その具象クラスを指定することなくカプセル化するための既知のメカニズムである。例えば、クライアント・ソフトウェアは、抽象ファクトリの具象的な実装形態を作成し、次いでファクトリの一般的なインターフェースを使用してテーマの一部である具象オブジェクトを作成することができる。ファクトリ・パターンは、オブジェクトのセットの実装形態の詳細を、その一般的な使われ方から別個にする。

やはり、接続を定義するインターフェースは金融オントロジにある。プロバイダは初期化されると、サービス・インターフェース用のそのサポート及び呼び出しサービスへのファンクションを公表する。このことは、呼び出しサービスがサービス及び取引プロバイダによってサポートされるメソッドを識別できるようにする。この情報を使用して、呼び出しサービスは、取引タイプをサポートするプロバイダの資格を判断することができる。チェーン化された取引に参加しているあらゆるプロバイダは、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ抽象化をサポートすべきである。Ｆｉｎａｎｃｅ Ｏｎｔｏｌｏｇｙから頻繁に使用されるサービスの短いリストを、以下で説明する。
・ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ：すべての価値の移転を実行する。ファンクションには以下が含まれる：取引にかかるコストを推定すること、支払いを実行すること、その完了を検証すること、及びソースから支払いのリストを取得すること
・ＩＷａｌｌｅｔＲｅａｄｅｒＳｅｒｖｉｃｅ：口座残高（特定のウォレット・アドレスにおける利用可能な価値の額）を識別し、ウォレットについての詳細を取得するために使用される（例えば、サポート通貨、作成日）
・ＩＷａｌｌｅｔＶａｌｉｄａｔｏｒＳｅｒｖｉｃｅ：所有権を主張するエンティティによる所有権を含め、ウォレットが取引に対して資格があるかどうかを判定する。
ＩＰａｙｍｅｎｔサービス及びＩＩｓｓｕｅｒサービスは、あらゆる支払いシステムの上のレイヤとなり、そのプロバイダを介する移転を実行することができる。すぐ下に見られるのは、インターフェース用の例示的な疑似コード及び関連データ構造である。

複雑なクロス台帳移転に対する取引サービス・バス・モジュール２００２の用途を理解するためには、まず、単純な支払いシステムが取引サービス・バス・モジュール２００２のコンテキストにおいて、どのような働きをするかを探ることが助けとなる。図１５は、単純な移転の実例５０００を概略的に図示している。ＵｓｅｒＸ（送る側）が、同一台帳上で、ＵｓｅｒＹ（受け取り側）に価値を送りたがっている（例えば、ＰａｙＰａｌ移転）。まず、送る側は、ファンクション（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｐｒｅｐａｒｅ）受け取り側（アドレスによって）、及び送られる通貨／金額（通常、受け取り側が受け取ると期待される金額で表される）を指定することによって移転を提案する。システムは、提案された支払いの妥当性をチェックし（手数料／ガス代、ポリシー、受け取り側は有効か、ファンドは十分か、を評価する）、所望のデリバリーを実現するために送らなければならない金額に関する１つ又は複数の選択肢によって応答する（多くのシステムでは、利用可能な選択肢は１つだけである）。ある選択肢について移転約定が受け入れ可能であれば、送り側は、署名された取引（ログイン、シークレット、など）の移転を開始する（ステップ１、ＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。システムは、移転を有効化し（ステップ２、イベントＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）、口座残高を調節する（ソース残高を減少させ、宛先残高を増加させる）ことによって価値を移動しつつ、移転手数料を抽出する（ステップ３）。取引が完了すると、通知が送られる（イベントＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）。新しい残高が、ソース・ウォレットと宛先ウォレットに反映される。

開示される実装形態によるチェーン化された取引は、これらの同じファンクションを使用して、開示される実装形態の新規な要素と組み合わせて開始されてもよい。図１６は、開示される実装形態によるチェーン化された取引の実例６０００（指定された順に達成される複数のサブ取引を含む）を概略的に図示している。図１６での実例は、図１２のアーキテクチャ２０００を使用して取引を達成することができる。チェーン内の個々の台帳移転は、図１２のチェーン化移転ハンドラ・モジュール２００４によって管理されるアクティビティを協調することを伴う単純な支払いと一貫性のある方法を使用する。

図１６に示されるように、送り側は、ＩｎｆｉｎＸｃｈａｎｇｅインターフェースを使用して移転を提案する（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｐｒｅｐａｒｅ）。この実例では、ユーザＸは、価値をプロバイダＡの口座（例えば、第１のＤＬＴネットワーク）から、プロバイダＢにあるユーザＹの口座（例えば、第２のＤＬＴネットワーク）に移転したいと思っている。ステップ１において、ルート計画サービス・モジュール２００６図１２は、ノード・グラフ（図１３Ａのノード・グラフ３０００など）を巡回することによって利用可能な経路を探して、ブリッジ・メタデータに基づいて、ソース・ネットワークと宛先ネットワークとの間の存在可能な経路を提供するブリッジを識別し、移転のレッグごとの手数料を取得する。移転を容易にするために利用可能な０から多くの経路があってもよい。（人工知能を含む様々な技法を使用して、利用可能な選択肢のリストを狭めることができる、又は可能な経路を優先度付けすることができる。経路は、すべての必要なＩｎｆｉｎＸｃｈａｎｇｅインターフェース及びブリッジ・メタデータから導出したビジネス・ロジックを含むことができる。

送り側、又は自動化されたアルゴリズムは、所望の経路を選択して、所望の移転を開始することができる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。チェーン化移転ハンドラ・モジュール２００４は、取引をシステム取引台帳２０１３（図１２）の台帳に書き込み、監査可能性及びシステム障害の結果として回復可能性を保証する。この記録は、ゼロ知識証明技法を使用して不明瞭にして、取引のプライバシーを損なうことなく不変性を実現することができる。チェーン化移転ハンドラ・モジュール２００４はまた、イベント（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）を公表して移転をシグナリングする。チェーン化移転ハンドラ・モジュール２００４は、ユーザの署名権限を伝達して、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔファンクション（ステップ２）により計画されたルートを使ってソース台帳で子転送を実行し、これには１つ又は複数のブリッジを介する異種ネットワークの巡回を含む。サブ移転の開始の際、この移転は、外部取引台帳内の親取引にリンクされているため、イベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）。ソース・ブリッジ口座への移転が完了すると（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）、イベントがスローされて、移転の完了をマークして、ハンドラが取引の次の部分を開始するようシグナリングする。移転は、ブリッジを介して開始される（ＩＢｒｉｄｇｅＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。ブリッジ移転が完了すると（ＩＢｒｉｄｇｅＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）、チェーン化移転ハンドラ・モジュール２００４は、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔを使用してアウトバウンド台帳上で移転を開始して（ステップ４）、価値を宛先口座又はルートに応じてチェーン内の別のレッグに運ぶ。この取引が開始されると、イベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）。この取引は、独立取引台帳モジュール２０１２の外部取引台帳内の親取引にリンクされている。価値は、宛先口座に運ばれ、ステップ５においてイベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）。チェーン化シーケンスにおける最後のステップとして、すべての取引の完了をシグナリングするイベントがスローされる。すべてのサブ取引が、システム取引台帳２０１２の台帳に記録される。

代替的には、チェーン化移転は、宛先向けのデリバリー用の命令でブリッジ・ソース口座に価値を運ぶことによって、図１６のステップ１及びステップ２をスキップして、外部のシステムから開始することができる。受け取ると、ブリッジ口座はＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ移転を発行する。チェーン化移転ハンドラ・モジュール２００４は、このイベントを読み取り、正当な支払いルートがあるかどうかを判定する。あるルートが利用可能な場合、ブリッジ・ソース口座においてファンドがエスクローに保有された状態でチェーンが開始される。移転が成功すると、これらのファンドは解放される。移転に失敗すると、ファンドはソースに戻されてもよい。ソース台帳がスマート・コントラクトをサポートしている場合、取引を開始することは、オンチェーンのエスクロー方法を活用して、取引の原子性を保証することができる。

図１７は、開示される実装形態による、実例の取引チェーン構築処理の概略図である。図示される処理は、図１２のアーキテクチャによって達成することができる。取引が取引データ構造内で指定されると、ネットワーク・ノード全体での最適な送信経路を識別するための、ＩｎｆｉｎＸｃｈａｎｇｅ（商標）ラッパーと組み合わせたルート計画サービス・モジュール２００６。この実例では、指定される取引は「ＡＢＣトークンを、ステラＤＬＴシステム上のＵｓｅｒＡノードから、リップルＤＬＴシステム上のユーザＢノードに移転する」である。価格、及び期待されるデリバリー時間などの、すべての利用可能な選択肢のセットは、取引データ構造によって指定することができる。ステップ１において、ルート計画サービス・モジュール２００６は、すべての可能なルート及び利用可能なブリッジを評価して、すべてのノードのグラフ及びブリッジを巡回することによって移転を実行する。可能な取引経路が、関連ネットワークについてのブリッジ・メタデータを読み取ることによって分析され、ソース台帳（この実例ではステラ）と宛先台帳（この実例ではリップル）のプロバイダとトークンとの間のすべての接続を表現するブリッジ・グラフを構築する。ブリッジ・グラフは、識別された接続のブリッジのすべての関連ブリッジ・メタデータを含むことができる。

ルート計画サービス・モジュール２００６は、幅優先探索（ＢＦＳ：Ｂｒｅａｄｔｈ Ｆｉｒｓｔ Ｓｅａｒｃｈ）アルゴリズム（選択されたノードからレイヤ方向にグラフを巡回する、既知のグラフ巡回アルゴリズム）を適用してすべての経路を見つけ、ＢｒｉｄｇｅＮｏｄｅＣｈａｉｎのリスト、つまり取引を達成するための可能な経路のリストを返すことができる。この実例では、２つの可能な経路が識別されている（ＴｒａｎｓａｃｔｉｏｎＣｈａｉｎ１、及びＴｒａｎｓａｃｔｉｏｎＣｈａｉｎ２）。ステップ２において、ルート計画サービス・モジュール２００６は、取引要件及び条件のリストに基づいて、最終的な取引経路を構築する。例えば、チェーンが、１ＡＢＣトークンを宛先ウォレットに運ばなければならない場合、且つ関連する送信手数料の合計が０．１ＡＢＣトークンである場合、ソースは１．１ＡＢＣトークンを移転しなければならない。最終的な取引経路は、取引手数料、取引確認時間などの、様々な選好及び属性を考慮するように構築することができる。

図１３Ａを使用して、経路の選択及び取引チェーンをより良好に図示することができる。図１３Ａでは、Ｇｒａｐｈ３０００は、３つのＤＬＴネットワークを有しており、それぞれが少なくとも１つのノードを有していることを思い出されたい。取引は、あるネットワーク内で発生することができる（例えば、Ａ－＞Ｂ、Ｙ－＞Ｚ）。しかしながら、ネットワーク間をクロスするため、例えば異なるＤＬＴネットワークにあるノード間で取引をするためには、ブリッジを使用しなければならない。ブリッジがないと、例えばノードＡとノードＺとの間での移転用の経路は存在しない。ネットワーク同士をリンクするために、ブリッジ口座Ｂ、Ｍ、及びＹが作成される。次いでブリッジは、これらの口座をリンクするためにセットアップされる。ブリッジ１を使用して、例えばＡとＺとの間のルートが存在する（Ａ－＞Ｂ～１～Ｙ－＞Ｚ）。第２のルートは、サード・パーティのネットワーク（Ａ－＞Ｂ～２～Ｍ～３～Ｙ－＞Ｚ）を通じてリンクすることによって存在する。ルート計画サービス・モジュール２００６のルート・プランナは、ネットワーク・グラフを巡回して、潜在的なルートとして、これらのルートを生成する。ユーザ（又は自動化されたサービス）は、選好及び他の属性に基づいて、識別された選択肢の中から最良の移転経路を決定することができる。

図７に戻ると、１つのネットワーク又は台帳から別のネットワーク又は台帳に価値を移動するための能力には、多くの潜在的な経路及びメカニズムが伴う場合がある、又は存在可能な経路がまったくない場合がある。ユーザが支払いデリバリーをリクエストすると、すべての利用可能な選択肢のセット、それらの価格、及び期待されるデリバリー時間が、実質的にリアルタイムに生成されなければならない。図１７のステップ２において、ルート計画サービス・モジュール２００４は、ソース・ノードから宛先ノードへの経路を提供することができるすべての利用可能なブリッジを評価することによって、すべての可能なルートを集める。

取引サービス・バス
すべての抽象経路が計算されてしまうと、ルート計画サービス・モジュール２００６は、抽象経路に基づいて１つ又は複数の取引チェーンを構築する。チェーンを構築するためには、宛先から構築を開始する（デフォルト）、又はソースから構築するという、少なくとも２つの方法がある。宛先からソースに向けて開始する場合、ルート計画サービス・モジュール２００６は、宛先条件を固定ポイントとして始める。ソース・ノードを固定パラメータとして開始する場合、ルート計画サービス・モジュール２００６は、移転が１ＡＢＣで始まった場合に宛先ノードが受け取ることになる価値を決定する。ルート計画サービス・モジュール２００６は、ソースから取引リンクを構築し始め、経路を通じてすべての手数料及び交換を累積する。例えば、すべての手数料が０．１ＡＢＣトークンである場合、受け取り側は最終的に０．９ＡＢＣトークンを得ることになる。次いで、ルート計画サービス・モジュール２００６は、例えば以下の規則に基づいて、現実のチェーンへの抽象経路を構築する：

次いで、ルート計画サービス・モジュール２００６は、すべての経路チェーンを選択して、重複リンクを取り除くことによって、これらを単一の最終取引チェーンにマージする。図１７に示されるように、取引チェーンは、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ１、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ２、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ３、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ４、及びＴｒａｎｓａｃｔｉｏｎＬｉｎｋ５を含む。図１７のステップ３において、ＴｒａｎｓａｃｔｉｏｎＶａｌｉｄａｔｉｏｎＳｅｒｖｉｃｅは、例えば経路中の各リンクのソース・ウォレットが取引をサブミットするのに十分な残高を有しているかどうかをチェックすることによって、及び／又は自己参照チェーン、つまり同一ノードが１つのチェーン内で２回以上発生するチェーンをチェックすることによって、取引経路を実行することができることを検証する。（ポリシー・エンジンは、それぞれの移転ノードにおいて、企業コンプライアンスを検証することができる。例えば、米国特許出願公開第２０１９０１６４１５１（Ａ１）号で説明されるシステム及び方法は、企業コンプライアンスを検証するために使用することができる。）それぞれ存在可能な取引チェーンは、手数料及び交換が関与する可能性があり、推定デリバリー時間を有する。提案される移転の価格及びデリバリー時間は、ユーザに提示するために、移転アクションのユーザ承認に先立って計算することができる。

サブ取引のチェーンにおける移転の間、ネットワーク障害が発生する可能性がある、又は移転が完了する前にキャンセルされる（許可されていれば）可能性がある。この場合、ロールバックが必要となる。中間的な手数料がチャージされる、又は交換が行われる事例では、価値の損失なく取引を反対にすることができない場合がある。このような事例では、ユーザは、移転を完了、ロールバックに進めるために移転チェーンを再開始する選択を行使すること、又はその現在の状態の価値を請求することにより取引を見捨てることができる。図１８の８００２に、（所望の移転取引を達成するための）４つのサブ取引の正常なチェーンが図示されている。４つすべてのサブ取引（８００２ａ、８００２ｂ、８００２ｃ、及び８００２ｄ）が正常である。

しかしながら、ブリッジの構成によっては、取引が失敗すると、システムは、価値を運ぶよう自動的に再開始を行ってもよいか、又は停止してユーザ入力を待機してもよい。図１８の８００４は、サブ取引８００４ｄが失敗したチェーン化された取引を図示している。設定によっては、失敗すると、チェーンは自動的にロールバック取引を開始する場合がある。ロールバック取引は、ルート内で使用される各ブリッジが、両方向への取引をサポート可能な２ｗａｙブリッジである場合にのみ可能である。図１８の８００６は、ロールバック取引を図示している。８００６において、サブ取引８００６ｄは失敗しており、このすべてのサブ取引８００６ａ、８００６ｂ、及び８００６ｃは、これらのサブ取引のそれぞれで反対サブ取引を達成することによって「リバース」される。さらには、８００８及び８０１０において示されるように、取引は途中でキャンセルされる可能性がある。取引８００８では、サブ取引８００８ｂは実行の前にキャンセルされており、そのためサブ取引８００８ａがリバースされている。代替的に、８０１０において、サブ取引８０１０ｂが実行の後にキャンセルされており、サブ取引９０１０ａ及び８０１０ｂの両方がリバースされる。代替的に、取引イニシエータが中間的な台帳を介して価値を受け取る手段を有している場合、８０１２において示されるように、価値は停止した取引から直接請求されてもよい。反対取引を含め、すべてのサブ取引は、システム取引台帳モジュール２０１２に記録される。図９Ａ及び図９Ｂは、組み合わせて、チェーン化移転の状態図９０００の実例を図示している。

それぞれ存在可能なルートは、手数料及び交換が関与する可能性があり、推定デリバリー時間を有する。提案される移転の価格は、移転アクションをサポートするためにユーザに提示するよう計算されなければならない。チェーン化移転ハンドラ２００４は、Ａｔｏｍｉｃｉｔｙ（原子性）（Ａ）に対する管理可能な代替を提供し、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）（Ｃ）、Ｉｓｏｌａｔｉｏｎ（分離性）（Ｉ）、Ｄｕｒａｂｉｌｉｔｙ（耐久性）（Ｄ）をＡＣＩＤ（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＡＣＩＤ＿（ｃｏｍｐｕｔｅｒ＿ｓｃｉｅｎｃｅ） ｐａｙｍｅｎｔ ｄｅｌｉｖｅｒｙ参照）に一貫して実現するように設計される。チェーン化移転ハンドラ・モジュール２００４は、以下のファンクションを提供することによってクロス台帳支払いを編成する：台帳相互運用性、ルート計画、価格及び手数料発見、取引管理、取引状態、並びにロギング。チェーン化移転ハンドラ・モジュール２００４は、ネットワークに対して、以下によって高信頼エンドツーエンド移転を保証する：
・トレーサビリティ及び信頼のために実行される時、提案されるエンドツーエンドの取引及びすべてのサブ取引を、ゼロ知識証明と共に台帳（システム取引台帳２０１２など）に公表する；
・取引が巡回するそれぞれのネットワークにおいて、移転機能を活用する相互運用性フレームワークを使用して移転をシーケンス化する；
・各取引が正常に実行され（又はロールバックされ）、価値が正常に運ばれることを保証する。

Ｉｓｏｌａｔｉｏｎ（Ｉ）は、それぞれ個々の台帳取引をより大きなフローのコンポーネントとして分離する共通のＩＰａｙｍｅｎｔＳｅｒｖｉｃｅプラグインを介して実現される。このプラグイン・フレームワークは、異種の台帳にわたって取引を処理するための共通モデルを提供する。取引管理：取引管理は、チェーン化支払いのＤｕｒａｂｉｌｉｔｙ（Ｄ）を用意する。チェーン化移転ハンドラ・モジュール２００４は、複雑な支払いシーケンスの各ステップを管理して、故障停止又は支払いネットワークの障害に直面しても、それが実行されることを保証する。このコンポーネントは、並列又は直列の取引を取り扱い、支払い及びブリッジ取引を実行する。

特定の取引の不可逆性（手数料のため）、特定のチェーン化支払いを特徴付ける長期のデリバリー時間フレーム、及び頻繁に変化する市場状況により、Ａｔｏｍｉｃｉｔｙ（Ａ）は、保証することができない。スリッページ（取引の開始とその完了までの、為替レート又は手数料の変化）に備えるために、チェーン化移転ハンドラ・モジュール２００４は、著しい変化があった場合、取引を凍結することができ、ユーザが継続する意思に関して検討できるようにする。この点で、取引はロールバックすることができ（手数料は犠牲になる）、価値は、その既存の形式で請求されることができるか、又は（ユーザが変更された約定を受け入れると）取引は完了に進むよう再開始されてもよい。

チェーン化された取引は２つ以上の台帳に関与する可能性があるため、関与する個々の台帳のいずれも、取引のエンドツーエンドのトレーサビリティを含まない。Ｃｏｎｓｉｓｔｅｎｃｙ（Ｃ）を保証するために、独立取引台帳モジュール２０１２によって包括的な台帳が維持され、全体的な取引並びにサブ取引のそれぞれへのリンクが追跡される。チェーン化移転は、ブリッジ構成に依存して直列又は並列に生ずる場合がある。並列な支払いは、高速であるが、インバウンドのデリバリーの時間レイテンシにおけるリスクのため、ロールバックのロック又はヘッジを必要とする場合がある。直列なデリバリーは、スリッページ管理の著しい使用を必要とすることがあり、インバウンドの取引における遅延をサポートするために、アウトバウンドのファンドのロックを必要とする場合がある。

直列で運用される場合、ブリッジは、チェーン化された取引（アウトバウンド）を開始するのに先立って、開始取引（インバウンド）の完了（ＩＰａｙｍｅｎｔ．Ｃｏｍｐｌｅｔｅイベント）の検証を待機する。並列で運用される場合、アウトバウンド取引は、インバウンド取引の開始の検証（ＩＰａｙｍｅｎｔ．Ｉｎｉｔｉａｔｅｄイベント）直後に開始することができる。並列の運用では、ブリッジ・オペレータは、インバウンド（及びすべての中間）取引がキャンセル又はロールバックされた場合、デリバリー・リスクを取る。しばしば、ブリッジ・オペレータは、インバウンドのネットワークがキャンセル及びロールバックを許可しない場合に、並列運用だけを許可する。代替的に、ブリッジ・オペレータは、デリバリー・リスクを補償するために高額な手数料の担保又はチャージを必要とする場合がある。直列の運用では、イニシエータは、スリッページ・リスク、つまり、デリバリーの価格の、取引の最初に提示された最初の約定からの変化を経験する可能性がある。例えば、下流のネットワーク手数料又は為替レートは、取引が開始された時から変わっている可能性がある。ブリッジ・オペレータは、価格保証（スリッページがないこと）を提供することができるが、しばしば市場変化又はヘッジ戦略を補償するために手数料を組み入れる。

上述のことから明らかなように、異種ネットワークに対する取引の経路を提供することに加えて、ブリッジは様々な論理的なファンクションを有することができる。預け入れは、ブリッジ・ファンクションの特殊な実例である。これには、預け入れられたファンドを、ユーザの内部口座に運ばれる等価額のトークン（Ｈｙｐｏｔｈｅｃａｔｅｄ 資産又はＩＯＵ）にリンクするＰｅｇを伴う。ＩＯＵは、他のユーザに移転すること、又は中央集権化された又は非中央集権化された取引所を介して資産と売買することができる。これらのトークンは、反対のフロー、つまり引き出しを使用して、カウンターパーティ口座における価値で償還（決済）することができる。

Ｃｏｕｎｔｅｒｐａｒｔｙプールにおける口座残高は、流通における内部トークンの総数と厳密に一致していなければならない。両方の残高は、ユーザに公表されるべきである。一部のネットワークは、トークンの作成と破壊をサポートしているが、他のネットワークは、コールド・ウォレットを介して流通に出入りする動きを必要とする。

図１０は、担保契約移転を達成するブリッジ用の運用の実例を概略的に図示している。ステップ１において、価値は外部プロバイダ（例えば、ＯＯＢ、Ｃａｓｃａｄｅ、ＰａｙＰａｌ、イーサリアム）を使用してソース・ウォレットから保管ウォレット（ブリッジ・インバウンド）に送られる。ステップ２において、発行者ウォレットから等価な数のＩＯＵ（預け入れ額のデジタル・バージョン）が発行され、ベース・ウォレットに送られる。ステップ３において、ベース・ウォレット（ブリッジ・アウトバウンド）は、ＩＰａｙｍｅｎｔ．Ｔｒａｎｓｆｅｒを定め、価値をインターネット・プロバイダの宛先ウォレットに送る。このパターンは、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳上で取引を検出して属性付け、発行者ウォレット及びベース・ウォレットからの取引を実行するための手段を有することを必要とする。この権限へのアクセスは、ブリッジのセットアップ時にグラントすることができる。ステップ２をスキップして、発行者ウォレットから宛先ウォレットに直接送ることができることに留意されたい。

決済は、担保契約移転の逆である。ユーザが価値を台帳から除去し、価値をその元の形態に戻したいと思う場合、決済ブリッジを巡回する移転が開始される。図２１は、決済移転を達成するブリッジ用の運用の運用の実例を概略的に図示している。ステップ１において、価値はＥｘｔｅｒｎａｌプロバイダ（例えば、ＯＯＢ、Ｃａｓｃａｄｅ、ＰａｙＰａｌを使用してソース・ウォレットからベース口座（ブリッジ・インバウンド）に送られる。ステップ２において、保管ウォレット（ブリッジ・アウトバウンド）は、ＩＧａｔｅｗａｙ Ｐａｙｍｅｎｔを定めて価値を宛先ウォレットに送る。ステップ３において、先行ステップの完了に応答して、等価な数のＩＯＵ（決済額のデジタル・バージョン）がベース（エスクロー）ウォレットからバーンされる（つまり、破壊される）。このパターンは、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳上で取引を検出して属性付け、保管ウォレットからの取引を実行するための手段を有し、ベース・ウォレットからのトークンをバーンすることを必要とする。この権限へのアクセスは、ブリッジのセットアップの一部としてグラントすることができる。また、取引が失敗した場合にバーンをリバースするための権限が存在すれば、ステップ３をスキップして、ソース・ウォレットから発行者ウォレットに直接受け取ることが可能である。

マルチ台帳発行のために、クロス台帳変異を使用することが可能である。これは、例えば、所有権の公的な記録が移転用に使用されている台帳とは別個である場合、又は公的な記録が影響を受ける台帳の所有権の記録の合計である場合に使用される。上述の具体的な台帳に存在するＩｎｆｉｎＸｃｈａｎｇｅ（商標）の合計メカニズムを用いて、変異により、トークンが複数の台帳上で発行できるようになる、及び／又は１つの台帳上で発行されたトークンが別の台帳に「フロー」できるようにする手段を提供する。トークンが台帳から台帳へ移動すると、流通におけるトークンの総数は一定なままであるが、所有権の記録は台帳から台帳へと移動する。このタイプのブリッジは、引き出しファンクションと預け入れファンクションを連結する。トークンを１つの台帳から同時に除去することによって、トークンは別の台帳の流通に導入され、トークンの総数は一定なままである。台帳から出て行くファンドは、ソース台帳ベース・ウォレットに送られる。この移転はまた、トークンを移動させずにトークンを保留するエスクロー取引であってもよい。等価な数のトークンが、発行者（ウォレット、口座、又はスマート・コントラクト）から宛先台帳上の流通に、又はＣｏｌｄウォレットからプロバイダＢ上のアウトバウンド・ウォレットに、宛先へのデリバリー用に発行される。デリバリーに成功すると、ソース台帳で呼び出されたＩＩｓｓｕｅｒ．Ｄｅｓｔｒｏｙファンクション流通からトークンを除去する。

アウト・オブ・バンド移転モジュール２１０４は、価値移転経路レッグがシステム内で完全に自動化されない場合に、アウト・オブ・バンド（ＯＯＢ）処理を提供する。サード・パーティがシグナリングしてデータを申し込み側のシステムに提供し、処理の実行を容易にできるように、インターフェースが設けられる。例えば、ブリッジがネットワーク間でファンドの１ｗａｙフローのみをサポートすることができる事例では、ファンドの不均衡が累積し、バランスを回復させるためにＯＯＢ取引が必要とされる場合がある。ＯＯＢのタイム・ラグ、及びアウトバウンド口座における適正なファンドの事前位置付けを管理することは、制御用にしっかり確立された数学的モデルを伴うロジスティックスの問題である。価格発見は、価格及び流動性モジュール２０１０（図１２）の運用によって容易になる。このモデルは、市場ファンクションを通じて価格を調節し、インバウンドとアウトバウンドとの口座レベルのバランスを維持することが可能である。流動性を補充するために、外部の市場を使用することができる。ダークプールの所有者（資産をプールへ寄付する人）は、プールの使用にリンクした手数料から収入を受け取る。価格及び流動性モジュール２０１０は、エコシステム、通貨、資産取引所間の流動性を管理するように設計される。価格及び流動性モジュール２０１０は、マーケット・メイキングのアルゴリズムを適用して流動性を管理する。価格及び流動性モジュール２０１０は、ダークプールの両側のリソースの残高に基づいて、移転のコストを管理してもよい。これは資本のフローにおける持続的な不一致のコストを押し上げる。ＡとＢとの間のリソース・フローにおける持続する不均衡は、Ａ－＞Ｂに動くと価格が上昇し、Ｂ－＞Ａでは減少する。不一致が大きいと、モデルの収益が大きくなる。ユーザは、必要なところに流動性をもたらすよう、不一致に「投資」することができる。

通貨の交換が伴う場合、流動性ダークプールを使用して、エコシステム同士、又はエコシステム内の移転を容易にすることもできる。チェーン化されたフローは、価値のあらゆるフローのための経路を提供し、外部の流動性を使用するために、利用可能な通貨の交換を含み、多くのプロバイダに対して繰り返されてもよい。通貨の交換は、価格及び流動性モジュール２０１０を介して発生することができる。処理は、繰り返され、カウンターパーティの交換口座を使用して流動性を最大化することができる。

上述の技術的なプラットフォーム及びデータ構造は、コンピュータ売買プラットフォームの有効性及びスループットを向上させるために使用することができる。取引効率は、以下のものとして測定することができる：１）取引からもたらされる、価格の変化；２）取引を完了するための時間；又は３）サポートすることができる取引の合計サイズ。価値を、別の形態の価値と交換するリクエストが、ある資産の他の資産に対する著しい価格比率の変化なしに、短期間のうちに満たすことができない場合、市場は、非流動的であると言われる。例えば、図２２に図示されるように、投資家は、マーケットプレイス又は取引所から、金（資産Ｂ）をＵＳＤ（資産Ａ）で購入したい場合がある。マーケットプレイスは、価格決定エンジンによってセットされた価格で、金との交換でＵＳＤを受け入れる。金購入の一定の流入は、結果として、利用可能なＵＳＤが増加して、利用可能な金のプールが対応して減少する。利用可能な金のアウトバウンド口座供給が減少するため、その流動性（あらゆる価格における大量注文をサポートする能力）は低下する。金の需要の増加が続き、交換の価格が変わらない場合、宛先プールにおける金の供給は結果的に不足し、流動性の全体的な損失につながる。

マーケットプレイスにおいて資産の流動性を持続させるためには、いくつかのファクタが必要とされる：資産Ａを有しており資産Ｂの需要がある投資家の利用可能性；マーケットプレイスにおいて需要を満たす資産Ｂの適切な供給；供給を需要と一致させるための、資産Ｂの固有な価値に一貫した効果的な価格決定；資産Ｂが使用を邪魔されずに利用可能となるべく、効果的でタイムリーな所有権移転。より直接的には、流動的な市場は、効率的に価格決定して、供給／需要を一致させ、価値の使用を許可するよう迅速に決済する。

図２３は、１ペアの資産同士での流動性をサポートする従来的なシステムの基本的な要素を図示している。システムは：指定された価格（資産Ｂの単位当たりの資産Ａの単位の比）で、資産Ａと引き換えにある金額の資産Ｂをリクエストする手段をサポートすることができる；リクエストに対して資産Ｂを運ぶ手段を含むことができる（通常は資産のプール）；資産Ｂと引き換えに資産Ａのデリバリーを受け入れることができる。任意選択で、システムは：サービスに手数料をチャージし、流動性メカニズムの使用を通じて資産Ａの累積を使用して、資産Ｂの利用可能なプールを補充するためのメカニズムを必要としてもよい。

流動性ファンクションの中心的な恩恵は、資産Ａから資産Ｂへの変換である。ソース及び宛先準備金は、異なる通貨、カウンターパーティ、ネットワーク、資産タイプ、管轄域などであってもよい。流動性サービスの価値は、資産価値を変形（交換）できる容易さ、又は代替的な手段を使用してソースから宛先に移転できる容易さに反比例する。代替的な手段を用いて、資産を、自由に、瞬時に、確実に、便利に、そして劣化することなく動かすことができる場合、流動性ファンクションには有用性はなく、手数料を命じることはできない。代替的な変換が、高額、低速、安全でない、又は不便となる程度が、ファンクションの有用性及び収益性を決定する。

資産価値が、いつも１つの方向にフローし、フロー同士のバランスが取れていない場合、持続的な運用は、フローを持続するためにアウト・オブ・バンドの補充モデルを必要とする。このアウト・オブ・バンド処理のセキュリティ及びコストは、モデルの収益性に影響する。バランスの取れたフロー、つまりソースから宛先に動く価値が反対方向への等価なフローに一致している価値フローは、アウト・オブ・バンドの補充の必要性を回避するため、最も望ましい。システムは、両方の資産の準備金の比率が所望の目標に一致する時、局所平衡にある。

図２５は、ある資産トークンを定義するデータ構造を概略的に図示している。図２５の資産トークンは、図１～図８に対して上述したトークン構造を使用することができ、これらの図ではトークンはウォレットを所有して、ウォレットは再帰的なやり方でトークンを所有する。実装形態は、資産のペアを含む資産のクラスをトークン化するために、ＤＬＴ技術を利用することができる。クラス・メンバは、ウォレット２５０４を所有する非代替性資産トークン２５０２であることができ、資産のペアのそれぞれの側における資産を表現するトークン２５０６ａ及び２５０６ｂを保有している。非代替性トークン２５０２は、代替性トークン２５００８内に「ラップされる」（例えば、代替性トークンは、上述のＩＡｓｓｅｔＦｕｎｄインターフェースを実装することができる）。したがって、代替性トークン２５０８は、基礎となる非代替性資産トークン２５０２の所有権を表現することができる。代替性トークン２５０８（「親トークン」）の保有者は、ペアの間に流動性を与えることによって生成される収益を反映する配当を取得してもよい。非代替性トークン２５０２並びに資産トークン２５０６ａ及び２５０６ｂは、上述のやり方で、資産レジストリ１０４（図１参照）に登録することができる。

非代替性トークン２５０２に類似したトークンは、本明細書において「流動性トークン」と称される。代替性トークン２５０８などのトークンは、本明細書において「ラップされた流動性トークン」と称され、上述のようなネットワーク化されたコンピューティング・プラットフォーム上に実装された取引所を介して、全体的に又は一部、移転することができる（ラップされた流動性トークン内の株式を売却することによって）。例えば、ラップされた流動性トークンは、図１及び図１２に関して上述した技法に類似したやり方で、ネットワーク化された売買プラットフォーム上で取引することができる。

図２６に図示されるように、ラップされた流動性トークン（ＡＢ）の価格は、基礎となる資産の価値、及び基礎となるソース準備金、つまり「流動性プール」によって作り出される収益に依存する。ペア間の流動性への高い需要は、ペアの流動性トークン保有者へ支払われる配当を増加させ、次いでラップされた流動性トークンへのさらなる需要を作り出す。

資産ペアの流動性トークンの需要の高まりは、エコシステムへの資本の純流入となる。この資本の流入は、流動性プール内で、キャッシュとトークン準備金との間に不均衡を作る。上で開示される弾力的な証券化技法を用いて、資本の流入は、基礎となる資産プールを増加させるために使用することができる。価格決定ファンクションとしてスマート・コントラクト（又は他のアルゴリズム）を使用して、準備金に保有される流動性プール内のキャッシュがしきい値にヒットすると（流動性ファンクションにおける需要の高まりを反映して）、そのキャッシュをより広い基礎となるプールに移動して、償還需要を満たすため、又は流動性ペアに必要な資産を買うために提供することが可能である。ソース準備金内のキャッシュの結果的な増加は、エコシステムの全体的な流動性を高めることを助ける。

図２６に示されるように、流動性プールは、流動性トークン用に作成することができる－つまり図２３の基礎となる流動性プール及び価格決定ファンクションに類似した配置構成を使用する。この流動性プールは、ポートフォリオの一部であってもよく、流動性を管理するために使用される。これは、資本のシステムへの純流入及び流出を統制する助けとなる。図２６に示されるように、流動性トークンを構成するために、非代替性資産トークン（図２５の２５０２）が、上述のように、ソース口座及び宛先口座と共に作成され、価格決定ファンクション及び手数料構造を含む。資産トークンは、代替性トークン（図２５の２５０８）内にラップされ、投資家が流動性資産に投資できるようにしている。弾力的な証券化規則により、投資が資産へ／資産からフローして需要を満足できるようにしている。

流動性を必要とする各ペアは、自分自身の流動性トークンを有しているため、自己バランス型の流動性システムは、資産ペアのエコシステム全体に形成することができる。１つのペアに対する流動性の必要性が低下すると、その配当は下がり、そのペアに対する流動性トークンの投資家需要を低下させる。このことは、そのペア流動性プールからの資本の純流出となる。利回りを求める投資家は、自身の資本を、手数料が市場を上回っている他のペアに投資する。この方法では、資本は流動性に対する最大の需要にフローし、自己バランス型システムをもたらす。流動性トークンは、上述のようにその後代替性トークン内にラップすることが可能な親ファンド・トークンにまとめることができ、ファンドの株式を売却できるようにして、保有者が基礎となるウォレット内の価値の利息及び手数料から生じる収益を所有できるようにしている。

流動性トークンは、ダークプール（私的に組織化されたフォーラム及び取引所）と併せて使用して、例えば、図１２に関連して開示されたブリッジ及びプラットフォームを使用して、エコシステム同士での価値の移転を促進及び自動化することができる。チェーン化移転技術と併せて使用され、ブリッジに関連付けられる流動性トークンは、エコシステム同士での価値の移転に資金を提供する手段を提供する。ダークプールは、手数料、マーケット・メイキング、又は両方を通じて価値を生成する。収入生成ポートフォリオとして、これらはサード・パーティによって所有されるか、セキュリティ・トークンとして売買される。ダークプールは、ジャストインタイムのサプライ・チェーン・マネジメント・ソリューションを表現して、より低速で、内部的な補充処理に対して一過性のフローを最適化する。

流動性価格決定ファンクションは、資産、エコシステム、及び取引所同士の流動性を管理する。エンジンは、リソースのバランスを取るために必要な移転のコストを管理する。これは、ユーザにインセンティブを与えて不一致に「投資」して流動性を必要なところで動かすことによって、資産のフローにおける持続的な不一致のコストを押し上げる。流動性価格決定ファンクションの一実装形態は、ソース準備金残高と宛先準備金残高との相対的なバランスを監視して、最近の価格決定履歴に基づいて価格及び価格の変化率を、外部情報に基づいてアンカー値を、補充に関する手数料を、及び動かされている価値の量を、調節する。流動性価格決定ファンクションはまた、市場の状況及びボラティリティに基づいてスプレッド（最小のビッドとアスクの注文価格との差）を決定する。

図２４は、価格決定ファンクションを図示している。開示される価格決定ファンクションは、以下を含む、複数のファクタを組み込む：ソース準備金口座と宛先準備金口座との不均衡、現在の市場の状況及びアクティビティ、外部価格決定、資産の額面価格、及び他のファクタ。価格決定アルゴリズムには、スプレッドを広げること、及び他の技法による市場操作に対する保護策を組み入れる。価格決定ファンクションの一実装形態は、取引所に注文を出すことによって価格を管理する。別の実装形態は、流動性リクエストに直接応答して価格をセットするアルゴリズムを通じて価格を直接的に管理する。

リソースがドローダウンすると価格を上昇させる動的な価格決定ファンクションを用いて、流動性エンジンは、市場が平衡に達するまで資産Ｂの価格を上昇させる（資産Ａの観点から）。図２４に図示される実例では、資産Ｂの需要は、資産Ｂの準備金プールの減少、及び平衡価格の上昇につながる。反対方向への純需要は価格を押し下げる。平衡価格が支配的な市場価格から逸脱する程度が、流動性の価格である。動的な価格ファンクションは、価値のフローに突然の不均衡があっても、準備金リソースが決して不足しないことを保証するように設計される。動的な価格決定ファンクションは、比例－積分－微分（ＰＩＤ：Ｐｒｏｐｏｒｔｉｏｎａｌ Ｉｎｔｅｇｒａｌ Ｄｅｒｉｖａｔｉｖｅ）コントローラによって駆動され、持続的な流動性需要に従って価格を動的に調節することができる。

不均衡なフローには、価値をある準備金から別の準備金にＯＯＢで動かす必要がある可能性がある。ＯＯＢ移転には、ファンドの手作業の移動、取引所の使用、又は上述のようなメインの移転チャネルとは独立した他の移転チャネルが伴う場合がある。しばしば、ＯＯＢ取引は、長時間のデリバリー時間を伴う場合があり、コストがかかる場合がある。これらの移転の時間及び費用は、従来的なロジスティックス問題のパラメータを定義する－つまり需要の変動性並びに補充する時間及び費用に基づいて、事前位置決めへの価格の金額を決定する。

流動性準備金の運用からの収益は、２つのソースによって生成される：１）取引にかかる手数料、及び２）スプレッド（フローの、逆フローからの交換価格の差）。手数料は、収益を最大化するように調節することができる。手数料が高すぎると、チャネルは使用されず、収益をもたらさない。手数料が低すぎると、機会を損失する場合がある。類似のロジックが、スプレッドに関連付けられるマーケット・メイキング・ファンクションに適用される。

トークン化構造を作成するため、及び資産管理ファンクションを行うために、追加的な代替構造及び機能上の設計が実装されてもよい。したがって、実装形態及び実例が図示され、説明されたが、発明は本明細書に開示された正確な構築及びコンポーネントに限定されないことを理解されたい。添付の特許請求の範囲で定義される本発明の思想及び範囲を逸脱することなく、配置構成、運用、並びに本明細書において開示される方法及び装置の詳細において、様々な修正形態、変更、及び変形形態が成され得る。

ＣＯＤＥ ＡＰＰＥＮＤＩＸ

Claims (9)

1. 資産のトークン化ペアを作成する方法であって、前記方法は、
   流動性トークンを作成することを含み、前記流動性は、資産ペアのための流動性ファンクション、及び前記流動性ファンクションによって作り出される収益の有益な所有権、及び流動性をサポートするために必要な前記資産の所有権、を表現するデジタル・トークンである、方法。
2. 前記流動性トークンが、クラス定義に従って非代替性トークンとして作成され、前記流動性トークンが、一意なトークン識別子を含み、
   前記流動性トークンの所有権を前記代替性トークンに割り振ることによってデジタル代替性トークンで前記流動性トークンをラップすることであって、それによって前記資産及び前記流動性トークンによって表現される収益の部分所有権を可能にするデータ構造を作成する、ラップすること
   をさらに含む、請求項１に記載の方法。
3. 前記流動性トークンに、流動性ファンクション及び資産管理をサポートするために、スマート・コントラクト・ウォレットを割り振ることと、
   資産トークンを、それぞれの資産トークンをクラス定義に従って資産ペアにおけるそれぞれの資産プールを表現する非代替性デジタル・トークンとして、作成することであって、それぞれのデジタル・トークンが一意なトークン識別子を含む、作成することと、
   前記資産トークンのそれぞれの所有権を流動性トークンによって所有されるウォレットに割り振ることと
   をさらに含む、請求項２に記載の方法。
4. 資産トークンに、前記資産プール用の流動性運用をサポートするために、スマート・コントラクト・ウォレットを割り振ること
   をさらに含む、請求項３に記載の方法。
5. 弾力的な証券化アルゴリズムが適用されて、基礎となる流動性の必要性を満たすよう前記資産ペアの前記資産に投資されたリソースを割り当てる、請求項１に記載の方法。
6. 資産のトークン化ペアを作成する方法であって、前記方法は、
   クラス定義に従って資産ペアのそれぞれの側のデジタル・トークンを作成することであって、それぞれのデジタル・トークンは一意なトークン識別子を含む、作成することと、
   前記デジタル・トークンを、対応する前記資産と関連付けて、一意なレコードとして資産レジストリのメモリ・デバイスに登録することと、
   前記デジタル・トークンのそれぞれの所有権を、非代替性トークンによって所有される個々のウォレットに割り振ることと、
   前記非代替性トークンの所有権を代替性トークンに関連付けられるウォレットに割り振ることによって、前記非代替性トークンを前記代替性トークンでラップすることであって、それにより前記資産ペアの前記資産の間に流動性を与えることによって生成される収益を表現するデータ構造を作成する、ラップすることと
   を含む、方法。
7. 弾力的な証券化アルゴリズムが適用されて、基礎となる流動性の必要性を満たすよう前記資産ペアの前記資産に投資されたリソースを割り当てる、請求項６に記載の方法。
8. 資産のトークン化ペアを表現するデータ構造であって、前記データ構造は、非一時的な媒体に記録され、
   資産ペアのそれぞれの側のデジタル・トークンであり、それぞれのデジタル・トークンは、クラス定義に従って作成され、それぞれのデジタル・トークンは、対応する前記資産と関連付けて、一意なレコードとして資産レジストリのメモリ・デバイスに登録される一意なトークン識別子を含む、デジタル・トークン
   を含み、
   前記デジタル・トークンのそれぞれの所有権は、非代替性デジタル・トークンによって所有される個々のウォレットに割り振られ、
   代替性デジタル・トークンは、前記非代替性トークンを前記代替性トークンに関連付けられるウォレットへ所有権割り振りすることを通じて、前記非代替性デジタル・トークンをラップし、それにより前記資産ペアの前記資産の間に流動性を与えることによって生成される収益を表現するデータ構造を作成する、データ構造。
9. 弾力的な証券化アルゴリズムが適用されて、基礎となる流動性の必要性を満たすよう前記資産ペアの前記資産に投資されたリソースを割り当てる、請求項６に記載の方法。

Images