JP6922097B2 - スマートコントラクトのトークン化された制御のためのシステムおよび方法 - Google Patents

Description

関連出願の相互参照
本出願は、その内容全体が参照により本明細書に組み込まれる、2019年4月10日に出願された米国仮特許出願第62/832,145号、2019年4月18日に出願された米国仮特許出願第62/835,801号、2019年7月26日に出願された米国仮特許出願第62/879,187号、2019年9月9日に出願された米国仮特許出願第62/897,589号、および2019年12月19日に出願された米国特許出願第16/721,067号の利益を主張する。

記載された実施形態は、電子取引、特に分散型台帳システムで電子取引を行うためのシステムおよび方法に関する。

イーサリアムブロックチェーンは、プログラム可能であり、ユーザがスマートコントラクトの形式でカスタムプログラムを作成し、展開できるようにする。イーサリアムブロックチェーンのプログラマビリティは、チューリング完全であり、イーサリアムブロックチェーンにおいて展開されたスマートコントラクトのプログラムコードを実行するように動作するイーサリアム仮想マシン("EVM")によって部分的に可能になる。

イーサリアムブロックチェーンは、ピアツーピアネットワークプロトコルを介して互いに通信する複数のノードから構成される。各ノードは、独自のEVMを実行し、特に各ノードは、その独自のローカルEVMを使用して、展開されたスマートコントラクトの同じプログラムコードを実行する。各ノードは別々にEVMを実行するので、イーサリアムネットワークは、プロトコルを使用して、すべてのノード間でコンセンサスを維持し、ノードが共有状態を維持できるようにする。このコンセンサスメカニズムは、コンセンサスメカニズムを介して確認された後、ブロックチェーンに記憶されている特定のデータを不変にする。

第1の広範な態様では、スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約(CFRA)を自動的に行うための方法が提供され、第1のスマートコントラクトを識別するステップであり、第1のスマートコントラクトは、第1のアドレスおよびそれに関連付けられた第1の借り手アドレスを有し、第1のスマートコントラクトは、(i)第1の借り手アドレスに転送された暗号通貨の金額に最初に基づく未払金額値と、(ii)第1の借り手アドレスに関連付けられたスマートコントラクトにコミットされた担保オブジェクトの値を表す担保価値と、(iii)外部金利または内部金利に少なくとも基づいて、第1の変動金利を定期的に決定するように構成された金利クエリルーチンとを有する、ステップと、第1のスマートコントラクトに関連付けられた少なくとも1つのローントークンを識別するステップであり、少なくとも1つのローントークンは、担保オブジェクトへの関心を表す、ステップと、第2のスマートコントラクトを識別するステップであり、第2のスマートコントラクトは、第2のアドレスおよびそれに関連付けられた第1の貸し手アドレスを有し、第2のスマートコントラクトは、(i)第1の貸し手アドレスに関連付けられた暗号通貨の貸し手金額を表す貸し手残高と、(ii)外部金利または内部金利に少なくとも基づいて第2の変動金利を定期的に決定するように構成された第2の金利クエリルーチンとを有する、ステップと、債務対象(obligation object)を生成するステップであり、債務対象を生成するステップは、少なくとも1つのローントークンの制御を受信するステップと、少なくとも1つのローントークンに関連付けられた担保価値に基づいて、債務対象の借り手残高を生成するステップと、貸し手金額の制御を受信するステップと、貸し手金額に基づいて、債務対象の貸し手残高を生成するステップと、少なくとも1つの貸し手トークンおよび少なくとも1つの借り手トークンを生成するステップと、少なくとも1つの貸し手トークンを第1の貸し手アドレスに関連付けるステップと、少なくとも1つの借り手トークンを第1の借り手アドレスに関連付けるステップと、債務対象に関連付けられた所定の金利を決定するステップとを含むステップと、債務対象を実行するステップであり、債務対象を実行するステップは、第1の借り手アドレスから少なくとも1回の第1の支払いを受信するステップと、第1の貸し手アドレスから少なくとも1回の第2の支払いを受信するステップと、少なくとも1回の第1の支払いおよび少なくとも1回の第2の支払いに基づいて借り手残高を更新するステップと、トリガイベントを検出するステップと、トリガイベントの検出に応答して、貸し手残高および少なくとも1回の第1の支払いに基づいて、貸し手返金額を計算するステップと、借り手残高および少なくとも1回の第1の支払いに基づいて、借り手返金額を計算するステップと、貸し手返金額および借り手返金額に基づいて暗号通貨をリリースするステップとを含むステップとを含む。

いくつかの場合には、少なくとも1つの貸し手トークンは、複数の貸し手トークンを含む。

いくつかの場合には、複数の貸し手トークンのサブセットが第2の貸し手アドレスに関連付けられ、貸し手金額が、第1および第2の貸し手アドレスにそれぞれ関連付けられた複数の貸し手トークンの割合に従って、第1の貸し手アドレスと第2の貸し手アドレスとの間で再割振りされる。

いくつかの場合には、本方法は、第1の貸し手アドレスから少なくとも1つの貸し手トークンの関連付けを解除するステップと、ローン金額のサブセットを第1の貸し手に転送するステップと、第2の貸し手から、ローン金額のサブセットを置き換えるために、2次ローン金額を受信するステップとをさらに含んでいてもよい。

いくつかの場合には、少なくとも1つの借り手トークンは、複数の借り手トークンを含む。

いくつかの場合には、複数の借り手トークンのサブセットが第2の借り手アドレスに関連付けられ、借り手残高が、第1および第2の借り手アドレスにそれぞれ関連付けられた複数の借り手トークンの割合に従って、第1の借り手アドレスと第2の借り手アドレスとの間で再割振りされる。

いくつかの場合には、本方法は、第1の借り手アドレスから少なくとも1つの借り手トークンの関連付けを解除することをさらに含んでいてもよい。

いくつかの場合には、債務対象を生成するステップは、所定の金利を決定するために外部サーバまたはスマートコントラクトにクエリを行うことをさらに含む。

いくつかの場合には、所定の金利は固定されている。

いくつかの場合には、債務対象を実行するステップは、外部金利が所定の金利未満であると判断するステップと、外部金利と所定の金利との間の差に基づいて、貸し手アドレスに割り振られるローン金額の割合を増加させるステップとをさらに含む。

いくつかの場合には、債務対象を実行するステップは、外部金利が所定の金利を上回ると判断するステップと、外部金利と所定の金利との間の差に基づいて、借り手アドレスに割り振られるローン金額の割合を増加させるステップとをさらに含む。

いくつかの場合には、貸し手金額の制御を受信するステップは、債務対象が貸し手金額の制御を受信するステップを含み、本方法は、未払金額値を低減するために、貸し手金額の一部を第1のスマートコントラクトに転送するステップをさらに含む。

いくつかの場合には、トリガイベントを検出するステップは、担保価値が現在貸し手に割り振られているローン金額よりも低いことを検出するステップを含む。

いくつかの場合には、トリガイベントを検出するステップは、債務対象の期間が経過したことを検出するステップを含む。

いくつかの場合には、第1の支払いは、第1の変動金利に基づく少なくとも1回の借り手利息支払いである。

いくつかの場合には、第2の支払いは、第2の変動金利に基づく少なくとも1回の貸し手利息支払いである。

いくつかの場合には、債務対象はスマートコントラクトである。

いくつかの場合には、少なくとも1回の第1の支払いが複数回の支払いを含み、少なくとも1回の第1の支払いを監視するステップが、複数回の支払いを定期的に監視するステップを含む。

いくつかの場合には、暗号通貨は、Daiの形式に基づく。いくつかの場合には、外部金利は、Dai貯蓄率である。いくつかの場合には、外部金利は配当率に基づく。

別の広範な態様では、スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うための方法が提供され、債務対象を生成するステップであり、債務対象は、第1のアドレスおよびそれに関連付けられた第1の借り手アドレスを有し、債務対象は、(i)第1の借り手アドレスに転送された暗号通貨の金額に最初に基づく未払金額値と、(ii)第1の借り手アドレスによって債務対象にコミットされた担保オブジェクトの値を表す担保価値と、(iii)外部金利または内部金利に少なくとも基づいて、第1の変動金利を定期的に決定するように構成された金利クエリルーチンとを有し、債務対象は、それに関連付けられた第1の貸し手アドレスと、(i)第1の貸し手アドレスに関連付けられた暗号通貨の貸し手金額を表す貸し手残高とをさらに有し、債務対象を生成するステップは、少なくとも1つのローントークンに関連付けられた担保価値に基づいて、債務対象の借り手残高を生成するステップと、貸し手金額に基づいて、債務対象の貸し手残高を生成するステップと、少なくとも1つの貸し手トークンおよび少なくとも1つの借り手トークンを生成するステップと、少なくとも1つの貸し手トークンを第1の貸し手アドレスに関連付けるステップと、少なくとも1つの借り手トークンを第1の借り手アドレスに関連付けるステップと、債務対象に関連付けられた所定の金利を決定するステップとをさらに含むステップと、債務対象を実行するステップであり、債務対象を実行するステップは、第1の借り手アドレスから少なくとも1回の第1の支払いを受信するステップと、第1の貸し手アドレスから少なくとも1回の第2の支払いを受信するステップと、少なくとも1回の第1の支払いおよび少なくとも1回の第2の支払いに基づいて借り手残高を更新するステップと、トリガイベントを検出するステップと、トリガイベントの検出に応答して、貸し手残高および少なくとも1回の第1の支払いに基づいて、貸し手返金額を計算するステップと、借り手残高および少なくとも1回の第1の支払いに基づいて、借り手返金額を計算するステップと、貸し手返金額および借り手返金額に基づいて暗号通貨をリリースするステップとを含むステップとを含む。

別の広範な態様では、プロセッサによって実行されると、プロセッサに、本明細書に記載された方法を実行させる、プロセッサによって実行可能なコンピュータプログラムコードを記憶する非一時的コンピュータ可読媒体が提供される。

さらに別の広範な態様では、スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うためのシステムが提供され、データ通信ネットワークと、少なくとも1つの貸し手デバイスと、少なくとも1つの借り手デバイスと、プロセッサおよびメモリを含む少なくとも1つのノードデバイスであり、プロセッサが本明細書に記載された方法を実行するように構成される、少なくとも1つのノードデバイスとを含む。

次に、図面を参照しながら、本発明の好ましい実施形態について詳細に説明する。

少なくともいくつかの例示的な実施形態によるシステムの概略ブロック図である。 少なくともいくつかの例示的な実施形態によるコンピューティングデバイスの簡略化された概略ブロック図である。 少なくともいくつかの実施形態による、トランザクションを行う方法を示すプロセスフロー図である。 少なくともいくつかの実施形態による、トランザクションを行う方法を示すプロセスフロー図である。 少なくともいくつかの実施形態による、トランザクションを行う方法を示すプロセスフロー図である。 債務対象に関連付けられた少なくとも1つまたは複数の貸し手を変更する方法のプロセスフロー図である。 債務対象に関連付けられた少なくとも1つまたは複数の借り手を変更する方法のプロセスフロー図である。 CDPスマートコントラクトの例示的なライフサイクルのプロセスフロー図である。 いくつかの実施形態による、債務対象に関連付けられた貸し手を転送する例示的な方法のプロセスフロー図である。 いくつかの実施形態による債務対象の作成を示すプロセスフロー図である。 いくつかの実施形態による債務対象の作成を示すプロセスフロー図である。 いくつかの実施形態による債務対象の作成を示すプロセスフロー図である。 いくつかの実施形態による債務対象の作成を示すプロセスフロー図である。 少なくともいくつかの実施形態による、トランザクションを行う方法を示すプロセスフロー図である。

定義
担保付き負債ポジション(CDP)-資産保有者がデジタル資産を預金し、対応する金額のDaiを借りることを許可する、一般的にスマートコントラクトを介して施行される契約である。担保資産を引き出すために、借用したDaiを返済する必要がある。CDPは過剰に担保されており、これは担保の価値が、生成されたDaiの価値よりも高くなるように意図されていることを意味する。
継続的な金利先渡契約(CFRA)-金利スワップの継続的側面を組み込んだ金利先渡契約の変形である。CFRAでは、支払うべき金額は、契約期間中(単に終了ではなく)、外部で定義されたレートの関数であってもよい。これは、支払うべき金額は、契約期間の満了時でのレートのみに基づいて計算される従来の金利先渡契約とは対照的である。
分散型自律組織(DAO)-スマートコントラクトなど、コンピュータプログラムで定義されたルールによって表され、株主によって制御される組織である。DAOの記録およびプログラムルールは、ブロックチェーンにおいて記憶され、および更新される場合がある。
Dai-外部ストアの値(すなわち、米ドル)に対して安定した値を維持するようにプログラムされている、分散型、担保資産ありの暗号通貨である。Daiは、Maker DAOによって管理されている。Daiは、担保付き負債ポジション、自律的フィードバックメカニズム、および外部アクターについてのインセンティブのシステムを介して安定している。
Dai貯蓄-Dai暗号通貨の保有者がいつでもDaiをロックまたはアンロックできるようにするDai暗号通貨に実装されたスマートコントラクトなどのメカニズムである。ロックされたDaiは、DSR値に基づいたレートで、時間の経過とともに追加のDaiが生じる。
Dai貯蓄率(DSR)-ロックされたDaiの金利または経過金利を定義するDai暗号通貨システムのグローバルシステム変数である。
ガバナンス料金-Daiを鋳造するコストの補償として、およびDaiの価値を安定的に維持するようにMKR保有者にインセンティブを与えるために、CDPスマートコントラクトの保有者がMKRガバナンストークンの保有者に支払う料金である。
MKR-Maker DAOシステム内のガバナンストークンである。MKRトークンの保有者は、Maker DAOへの変更の提案に投票することが許可される。
安定手数料-CDPを使用してDaiを借りるために請求される料金であり、安定手数料は、ガバナンス料金およびDSRに基づく。

説明を簡単かつ明瞭にするために、適切であると見なされる場合、対応するまたは類似の要素またはステップを示すために、図面間で参照番号を繰り返す場合があることを理解されたい。加えて、本明細書に記載された例示的な実施形態の完全な理解を提供するために、多くの特定の詳細が記載されている。しかしながら、本明細書に記載された実施形態は、これらの特定の詳細なしで、または他の方法、構成要素、材料などを用いて実施され得ることが当業者によって理解される。他の事例では、周知の方法、手順、および構成要素は、当業者に知られているので、詳細には説明されていない。さらに、この説明は、本明細書に記載された実施形態の範囲を限定することを意図するものではなく、単に1つまたは複数の例示的な実装を説明するものであることに留意されたい。

文脈が他に必要としない限り、以下の明細書および特許請求の範囲を通して、「含む」という単語、ならびに「含む」および「含んでいる」などその変形は、オープンで包括的な意味で、すなわち「含むが、それらに限定されない」と解釈されるものとする。

本明細書で使用されるとき、「実質的に」、「約」、および「およそ」など、程度の用語は、最終結果が大幅に変更されないような修正された用語の妥当な量の偏差を意味することに留意されたい。これらの程度の用語は、修正された用語の意味を否定しない場合、修正された用語の偏差を含むと解釈されるものとする。

本明細書を通して「1つの実施形態」または「一実施形態」への言及は、特定の特徴、構造、または特性が、1つもしくは複数の実施形態において任意の適切な方法で組み合わされる場合があることを意味する。

本明細書および添付の特許請求の範囲で使用されるように、単数形"a"、"an"、および"the"は、内容が明らかにそうでないことを示さない限り、複数の指示対象を含む。また、「または」という用語は、一般にその最も広い意味で使用されていること、すなわち、内容が明らかにそうでないことを示さない限り、「および/または」を意味することにも留意されたい。

本明細書で提供される開示の見出しおよび要約は、便宜上のものにすぎず、実施形態の範囲または意味を解釈するものではない。

本明細書で使用される「結合される」または「結合」という用語は、これらの用語が使用される文脈に応じて、いくつかの異なる意味を有する可能性がある。たとえば、結合される、または結合という用語は、要素またはデバイスがデータを別の要素またはデバイスに電気的に、光学的に、またはワイヤレスで送信し、別の要素またはデバイスからデータを受信することができることを示すために使用されてもよい。

同様に、本明細書および添付の特許請求の範囲を通して、「通信経路」、「通信結合」、および「通信可能に結合される」などの変形における「通信」という用語は、一般的に、情報を転送および/または交換するための任意の設計された配置を指すために使用される。例示的な通信経路は、限定はしないが、導電性経路(たとえば、導電性ワイヤ、導電性トレース)、磁気経路(たとえば、磁気媒体)、光経路(たとえば、光ファイバ)、電磁放射経路(たとえば、電波)、またはそれらの任意の組合せを含む。例示的な通信結合は、限定はしないが、電気結合、磁気結合、光結合、無線結合、またはそれらの任意の組合せを含む。

本明細書および添付の特許請求の範囲を通して、不定形の動詞形態がしばしば使用される。例は、限定はしないが、「検出すること」、「提供すること」、「伝送すること」、「通信すること」、「処理すること」、「ルーティングすること」などを含む。特定の文脈で必要とされない限り、そのような不定形の動詞形式は、「少なくとも検出すること」、「少なくとも提供すること」、「少なくとも伝送すること」など、オープンで包括的な意味で使用されている。

本明細書に記載されたシステムおよび方法の例示的な実施形態は、ハードウェアまたはソフトウェアの組合せとして実装されてもよい。いくつかの場合には、本明細書に記載された例示的な実施形態は、少なくとも部分的に、1つまたは複数のコンピュータプログラムを使用して、少なくとも1つの処理要素およびデータ記憶要素(揮発性メモリ、不揮発性メモリ、ストレージ要素、またはそれらの任意の組合せを含む)を含む1つまたは複数のプログラム可能デバイス上で実行することによって実装されてもよい。これらのデバイスは、デバイスの性質に応じて、少なくとも1つの入力デバイス(たとえば、キーボード、マウス、タッチスクリーンなど)、および少なくとも1つの出力デバイス(たとえば、ディスプレイ画面、プリンタ、ワイヤレス無線など)を有している場合もある。

機能的パラダイムまたはオブジェクト指向パラダイムを採用するものなど、高レベルのコンピュータプログラミング言語で書かれたソフトウェアまたはソフトウェアアプリケーションを介して実装される場合がある、本明細書に記載された実施形態のうちの1つの少なくとも一部を実装するために使用されるいくつかの要素がある場合があることにも留意されたい。したがって、プログラムコードは、Python、Java、C、C++、または任意の他の適切なプログラミング言語で記述されてもよく、オブジェクト指向プログラミングの当業者に知られているように、モジュールまたはクラスを含んでいてもよい。代替的に、またはそれに加えて、ソフトウェアを介して実装されるこれらの要素のうちのいくつかは、必要に応じて、アセンブリ言語、機械言語、またはファームウェアで記述されてもよい。どちらの場合でも、言語は、コンパイルされた言語または解釈された言語でもよい。

ソフトウェアアプリケーションは、たとえば組織によって社内で構築されおそらく、類似または多様なハードウェアで実行される相互接続されたモジュラーサブシステムのセット、サードパーティによってリモートで動作されるサービスとしてのソフトウェアアプリケーション、アウトソーシングされたインフラストラクチャにおいて実行されるサードパーティソフトウェアなど、カスタムハードウェアにおいて実行されるモノリシックソフトウェアアプリケーションとすることができる。いくつかの場合には、ソフトウェアアプリケーションもあまり形式的ではない、または、組織のニーズに合わせて計算を実行するように変更されたプログラム可能なスプレッドシートドキュメントなど、その場限りの方法で構築される可能性がある。

ソフトウェアアプリケーションは、それらが動作するコンピューティングデバイスに展開され、インストールされてもよい。コンピューティングデバイスのオペレーティングシステムおよび/またはプラットフォームの性質に応じて、アプリケーションは、コンピューティングデバイスに直接展開されてもよく、および/またはアプリケーションは、アプリケーション市場からダウンロードされてもよい。たとえば、ユーザデバイスのユーザは、Apple App Store(商標)またはGoogle(商標) Play(商標)などのアプリストアを介してアプリケーションをダウンロードしてもよい。

これらのソフトウェアプログラムの少なくとも一部は、記憶媒体(たとえば、限定はしないが、ROM、EEPROM、磁気ディスク、光ディスクなどのコンピュータ可読媒体)、または汎用もしくは専用のプログラム可能デバイスによって読取り可能なデバイスに記憶されてもよい。ソフトウェアプログラムコードは、プログラム可能デバイスによって読み取られると、本明細書に記載された方法の少なくとも1つを実行するために、新しい特定のあらかじめ定義された方法で動作するようにプログラム可能デバイスを構成する。

本明細書で使用される「プログラム」、「ソフトウェアプログラム」、「ソフトウェアアプリケーション」、「アプリケーション」、および「スマートコントラクト」という用語は、コンピュータ実行可能命令、特に不揮発性メモリなど、非一時的媒体に記憶され、コンピュータのプロセッサによって実行されるコンピュータ実行可能命令を指す。コンピュータプロセッサは、命令を実行するとき、それが結合されている様々な入力または出力デバイスのいずれかから入力を受信し、それに出力を伝送してもよい。ソフトウェアアプリケーションは、スマートフォンおよびタブレットまたは他の「スマート」デバイスなどのモバイルデバイスで使用するためのモバイルアプリケーションまたは「アプリ」を含んでいてもよい。

スマートコントラクトは、特定のタイプのソフトウェアプログラムである。一般に、スマートコントラクトは、ルールまたは条件のセットを適用または実施するようにプログラムされている。これらのルールまたは条件は、外部ソース(たとえば、Webサーバ、サードパーティデバイスなど)からのデータなどの外部要因に依存してもよい。たとえば、少なくとも一部のスマートコントラクトでは、スマートコントラクトに、少なくとも1つのサブルーチンを実行させるように、プログラムコードが入力メッセージによってトリガされてもよい。少なくとも1つのサブルーチンは、たとえばサーバにクエリを行い、応答データを取得し、次いで、スマートコントラクトのプログラムコードに従って、さらに何らかのアクションを実行する(たとえば、スマートコントラクトのいくつかの条件を「実施する」)場合がある。

少なくともいくつかの実施形態では、スマートコントラクトは、イーサリアム財団によって開発されたイーサリアムブロックチェーンなどのブロックチェーンまたは分散型台帳システムを使用して実装されてもよい。しかしながら、いくつかの代替実施形態では、スマートコントラクトは、ブロックチェーンまたは分散型台帳システムなしで実装されてもよい。

イーサリアムブロックチェーンの動作は、複数の「アカウント」の一連の状態遷移としてモデル化することができる。したがって、イーサリアムブロックチェーンは、各ノードでEVMを実行することにより、すべてのアカウントの状態を追跡する。イーサリアムブロックチェーンの状態遷移は、アカウントによって、および/またはアカウント間での情報の転送と見なすことができる。アカウントには主に、秘密暗号キーによって制御される外部所有アカウント(EOA)、および、スマートコントラクトコードによって制御される契約アカウントの2つのタイプがあり、EOAによって、より詳細には、契約アカウントにアクティブ化させ、動作を実行させるトランザクションが発生したとき、「アクティブ化」または「トリガ」される場合がある。両方のタイプのアカウントは、16進数の文字列(たとえば、0xbfb2e296d9cf3e593a79981235aed29aa9984c0fなど)として表されてもよいアドレスが関連付けられている。

「スマートコントラクト」という用語は、契約アカウント内のコードを指すことができ、トランザクションがそのアカウントに送信されたときに実行されるプログラムである。ユーザは、コードをブロックチェーンに展開することによって、新しい契約を作成することができる。各スマートコントラクトは、一般に少なくとも1つの契約アカウント、したがって少なくとも1つの一意のアドレスを有する。一般に、スマートコントラクトのコンピュータプログラムコードは、時間をかけて継続的に実行するのではなく、外部トリガまたはアクティブ化(たとえば、クエリ、更新、または基になるブロックチェーン上の他のトランザクションなど)に応答して、離散間隔で実行される。

実施形態は、イーサリアムブロックチェーンを参照して本明細書に記載されているが、記載された実施形態は、他のブロックチェーンまたは分散型台帳システムを使用して実装されてもよい。いくつかの場合には、記載された実施形態は、集中型アプローチを使用して実装されてもよい。

説明は、ブロック図、概略図、および例の使用を介して、システム、デバイス、および/またはプロセスの様々な実施形態を説明する。そのようなブロック図、概略図、および例が1つまたは複数の機能および/または動作を含む限り、そのようなブロック図、概略図、または例内の各機能および/または動作を、広範囲のハードウェア、ソフトウェア、ファームウェア、または実質的にそれらの任意の組合せによって、個々におよび/または集合的に実装することができることが当業者には理解されよう。しかしながら、当業者は、本明細書に開示される実施形態は、全体的にまたは部分的に、1つまたは複数のコンピュータによって実行される1つまたは複数のコンピュータプログラムとして(たとえば、1つまたは複数のコンピュータシステム上で動作する1つまたは複数のプログラムとして)、1つまたは複数のコントローラ(たとえば、マイクロコントローラ)によって実行される1つまたは複数のプログラムとして、1つまたは複数のプロセッサ(たとえば、マイクロプロセッサ、中央処理ユニット、グラフィカル処理ユニット)によって実行される1つまたは複数のプログラムとして、ファームウェアとして、または実質的にそれらの任意の組合せとして、標準集積回路に同等に実装できること、ならびに、回路を設計すること、および/またはソフトウェアおよび/またはファームウェアのコードを書くことは、本開示の教示に照らして、当業者の技術の十分範囲内であることを認識されよう。

ロジックがソフトウェアとして実装され、メモリに記憶されるとき、ロジックまたは情報は、任意のプロセッサ関連のシステムまたは方法によって、またはそれらに関連して使用するために、任意のプロセッサ可読媒体上に記憶することができる。本開示の文脈において、メモリは、電子的、磁気的、光学的、または、コンピュータおよび/もしくはプロセッサプログラムを含むもしくは記憶する他の物理的デバイスもしくは手段であるプロセッサ可読媒体である。ロジックおよび/または情報は、コンピュータベースのシステム、プロセッサを含むシステム、または命令実行システム、装置、またはデバイスから命令をフェッチし、ロジックおよび/または情報に関連付けられた命令を実行することができる他のシステムなど、命令実行システム、装置、またはデバイスによって、またはこれらに関連して使用するために、任意のプロセッサ可読媒体に組み込むことができる。

本明細書の文脈において、「非一時的コンピュータ可読媒体」は、命令実行システム、装置、および/またはデバイスによって、またはそれらに関連して使用するためのロジックおよび/または情報に関連付けられたプログラムを記憶することができる任意の要素とすることができる。プロセッサ可読媒体は、たとえば限定はしないが、電子、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、またはデバイスとすることができる。コンピュータ可読媒体のより具体的な例(非網羅的リスト)は、ポータブルコンピュータディスケット(磁気、コンパクトフラッシュ(登録商標)カード、セキュアデジタルなど)、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、消去可能プログラム可能読取り専用メモリ(EPROM、EEPROM、またはフラッシュメモリ)、ポータブルコンパクトディスク読取り専用メモリ(CDROM)、デジタルテープ、および他の非一時的媒体を含む。

ビットコイン(BTC)およびイーサ(ETH)など、普及しているデジタル資産は、日常の通貨として使用するには値動きが荒すぎる。多くの場合、BTCの値は大きな変動を経験し、1日で25%程度上昇または下降し、1か月で300%を超えて上昇をすることもある。

Dai Stablecoin("Dai")は、担保資産ありの暗号通貨であり、その値は、米国ドルなど、所定のフィアット通貨に対して安定するように設計されている。Dai Stablecoinは、Maker DAO、または単に"Maker"と呼ばれる分散型自律組織(DAO)によって運営および管理されている。

Makerは、担保付き負債ポジション(CDP)、自律フィードバックメカニズム、および外部アクターへのインセンティブの動的システムを介して、フィアット通貨に関連するDaiの価値を裏付けし、安定させる、イーサリアムブロックチェーン上のスマートコントラクトプラットフォームを提供する。

Makerは、誰でも自分のイーサリアム資産を活用してMakerプラットフォーム上でDaiを生成することを可能にする。一旦生成されると、Daiは、他の暗号通貨と同じように使用することができ、他に自由に送信したり、商品およびサービスの支払いに使用したり、長期的な貯蓄として保持したりすることができる。Daiの生成は、堅牢な分散型貸出プラットフォームに必要な構成要素も作成する。ユーザは、ブローカーまたは取引所から購入することによって、Daiを取得することもできる。

Daiの保有者は、Dai貯蓄メカニズムを利用して、Dai貯蓄率に基づいて、保有物の安定した低リスクのリターンを獲得することができる。

担保資産を有する人は誰でも、それらを活用して、Makerの担保付き負債ポジションを使用してDaiを生成することができる。一般に、担保資産は、分散型Makerガバナンスプロセスが認識してシステムに入力したデジタル資産である。たとえば、イーサ暗号通貨(ETH)は、担保資産として認識される場合があるデジタル資産の1つの形式である。

CDPは、ユーザによって預け入れられた担保資産を保持し、ユーザが担保資産の制御と引き換えにDaiを生成することを許可するスマートコントラクトである。しかしながら、Daiを生成すると、負債も発生する。この負債は、未収利息とともに、相当額のDaiをCDPスマートコントラクトに転送することによって後でカバーされるまで、CDPスマートコントラクト内の預けられた担保資産を効果的にロックし、その時点で、担保資産を引き出すことができる。ポリシーとして、アクティブなCDPは超過担保であり、これは担保の価値が負債の価値よりも高いことを意味する。

Makerプラットフォームでは、CDPの担保の価値が総負債(たとえば、借入額+未収利息)を下回った場合、CDPを清算し、終了することができる。

Makerプラットフォームにおいて、Daiの保有者は、本質的に、そのロックされたDaiを介してCDPユーザによって生成された負債に流動性を提供する役割を果たすので、CDPユーザへの間接的な貸し手と見なすことができる。この点から見て、いかなるパーティ間でいかなる直接の貸し借りも行う必要はないが、Dai保有者は「貸し手」と呼ばれ、CDPユーザは「借り手」と呼ばれる場合がある。すなわち、「貸出」および「借入」は、Dai貯蓄およびCDPスマートコントラクトの異なるメカニズムを介して間接的であってもよい。

次に図6を参照すると、CDPスマートコントラクトの例示的なライフサイクルのプロセスフロー図が示される。本明細書に記載されたように、プロセスフロー図は、EVMで実行されるとき、イーサリアムブロックチェーンなどのブロックチェーンのノードによって実行される場合がある。

604で、CDPは、Makerへのトランザクションによってインスタンス化されてもよく、608で、担保預金は、たとえばETH暗号通貨の形式で、CDPスマートコントラクトによって受信される場合がある。この点で、CDPは、担保付きと見なされる場合がある。

612で、CDPは、608での担保預金の決定された価値に基づいて、ある金額のDai暗号通貨を生成する。

616で、CDPは、ユーザからの引き出しトランザクションを受信する。引き出しトランザクションは、CDPからの引き出しを希望するDaiの金額を示す。次いで、CDPスマートコントラクトは、Daiが引き出し可能であるかどうかを判断し、引き出し可能である場合、引き出しを承認する。CDPスマートコントラクトは、内部負債残高も更新し、これを使用して、内部負債残高がゼロに低減されるまで、スマートコントラクトに、担保資産全体の引き出しを防止することができる。しかしながら、いくつかの実施形態では、担保資産の部分的な引き出しは、支払われた総負債の比率に従ってスマートコントラクトによって許可されてもよい。

620で、CDPは、ユーザから返済トランザクションを受信する。返済トランザクションは、CDPスマートコントラクトにDaiの金額を転送する。624で、CDPスマートコントラクトは、負債が未払いであった時間量に基づいて、安定手数料とも呼ばれる料金を計算し、これを内部負債残高に追加する。他の時に、料金が計算される場合もある。

628で、CDPは、発生した任意の料金を含め、内部負債残高の任意の部分の返済を受信したかどうかを判断する。支払いが受信された場合、CDPは、632で、担保資産の対応する部分の引き出しを許可する場合がある。たとえば、負債残高(および関連の料金)の40%の返済が受信された場合、担保資産の最大40%まで、分割可能な場合、引き出しが許可されてもよい。636で、CDPは、担保資産が含まれていない場合(たとえば、すべての返済が行われ、担保資産が引き出された場合)、クローズされてもよい。

方法600の行為は、別個の行為として示されるが、いくつかの実施形態では、少なくともいくつかの行為は、組み合わされてもよく、またはさらに細分化されてもよい。たとえば、いくつかの実施形態では、Dai暗号通貨を生成する行為(612)が引き出しの行為(616)と結合されて、単一の結合される行為であってもよい。

市場ダイナミクスの変化により、Daiの市場価格が短期的に目標価格から逸脱するとき、Makerは、Dai貯蓄率を変更することによって、この価格の不安定性を緩和することができる。Dai貯蓄率は、グローバルなシステムパラメータであり、Dai保有者が時間の経過とともに保有物からどれだけのリターンを獲得することができるか、およびCDPからDaiを生成するための基本借入コストの両方に影響する。

たとえば、Daiの市場価格が目標価格(1米ドルなど)を下回る場合、Dai貯蓄率が上昇する場合がある。これによって、より多くのDai保有者、およびより少ないCDPユーザにインセンティブが与えられることによって、需要が高まり、供給が抑えられ、これによって、市場価格が1米ドルの目標価格に向けて上昇すると予想される。

逆に、Daiの市場価格が1米ドルを超える場合、Dai貯蓄率は低下する場合がある。これによって、需要が抑制され、供給が増加し、これによって、Daiの市場価格が1米ドルの目標価格に向けて下がると予想される。

これら2つのメカニズムは共に、目標価格に向けてDaiの価値を調整するのに役立つ。

Makerプラットフォームはまた、利息を支払う貯蓄システムを提供する。Dai暗号通貨を保有している人は、いつでもDai貯蓄メカニズムを使用してDaiをロックしてもよく、いつでもDaiをアンロックしてもよい。Dai貯蓄メカニズムを使用してロックされると、Daiは、Dai貯蓄率(DSR)と呼ばれるグローバルシステム変数に基づいて、時間の経過とともに発生する。トランザクションのロックおよびアンロックに必要なイーサリアム「ガス」以外に、Dai貯蓄メカニズムを使用するための制限または料金はない。

たとえば、DSRが平均2%のままである場合、100DaiをDSRモード内にロックし、それを通年にわたってロックし続けるユーザは、アカウントに自動的に追加される2Daiを獲得することになる。未払い額は、たとえばDaiがアンロックされたときに追加されてもよく、または、いくつかの場合には、定期的な間隔で(たとえば、クエリ、更新、または他のトランザクションに応答して)追加されてもよい。

DSRは、CDPスマートコントラクトで支払われた安定手数料から資金提供される。たとえば、CDPで収集された平均安定手数料が3%である場合、そのような料金は、2%のDSRに資金提供するために使用されてもよい。

DSRは、Daiの供給と需要のバランスをとるのを助け、分散されたMakerガバナンスが制御することができる金融政策のレバーのうちの1つである。述べたように、DSRは、Dai経済の市場状況の短期的な変化に対処するために頻繁に調整される場合があるグローバルパラメータである。これは、担保の種類ごとに、安定手数料および他のリスクパラメータを個々に設定することを伴う長期的なプロセスであるリスクガバナンスとは対照的である。

様々な実施形態が、イーサリアムブロックチェーン、Makerプラットフォーム、およびDai暗号通貨を参照して本明細書に記載されているが、記載された方法およびシステムは、他の状況、たとえば異なるブロックチェーンシステムに、異なる暗号通貨で、またはいくつかの場合には、集中型の非ブロックチェーンシステムに適用されてもよいことに再度留意されたい。

安定手数料とDai貯蓄率の両方は可変であり、時間の経過とともに変動する。しかしながら、ユーザは、Daiを借りるときと預金するときの両方で、所定のレートを有することを望む場合がある。

記載された実施形態は、継続的な金利先渡契約を介して資産(たとえば、Daiまたは他の暗号通貨)の借り手および預金者に所定の金利を提供するためのシステムおよび方法に関連してもよい。

記載されたアプローチの一態様では、借り手であるユーザは、借りたDaiよりも価値の高い担保(たとえば、ETH暗号通貨)と引き換えに、第1のスマートコントラクト(CDPスマートコントラクト)を使用してDaiを借りてもよい。借り手は、Daiを借りるために、安定手数料(すなわち、利息)を変動金利で支払う。安定手数料は、ガバナンス料金およびDai貯蓄率(DSR)に基づいており、どちらも時間の経過とともに変動する場合がある。

預金者である別のユーザは、Daiを保持してもよい。預金者は、保持されているDaiをロックし、その後、DSRに基づいて変動金利で利息を受け取ってもよい。

一態様では、記載されたシステムおよび方法は、継続的な金利先渡契約スマートコントラクト(または他のデジタル契約)を提供する。継続的な金利先渡契約は、一般に借り手と預金者との間に所定の金利または固定金利(または、連邦資金レートやロンドン銀行間オファーレート(LIBOR)など、DSR以外の何らかの外部メトリックに関連付けられたレート)を設定する。現在のDSRが所定の金利を下回った場合、借り手は、両パーティの金利が所定の金利に留まるように、預金者にその低い借入コストとの差額を支払うように要求される場合がある。しかしながら、DSRおよび安定手数料は相関関係があるので、預金者が支払う安定手数料も減少する場合がある。同様に、現在のDSRが所定の金利を上回った場合、預金者は、借り手に増加した利息利益との差額を支払うよう要求される場合がある(そして安定手数料が増加する)。それに応じて、DSRと安定手数料との間の相関関係により、両方のパーティが所定の金利を取得することができる。

少なくともいくつかの実施形態では、継続的な金利先渡契約は、借り手が仲介ユーザを介して開始してもよく、担保資産のリスク分析および提案されたCFRAの他の態様に基づいてCFRAの価格を設定してもよい。仲介者は、借り手からCFRAを購入し、預金者にCFRAを販売してもよい。

いくつかの実施形態では、システムは、複数の形態のエスクローを含むことができる。特に、第1の集中保管は、CFRA契約における借り手および預金者のポジションを表すトークンを保持する場合がある。第2の保管(集中型または分散型)は、CFRA契約の担保として、借り手からのCDPの制御、および預金者からのDaiの制御を保持してもよい。

いくつかの実施形態では、借り手および預金者は、それぞれのCFRAポジション(すなわち、それぞれのポジションを表すトークン)を、後続の借り手または後続の預金者にそれぞれ販売してもよい。次いで、最初のパーティは、第2の保管から担保の一部を戻されて受信することができ、これは後続のパーティによって補充される(たとえば、追加の担保が必要とされる場合)。次いで、第1の保管でのトークンは、パーティの新しいポジションを反映するように更新される。

一般に、スマートコントラクトは、契約が終了する場合がある一定の期間を有する。いくつかの状況では、パーティの合意などの1つまたは複数の要因に基づいて、CFRA契約の期間を延長するためのメカニズムが提供される場合がある。しかしながら、スマートコントラクトは、いくつかの他の状況でも終了する場合がある(たとえば、CDPの値が、借り手が預金者に借りている値を下回った場合)。スマートコントラクトが終了すると、各パーティのポジションは、各パーティに支払われるべき金額を支払うことによって解決される。借り手または預金者がCFRAポジションを後続の借り手または後続の預金者に売却した場合、これは複数のパーティが関与してもよい。

預金者は、一般にCFRA契約の担保がそのリスク許容範囲内であることの保証を望む場合がある。したがって、仲介ユーザは、担保の評価およびCFRA契約の価格設定を求められる場合がある。仲介ユーザはまた、いくつかの場合には、担保が、その契約期間中に、CFRA契約の清算価格(最低担保比率)を下回る可能性があるかどうか、および担保を清算できるかどうかを判定してもよい。一般に、仲介者は、貸し手のユーザエクスペリエンスを向上させるためにインセンティブを与えられる場合がある。次いで、利息が時間とともに発生するというこの原則も、借り手は、担保が清算された場合に利息を支払うことを望まないので、借り手のユーザエクスペリエンスを向上させる。

仲介ユーザは、CFRA契約が実行されるたびに、または規定のマイルストーン(たとえば、CFRA契約の終了)で補償を受けてもよい。

記載されたシステムおよび方法は、CDP契約の制御をトークン化することができ、制御または所有権利息を表すトークンをCFRA契約の担保として使用することができるので、CDP契約の制御または所有権によってCFRA契約が担保されることを提供する。いくつかの実施形態では、CDP契約自体がトークン化されてもよい。他の実施形態では、別個のスマートコントラクトを使用して、CDP契約を「ラップ」し、CDP契約の制御または利益を表すトークンを生成してもよい。そのような方法で、サードパーティは、CDP契約の制御または利益を表すトークンを受信することによって、担保オブジェクト(CDP契約など)を制御することができる。

記載されたシステムおよび方法のいくつかは、スマートコントラクトによって管理されるトークンの使用を伴い、したがってそのようなトークンは、とりわけ、作成、転送、細分化、乗算、破棄などを行われることができる。これらの機能は、スマートコントラクト(各々それぞれの契約アカウントを有する)の実行に従って、ブロックチェーンシステムのノードによって自律的に実行することができ、したがって人間の管理者の介入は不要である。さらに、そのようなトークンの出所および使用は、外部所有アカウントと契約アカウントの両方によって暗号で保護され、記録することができ、これによって、トークン自体と、そのようなトークンを伴うトランザクションの両方で、セキュリティ、信頼性、および信用性が向上する。この意味で、記載されたトークンは、少なくともいくつかの実施形態がブロックチェーンまたは分散型台帳技術のいくつかの固有の側面を適用または使用して、記載されたトランザクションのセキュリティ、信頼性、および信用性を高める方法の一例にすぎない。

別の例では、契約アカウントによって制御されるスマートコントラクトの使用によって、スマートコントラクトの機能が人間によって実行された場合に達成できない方法で、記載されたトランザクションのセキュリティ、信頼性、および信用性が向上する。特に、契約アカウントは、安全かつ自律的に動作するように設計することができるので、人間のオペレータが同じ機能を実行していた場合には不可能であろう方法で実行するリスク管理機能の信頼を向上させることができる。人間のエージェントとは異なり、契約アカウントは、本質的に、モラルハザードの影響を受けず、したがってエスクローエージェントとして使用することができる。したがって、その関連するスマートコントラクトによって、契約アカウントが暗号で署名されたトランザクションによって資産の制御を受信すると、すべてのパーティは、スマートコントラクトの合意されたルールが守られ、スマートコントラクト自体による詐欺は、完全に不可能ではないにしても、起こりそうにないという確信を高めることができる。したがって、これによって、カウンターパーティのリスクが軽減される。

別の態様では、少量で取引する多くのユーザの活動がシステム全体を強化するのに役立つので、記載された実施形態の分散の性質は、システムの信用性を高めることができる。設計上、個々の清算は、他のユーザに悪影響を及ぼさない。

いくつかの実施形態では、ステーブルコイン(たとえば、DAI)以外の資産は、仲介ユーザによって担保として使用され、担保オブジェクトに配置されてもよい。たとえば、外部または内部の金利に関連付けられている資産は、担保として使用されてもよい。

いくつかの実施形態では、借り手ユーザは、何らかのカウンターパーティリスクを引き受け、仲介ユーザが複数のCFRA契約に同じ担保オブジェクトを使用できるようにしてもよい。しかしながら、一部の担保の存在によって、パーティは、低レベルのリスクで契約を締結できる場合がある。

借り手、貸し手、またはその両方のエクスペリエンスを向上させることを目的とする、様々な異なる仲介ユーザが存在し得る。述べたように、記載された実施形態は、CFRA契約におけるポジション(借り手、預金者、または仲介者いずれでも)が、そのポジションを表すトークンの転送によって転送されることを可能にする。

次に、図1を参照すると、少なくともいくつかの実施形態による例示的なシステムの概略ブロック図が提供されている。システム100は、ネットワーク110、ネットワーク110を介して通信する1つまたは複数のノードデバイス120、借り手デバイス130a、および貸し手デバイス140aを有する。オプションで、システム100は、1つまたは複数の追加の借り手デバイス130bおよび1つまたは複数の貸し手デバイス140bを有していてもよい。少なくともいくつかの実施形態では、システム100は、少なくとも1つの仲介デバイス160を有する。少なくともいくつかの実施形態では、システム100は、少なくとも1つの外部サーバ150を有する。

ネットワーク110は、インターネットなどのデータ通信ネットワークであり、イーサネットなどの1つまたは複数のプロトコルおよびインターフェースを介してネットワーク110の要素間のデータ通信を可能にする。いくつかの場合には、ネットワーク110の1つまたは複数の要素間の様々なデータ通信は、仮想プライベートネットワークを介して暗号化またはトンネルされてもよい。いくつかの場合には、ネットワーク110は、プライベートネットワーク、またはパブリックネットワークとプライベートネットワークの組合せであってもよい。

ノード120は、ネットワーク110とデータ通信するコンピューティングデバイスである。少なくともいくつかの実施形態では、各ノード120は、ブロックチェーンノードソフトウェアアプリケーションを実行することによって、ブロックチェーンノードとして機能するように構成される。たとえば、ノード120は、イーサリアムブロックチェーンノードであってもよく、イーサリアム仮想マシンを実行し、イーサリアムブロックチェーンピアツーピアネットワークに参加するように構成されてもよい。しかしながら、いくつかの代替実施形態では、1つまたは複数のノード120は、集中型システムへのゲートウェイとして機能する従来のサーバコンピュータであってもよい。

各借り手デバイス130aおよび130b、ならびに貸し手デバイス140aおよび140bは、パーソナルコンピュータ、サーバコンピュータ、タブレットコンピュータ、スマートフォンまたは他のコンピューティングデバイスなどのコンピューティングデバイスである。ブロックチェーンシステムを採用する実施形態では、借り手デバイスおよび貸し手デバイスは、ブロックチェーンシステムのノード120に接続して、トランザクションおよび他のアクションを開始し、本明細書でさらに説明するように、それらのトランザクションの結果(たとえば、現在の状態)の通知を受信してもよい。

借り手および貸し手デバイスは、例示の目的でノード120に接続するものとして示されるが、借り手および貸し手デバイスの各々は、ネットワーク110の他の要素に接続し、それらのデータ通信をノード120との間でルーティングしてもよい。

外部サーバ150は、ブロックチェーンシステムに参加してもしなくてもよいサーバコンピュータである。しかしながら、外部サーバ150は、何らかの問合せへの応答について他のデバイスによってクエリが行われてもよい。たとえば、いくつかの実施形態では、外部サーバ150は、一般的な金利など、特定のデータについての合意された「オラクル」として機能してもよい。

仲介デバイス160は、本明細書でさらに説明するように、仲介エンティティ、保管エンティティ、またはその両方によって動作されてもよい、パーソナルコンピュータ、サーバコンピュータ、タブレットコンピュータ、スマートフォン、または他のコンピューティングデバイスなどの少なくとも1つのコンピューティングデバイスである。

デバイス130a、130b、140a、140b、150、および160の各々は、有線または無線接続を介してネットワーク110に結合してもよい。説明を不明瞭にしないように、少数のコンピューティングデバイスのみが示されるが、いくつかの実施形態では、多数のコンピューティングデバイス、特に借り手および貸し手デバイスがあってもよい。

次に、図2を参照すると、少なくともいくつかの実施形態によるコンピューティングデバイスの簡略化された概略ブロック図が提供されている。コンピューティングデバイス200は、例示的なコンピューティングデバイスであり、借り手デバイス130a、130b、貸し手デバイス140a、140b、ノード120、外部サーバ150、および仲介デバイス160など様々なコンピューティングデバイスの構成要素を示す。

コンピューティングデバイス200は、少なくともプロセッサ204、メモリ208、ならびに少なくとも1つの入力および/または出力デバイス212を有し、これらの各々は、システムバス220に接続されてもよい。いくつかの場合には、プロセッサ204は、システムバス220をバイパスして、メモリ208または入力/出力デバイス212と直接通信するように構成されてもよい。コンピューティングデバイス200は、パーソナルコンピュータ、サーバコンピュータ、タブレットコンピュータ、スマートフォン、他のコンピューティングデバイス、またはこれらの任意の組合せであってもよい。

いくつかの実施形態では、プロセッサ204、入力/出力デバイス212、およびメモリ208の各々は、より少ない数の構成要素に組み合わされてもよく、またはさらなる構成要素に分離されてもよいことを理解されよう。

プロセッサ204は、システム100の構成、目的、および要件に応じて十分な処理能力を提供することができる任意の適切なプロセッサ、コントローラ、またはデジタル信号プロセッサであってもよい。いくつかの実施形態では、プロセッサ204は、複数のプロセッサを含むことができ、各プロセッサは、異なる専用タスクを実行するように構成される。

入力/出力デバイス212は、コンピューティングデバイス200が入力を受信する、または出力を伝送することを可能にする任意のインターフェースデバイスであってもよい。たとえば、入力/出力デバイス212は、シリアルポート、パラレルポート、またはユニバーサルシリアルバス(USB)ポートのうちの少なくとも1つであり得る。入力/出力デバイス212はまた、インターネット、ローカルエリアネットワーク(LAN)、イーサネット、ファイアワイヤ、モデム、またはデジタル加入者線接続のうちの少なくとも1つであってもよい。これらの要素の様々な組合せが、入力/出力デバイス212内に組み込まれてもよい。

たとえば、入力/出力デバイス212は、コンピューティングデバイス200の要件および実装に応じて、マウス、キーボード、タッチスクリーン、サムホイール、トラックパッド、トラックボール、カードリーダー、音声認識ソフトウェアなどの様々な入力デバイスから入力を受信してもよい。同様に、入力/出力デバイス212は、たとえばディスプレイ、プリンタ、または他の出力デバイスの形で出力を伝送してもよい。

メモリ208は、RAM、ROM、1つもしくは複数のハードドライブ、1つもしくは複数のフラッシュドライブ、またはディスクドライブなどいくつかの他の適切なデータ記憶要素を含むことができる。メモリ208は、オペレーティングシステムおよびソフトウェアアプリケーションを記憶するために使用することができる。たとえば、オペレーティングシステムは、様々な基本的な動作プロセスを提供することができる。プログラムは、ユーザが入力/出力デバイス212と対話して、限定はしないが、コンピューティングデバイス200によって生成された通知の閲覧および/または応答など様々な機能を実行することができるように、様々なユーザプログラムを含むことができる。ユーザプログラムは、たとえばブロックチェーンノードソフトウェアまたはクライアントソフトウェアを含むこともできる。

次に、図3A〜図3Cを参照すると、少なくともいくつかの実施形態による、トランザクションを行う方法が示される。方法300は、スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うための方法であり、たとえば図1のシステム100の1つまたは複数のノード120によって実行されてもよい。

方法300は、図3Aの304で始まり、第1のスマートコントラクトを識別する。少なくともいくつかの実施形態では、第1のスマートコントラクトは、CDPスマートコントラクトであり、また、CDP契約またはローン契約と呼ばれることもある。説明したように、第1のスマートコントラクトは、一般に第1のアドレス(たとえば、その契約アカウントのアドレス)およびそれに関連付けられた第1の借り手アドレス(たとえば、借り手デバイスを介して第1のスマートコントラクトを開始したユーザに属するアドレス)を有する。第1のスマートコントラクトは、一般に第1の借り手アドレスに転送された暗号通貨の金額に最初に基づく未払金額値(たとえば、CDPから受信された暗号通貨の初期値など)、および第1の借り手アドレスに関連付けられたスマートコントラクトにコミットされた担保オブジェクトの値を表す担保価値など、1つまたは複数のパラメータを有する。第1のスマートコントラクトは、外部金利に少なくとも基づいて、第1の変動金利を定期的に決定するように構成された金利クエリサブルーチンを有していてもよい。少なくともいくつかの実施形態では、暗号通貨は、Daiおよび/またはイーサ(ETH)など他の暗号通貨であってもよい。少なくともいくつかの実施形態では、トークンは、不動産の権利、担保権、または他の権利、またはその両方を表す。外部金利は、システム100の外部サーバなど、1つまたは複数のソースからクエリされる場合があるDai貯蓄率であってもよい。第1の変動金利は、外部金利に基づいて決定されてもよい。

いくつかの変形実施形態では、外部金利の代わりに内部金利が使用されてもよい。内部金利は、債務対象がインスタンス化されるときに、または債務対象のサブルーチンによって指定されてもよい。

308で、第1のスマートコントラクトに関連付けられた少なくとも1つのローントークンが識別される。いくつかの実施形態では、第1のスマートコントラクトは、トークン化され、CDPスマートコントラクトの制御および担保オブジェクトへの関心を表すそれ自体の譲渡可能なトークンを生成する。しかしながら、他のいくつかの実施形態では、第1のスマートコントラクトは、ネイティブにトークン化されなくてもよく、その場合、第1のスマートコントラクトをラップし、「トークン化」するトークン化スマートコントラクトが使用されてもよい。トークン化スマートコントラクトは、CDPスマートコントラクトの制御を引き受け、CDPスマートコントラクトの制御および担保オブジェクトへの関心を表す1つまたは複数の譲渡可能なトークンを生成するために、いくつかの場合には、サードパーティによって提供されてもよい。

312で、第2のスマートコントラクトが識別される。第2のスマートコントラクトは、預金スマートコントラクトまたは預金契約と呼ばれる場合がある。第2のスマートコントラクトは、一般に第2のアドレス(たとえば、その契約アカウントのアドレス)およびそれに関連付けられた第1の貸し手アドレス(たとえば、貸し手デバイスを備えた暗号通貨から利益を獲得しようとするユーザに属するアドレス)を有する。第2のスマートコントラクトは一般に、第1の貸し手アドレスに関連付けられており貸し手が所有し、貸与、預金またはロックすることを希望する暗号通貨の貸出量を表す所有金額値または貸し手残高など、1つまたは複数のパラメータを有する。少なくともいくつかの実施形態では、第2のスマートコントラクトは、また、少なくとも外部金利に基づいて第2の変動金利を定期的に決定するように構成された第2の金利クエリルーチンを有していてもよい。第1のスマートコントラクトと同様に、外部金利は、システム100の外部サーバなど、1つまたは複数のソースからクエリされる場合があるDai貯蓄率であってもよい。第2の変動金利も、外部金利に基づいて決定されてもよい。

いくつかの実施形態では、第2のスマートコントラクトは、ユーザの暗号通貨の一部(たとえば、所有金額値または貸し手残高)が暗号通貨発行メカニズム(それ自体が1つまたは複数のスマートコントラクトであってもよい)によって単にロックされるロックメカニズムであってもよい。ロックされた部分は、ロックされている間、利息が発生する場合があり、その部分がアンロックされたとき、または別のクエリ、更新、または他のトランザクションに応答して支払われてもよい。

316で、債務対象が生成される。少なくともいくつかの実施形態では、債務対象は、実行時に継続的な金利先渡契約を実行するように構成されたさらなるスマートコントラクトであり、スマートコントラクトとして、債務対象アドレスを有する。したがって、債務対象は、CFRAスマートコントラクトまたはスワップ契約と呼ばれることがある。債務対象の生成は、本明細書でさらに説明するように、行為320〜348をさらに含む。しかしながら、いくつかの代替実施形態では、債務対象は、ブロックチェーンベースのスマートコントラクトではないが、プログラム契約であってもよい。

説明を簡単にするために、債務対象は、本明細書に記載された行為を実行するものとして説明されるが、記載された実施形態の少なくともいくつかにおいて、各債務対象は、記載された行為を実行するために(たとえば、分散型台帳システムの1つまたは複数のノードの)プロセッサによって実行可能なソフトウェアコード(たとえば、スマートコントラクト)であることが繰り返される。

いくつかの代替実施形態では、第1または第2のスマートコントラクト、またはその両方を省略することができ、必要に応じて、316で生成された債務対象は、第1および第2のスマートコントラクトと置き換えるように構成されてもよい。そのような実施形態では、行為304、308、および312は省略されてもよく、債務対象は、CDPスマートコントラクト、預金契約、またはその両方の機能を実行するように構成することができる。

本明細書でさらに説明するように、債務対象は、借り手残高、貸し手残高、期間、および所定の金利などのパラメータも有する。

320で、債務対象は、たとえば少なくとも1つのローントークンがトランザクションを介して債務対象アドレスに転送されることによって、少なくとも1つのローントークンの制御を受信する。

324で、債務対象は、少なくとも1つのローントークンに関連付けられた担保価値に基づいて、債務対象の借り手残高を生成または更新する。担保価値は、たとえば少なくとも1つのローントークンに関連付けられた第1のスマートコントラクトのクエリを行うことによって確認されてもよい。

328で、債務対象は、貸し手金額の制御を受信する。貸し手金額は、暗号通貨(たとえば、Dai)であってもよく、貸し手ユーザは、金利額と引き換えに、債務対象への貸与、預金、またはコミットを希望する。いくつかの場合には、貸し手金額は、別の暗号通貨への関心を表すトークンであり、その関心はスマートコントラクトの形であってもよい。

332で、債務対象は、328で受信した貸し手金額に基づいて、債務対象の貸し手残高を生成または更新する。

336で、債務対象は、少なくとも1つの貸し手トークンおよび少なくとも1つの借り手トークンをそれぞれ生成することによって、貸し手残高および借り手残高をトークン化する。いくつかの場合には、複数の貸し手トークンまたは複数の借り手トークン、あるいはその両方が生成されてもよい。いくつかの貸し手または借り手トークンが後の段階でも生成されてもよい。いくつかの場合には、トークンは、ユーザによって細分化されてもよい。少なくとも1つの貸し手トークンを生成することは、債務対象に関連付けられた各貸し手のポジションを追跡するために貸し手台帳を生成することを伴ってもよい。同様に、少なくとも1つの借り手トークンを生成することは、債務対象に関連付けられた各借り手のポジションを追跡するために借り手台帳を生成することを伴ってもよい。

いくつかの代替実施形態では、少なくとも1つの貸し手トークン、少なくとも1つの借り手トークン、またはその両方の生成が省略されてもよい。代わりに、債務対象は、貸し手、借り手、またはその両方に関連付けられた1つまたは複数のアドレスを記録してもよい。各アドレスは、場合によっては、それぞれの貸し手残高または借り手残高を表す、それに関連付けられた対応する値を有していてもよい。1つまたは複数のアドレスは、この目的で使用される少なくとも1つの台帳に記録されてもよく、アドレスおよび値は、その後、時間の経過とともに更新されてもよい。

340で、たとえばトランザクションで少なくとも1つの貸し手トークンを第1の貸し手アドレスに転送することによって、少なくとも1つの貸し手トークンが第1の貸し手アドレスに関連付けられる。貸し手トークンが生成されない実施形態では、転送は、台帳に第1の貸し手アドレスを記録し、第1の貸し手アドレスに関連付けられた値を(たとえば、貸し手残高と等しくするために)更新することによって実行されてもよい。

344で、たとえばトランザクションで少なくとも1つの借り手トークンを第1の借り手アドレスに転送することによって、少なくとも1つの借り手トークンが第1の借り手アドレスに関連付けられる。借り手トークンが生成されない実施形態では、転送は、台帳に第1の借り手アドレスを記録し、第1の借り手アドレスに関連付けられた値を(たとえば、借り手残高と等しくするために)更新することによって実行されてもよい。

348で、債務対象は、1つまたは複数の所定の金利を決定する。いくつかの場合には、所定の金利は、貸し手と借り手の両方について同じになる場合がある。しかしながら、他の場合には、貸し手と借り手で所定の金利が異なる場合がある。たとえば、借り手には第1の所定の金利があり、貸し手には第2の所定の金利があってもよい。所定の金利は、たとえばLIBORなどの外部金利に基づいて自動的に、株式または合成株式の配当率に基づいて、または外部サーバ150などの外部サーバにクエリを行うことによって決定されてもよい。いくつかの場合には、クエリは、別のスマートコントラクトへのトランザクションであってもよい。代替的に、所定の金利は、それが使用される実施形態において内部金利に基づいて決定されてもよい。他の場合には、所定の金利は、債務対象が作成または資金提供されるときに、1人または複数のパーティによって提供されるパラメータである場合がある。少なくともいくつかの実施形態では、所定の金利は、債務対象の継続期間中固定されている。

方法300は、図3Bの方法350に示されるように、債務対象のトランザクションサブルーチンの実行を継続してもよい。トランザクションサブルーチンは、たとえばトランザクションを債務対象に送信するパーティによってトリガされ、システムの1つまたは複数のノードに、トランザクションサブルーチンを実行させてもよい。トランザクションは、資金移転トランザクション、クエリトランザクション、更新トランザクション、トリガトランザクション、または何らかの他のトランザクションであってもよい。

図3Bの354で、トランザクションが受信され、トランザクションサブルーチンが実行を開始する。

356で、債務対象は、たとえば外部サーバ150などの外部サーバまたはブロックチェーンノードにクエリを行うことによって、Dai貯蓄率または安定手数料(またはMaker以外のプラットフォームの同等物)などの外部金利が変化したかどうかを判定してもよい。いくつかの場合には、クエリは、別のスマートコントラクトへのトランザクションであってもよい。代替的に、内部金利は、それが使用される実施形態で決定されてもよい。

358で、債務対象は、トランザクションが、たとえば少なくとも1つの借り手トークンの保有者によって開始された資金移転トランザクションであるかどうかを判定する。はいの場合、借り手残高は、366で支払いに基づいて更新される。資金移転は、第1のスマートコントラクトの第1の変動金利に基づく、少なくとも1回の借り手利息払いとすることができる第1の支払いであってもよい。

370で、債務対象は、トリガイベントが発生したかどうかを判定する。トリガイベントは、たとえばトリガトランザクション(たとえば、クエリ)に応答して、借り手残高が担保価値を上回るとの判断に応答して、または債務対象の期間が満了したまたは経過したとの判断に応答して発生する場合がある。トリガイベントは、外部金利が変化したという決定の場合もある。

トリガイベントの検出に応答して、債務対象は、374でさらなる処理を実行し、図3Cの382に進み、図3Cの方法380に示されるようなさらなる処理を実行する。そうでなければ、債務は、さらなるトランザクションを待ってもよく、それから354に戻る場合がある。このようにして、債務対象は、複数回の支払いを定期的に監視し、処理してもよい。

382で、債務対象は、貸し手残高が第1のスマートコントラクトに関連付けられた担保価値を上回るかどうかを判定する。本明細書でさらに説明するように、貸し手残高が担保価値の所定のしきい値内にある場合、債務対象は、384で清算に進み、388で債務対象を終了してもよい。たとえば、所定のしきい値が担保価値の105%に設定され、貸し手残高が担保価値の105%未満である場合、清算が開始されてもよい。いくつかの実施形態では、債務対象は、借り手残高が第1のスマートコントラクトに関連付けられた担保価値を上回るかどうかを判定してもよい。本明細書でさらに説明するように、借り手残高が担保価値の第2の所定のしきい値内にある場合、債務対象は、384で清算に進み、388で債務対象を終了してもよい。

386で、債務対象は、債務対象の期間が満了したかどうかを判定し、その場合、388で終了に進んでもよい。

390で、債務対象は、外部金利を所定の金利と比較する。

外部金利が所定の金利に対して増加した場合、396で、借り手残高は、金利の変化を補償するための調整額だけ増加してもよく(そうでなければ、貸し手は、所定の金利よりも多く受信することになり、同様に、借り手は、所定の金利よりも多く請求されることになる)、貸し手残高は、同等の調整額だけ減少してもよい。オプションで、債務対象は、398で借り手に割り振られた別のアカウントに調整額を即座に転送してもよい。調整額は、外部金利と所定の金利と間の差に基づいていてもよい。

いくつかの場合には、外部金利が増加した場合に第1のスマートコントラクトが不注意に清算されるのを防ぐために、調整額は、即座に、またはインクリメンタルで、またはその両方で、第1のスマートコントラクトに自動的に転送されてもよい。

外部金利が所定の金利に対して低下した場合、392で、貸し手残高は、金利の変化を補償するための調整額だけ増加してもよく(そうでなければ、借り手は、所定の金利よりも少なく請求され、同様に、貸し手は、所定の金利よりも少なく発生させることになる)、借り手残高は、同等の調整額だけ減少してもよい。

オプションで、債務対象は、エスクローアカウントと見なす場合がある貸し手(図示せず)に割り振られた別個のアカウントに調整額を即座に転送してもよい。上記のように、調整額は、外部金利と所定の金利と間の差に基づいていてもよい。

調整額は、担保の部分的または完全な清算を実行し、担保の清算部分を解放し、CDPスマートコントラクトから別のアカウントに転送することによって取得されてもよい。

いくつかの実施形態では、債務対象は、代わりに(たとえば、担保比率、またはローン対価値比率が以前に枯渇していない場合)追加のDaiの生成または引き出しをサポートするのに十分な担保が残っていると仮定して、CDPスマートコントラクトから新しい(すなわち、追加の)Daiを引き出してもよい。

例として、100Daiと評価された担保がCDPスマートコントラクトによって保持され、30DaiのみがCDPスマートコントラクトから引き出された場合、CDPスマートコントラクト全体の清算をトリガせずに追加のDaiを引き出すことが可能になる場合がある(たとえば、担保比率が3:2の場合、追加の10Daiが引き出される場合がある)。清算しきい値は、いくつかの場合には、担保比率と異なる場合があることに留意されたい(たとえば、しきい値は、1:1のような低い担保を許容する場合がある)。

追加のDaiの引き出しは、CDPスマートコントラクトを清算しきい値を満たすために近づくように動かし、CDPスマートコントラクトを部分的に清算する別の形態と考えてもよい。

上記のアプローチに従って受信された任意の追加のDaiは、貸し手残高が維持され、貸し手に十分な利息を支払うことができることを確実にするように、前述のエスクローアカウントに転送されてもよい。

394で、債務対象は、貸し手残高が第1のスマートコントラクトに関連付けられた担保価値を上回るかどうかを判定してもよい。貸し手残高が担保価値の所定のしきい値内にある場合、債務対象は、384で清算に進み、388で終了してもよい。たとえば、所定のしきい値が担保価値の105%に設定され、貸し手残高が担保価値の105%未満である場合、清算が開始されてもよい。

そうでない場合、本方法は、戻るか、または354でさらなる実行サイクルを待ってもよい。

388で債務対象を終了または清算することは、貸し手残高および少なくとも1回の第1の支払いに基づいて、貸し手返金額を計算することと、借り手残高および少なくとも1回の第1の支払いに基づいて、借り手返金額を計算することと、貸し手返金額および借り手返金額に基づいて暗号通貨をリリースすることとを伴っていてもよい。暗号通貨をリリースすることは、トランザクションでの少なくとも1つの貸し手トークンの保有者への貸し手返金額(または貸し手のアドレス)を転送することと、少なくとも1人の借り手トークン(または借り手のアドレス)の保有者に借り手返金額を転送することとを伴っていてもよい。いくつかの実施形態では、貸し手返金額および借り手返金額は、本明細書に記載されたように、未払いの債務トークンに基づいて計算されてもよく、貸し手返金額または借り手返金額の少なくとも一部、またはその両方を、未払いの債務トークンを保持するアドレスに割り振ってもよい。

いくつかの実施形態では、債務対象の終了388は、関心のあるユーザが債務対象(たとえば、借り手残高、貸し手残高)によって保持される資産に入札することを許可する場合があるオークションプロセスを伴っていてもよい。入札プロセスの終了後、勝者は、落札金額を送信し、代わりに関連資産の制御を受信する。しかしながら、いくつかの実施形態では、入札者は、資産のサブセットのみを受信することがあり、これらのサブセットは、債務対象に従ってオークションの勝者の前に、または同時に、関連する資産の制御を受信する場合がある他のパーティに支払うべき金額(たとえば、貸し手または借り手、2次トークンの保有者に支払うべき金額など)を決定し、減算することによって計算される。

金利を計算するとき、債務対象388は、所定の間隔複利(interval compounding)(たとえば、年次、月次、日次など)を使用して金利額を計算するか、いくつかの場合には、連続複利を使用して金利額を計算してもよい。たとえば、Maker DAO安定手数料は、連続複利を使用して計算される。

連続複利を使用して金利を計算するには、以下の式を使用してよい。
Pe^rt-P=A
ここで、Pは、元本の投資額(たとえば、初期預金またはローン金額)、rは年金利(10進形式)、tは資金が投資された年数、eはオイラー数、Aは金利額である。

理解を助けるために、債務対象の実行のいくつかの例が次に提供される。これらの例では、外部金利(DSRなど)は年利2%であり、所定の金利は毎年3%に固定されていると仮定されてもよい。少なくとも1つのローントークンに関連付けられている担保価値は、1000通貨単位(ドルなど)で評価され、貸し手金額も1000通貨単位である。理解を容易にするために、年複利が使用されているが、実際には、連続複利を含む他のタイプの複利が使用される場合があり、その結果、異なる計算結果が得られることになる。

第1の例では、債務対象の開始から1か月後、外部金利に調整がなく、毎年2%に留まっている。この場合、借り手は、所定の金利(毎年3%)とDSR(毎年2%のまま)との間の差を埋め合わせるために、貸し手に価値を転送する義務がある。債務対象は、次に実行されるとき(たとえば、クエリトランザクションまたは他のトランザクションの受信時)、借り手の残高を更新するだけで、この価値の転送を説明することができる。支払いは即座には行われないが、債務対象が保持する担保をリリースするために支払う必要がある場合がある。

あるいは、いくつかの実施形態では、債務対象が保持する担保の対応する部分の部分的清算を呼び出し、対応する部分の制御を債務対象に転送し、それに応じて債務対象の貸し手残高を更新することによって、支払いを即座におよび/または少しずつ行ってもよい。いくつかの場合には、担保が部分的に清算され、担保の対応する部分がCDPスマートコントラクトからリリースされてエスクローに保持されてもよい。代替的に、追加のDaiが作成され、CDPスマートコントラクトから引き出され(たとえば、担保比率が許す場合)、同様にエスクローに保持されてもよい。そのような調整トランザクションは、債務対象の更新機能が実行されるたびに、たとえば毎日実行することができる。

例を続けると、債務対象の開始から2か月後、外部金利は毎年4%に上昇する。この場合、貸し手は、所定の金利(毎年3%)とDSR(現在は毎年4%)との間の差を埋め合わせるために、貸し手に価値を転送する義務がある。前述のように、債務対象は、次に実行されるとき(たとえば、クエリトランザクションまたは他のトランザクションの受信時)、単に借り手の残高を更新するだけで、この価値の転送を説明することができ、この場合、借り手残高は等しくなる。

例をさらに続けると、債務対象の開始から3か月後、外部金利は毎年15%に上昇する。この場合、貸し手は、この場合も、所定の金利(毎年3%)とDSR(現在は毎年15%)との間の差を埋め合わせるために、貸し手に価値を転送する義務がある。所定の金利の差は毎年12%、または毎月1%である。したがって、債務対象は、次に実行されるとき(たとえば、クエリトランザクションまたは他のトランザクションの受信時)に、3か月目の貸し手金額の1%で借り手残高を更新することによって、この価値の転送を説明することができる。

債務対象が3か月後に終了した場合、貸し手金額の1%、または10単位が借り手アドレスまたは第1のスマートコントラクトに転送されることになる。

第2の例では、債務対象がインスタンス化された直後、外部金利がゼロに低下し、1か月間保持される。債務対象が1か月後に終了した場合、借り手は、債務対象が少なくとも1つのローントークン(および担保)の制御をリリースするため、所定の金利(毎年3%)と外部金利(0%)との間の差、すなわち、貸し手金額の3/12%を債務対象に(または、いくつかの場合には、貸し手アドレスに)転送する必要がある。

第3の例では、債務対象がインスタンス化された直後、外部金利は23%に上昇し、1年間それに留まる。その間、第1のスマートコントラクトに関連付けられた担保オブジェクトの価値が大幅に低下し、したがって担保価値が第1のスマートコントラクトの清算価格(たとえば、担保価値から未払金額値を差し引いたもの)に近づきつつあり、第1のスマートコントラクトが終了する場合がある。しかしながら、債務対象は、両方のパーティに所定の金利を設定するので、第1のスマートコントラクトは清算されない。この場合、債務対象は、第1のスマートコントラクトの清算を防ぐために、その制御下にある資金を第1のスマートコントラクトに転送してもよい。このシナリオでは、貸し手は、第1のスマートコントラクトを有効に維持するために、債務対象の満了前に、借り手の負債を実質的に返済している。

第4の例では、外部金利は、債務対象のインスタンス化後1年間2%のままであるが、第1のスマートコントラクトの担保価値は95%低下する。次いで、第1のスマートコントラクトの所有権がサードパーティに転送され、サードパーティは、第1のスマートコントラクトを閉じ、担保オブジェクトを、債務対象である少なくとも1つのローントークンの保有者に返す。したがって、債務対象は、次いで、担保オブジェクトを使用して、3%の所定のレートを達成するために必要な外部金利(2%)を超えるさらに1%の金利を貸し手に支払うことができる。担保オブジェクトの残りの金額があれば、借り手に返すことができる。

次に図4を参照すると、債務対象に関連付けられた少なくとも1つまたは複数の貸し手を変更する方法の例示的なプロセスフロー図が示される。

方法400は、債務対象の作成後いつでも開始してよく、404で債務対象が貸し手の変更要求を受信することから始まる。要求はトランザクションである場合があり、導入される追加の貸し手のアドレスを識別し、ローン金額のそれぞれのシェアを含んでいてもよい(別の貸し手が引き出す場合がある任意の金額を置き換えるため)。

408で、債務対象は、追加の貸し手アドレスを貸し手トークンと内部的に関連付ける。たとえば、複数の既存の貸し手トークンのサブセットは、第2の貸し手アドレスに関連付けられてもよい。

412で、第1および第2(および追加の)貸し手アドレスに関連付けられた複数の貸し手トークンの割合に従って、貸し手金額を、第1の貸し手アドレスと第2の貸し手アドレス、および任意の追加の貸し手アドレスとの間で再割振りすることができる。割振りの割合は、ブロックチェーンに記録された貸し手トークンの保有物を参照して確認し、変更トランザクションの一部として受け取られた任意のローン金額と照合することができる。

いくつかの場合には、元のまたは既存の貸し手はまた、要求の一部として取り除かれてもよく、その場合、トランザクションは、取り除かれる貸し手を識別する。

416で、債務対象は、貸し手が取り除かれるか、関連付けを解除されるかを決定する。はいの場合、債務対象は、第1の貸し手アドレスから少なくとも1つの貸し手トークンの関連付けを内部的に解除し、第1の貸し手アドレスに返されるローン金額のサブセットを決定することができる。債務対象は、オプションで、それが420で1つまたは複数の2次ローン金額を受信したことを確認して、ローン金額のサブセットを置き換えてもよい。

ローン金額のサブセットは、424で、第1の貸し手アドレスに転送されてもよい。

いくつかの実施形態では、ローン金額のサブセットは、第1の貸し手アドレス(または他の取り除かれた貸し手)に即座に転送されなくてもよい。代わりに、1つまたは複数の債務トークンが生成され、第1の(または他の)貸し手アドレスに転送されてもよい。そのような実施形態では、債務対象の清算または他の終了時に未払いである1つまたは複数の債務トークンは、ローン金額を配分するために表にされ、債務対象によって使用される。

次に図5を参照すると、債務対象に関連付けられた少なくとも1つまたは複数の借り手を変更する方法の例示的なプロセスフロー図が示される。

方法500は、債務対象の作成後いつでも開始してもよく、504で債務対象が借り手の変更要求を受信することから始まる。要求はトランザクションである場合があり、導入される追加の借り手のアドレスを識別し、借り手残高のそれぞれのシェアを含んでいてよい。

508で、債務対象は、追加の借り手アドレスを借り手トークンと内部的に関連付ける。たとえば、複数の既存の借り手トークンのサブセットは、第2の借り手アドレスに関連付けられてもよい。

512で、第1および第2(および追加の)借り手アドレスに関連付けられた複数の借り手トークンの割合に従って、借り手残高を、第1の借り手アドレスと第2の借り手アドレス、および任意の追加の借り手アドレスとの間で再割振りすることができる。割振りの割合は、ブロックチェーンに記録された借り手トークンの保有物を参照して確認することができる。

いくつかの場合には、元のまたは既存の借り手に属する借り手残高の割合は、要求の一部としてゼロに低減されてもよく、その場合、対応する借り手は取り除くことができる。

516で、債務対象は、借り手を取り除くことができるか、関連付けを解除することができるかを決定する。はいの場合、債務対象は、520で、第1の借り手アドレスから少なくとも1つの借り手トークンの関連付けを内部的に解除することができる。少なくともいくつかの実施形態では、債務対象は、貸し手金額の一部を第1のスマートコントラクトに転送して、未払金額値を低減してもよい。

方法400のように、いくつかの実施形態では、ローン金額のサブセットは、第1の貸し手アドレス(または他の取り除かれた貸し手)に即座に転送されなくてもよい。代わりに、1つまたは複数の債務トークンが生成され、第1の(または他の)貸し手アドレスに転送されてもよい。そのような実施形態では、債務対象の清算または他の終了時に未払いである1つまたは複数の債務トークンは、ローン金額を配分するために表にされ、債務対象によって使用される。

本明細書に記載されたように、記載された実施形態の少なくともいくつかは、複数のユーザのための担保管理システムとして使用されてもよい。たとえば、記載されたシステムおよび方法は、貸し手が信頼できない方法で、仲介者またはカウンターパーティを必要とせずに、自分のポジションを新しい貸し手に転送することを可能にするために使用されてもよい。次いで、既存の貸し手は、ローン金額を引き出してもよい。いくつかの場合には、貸し手がそのポジションを新しい貸し手に転送するとき、外部金利(DSRなど)が異なる場合がある。そのような場合、元の貸し手は、元のレートでの利息の発生を継続してもよく、この未収利息は、債務対象が生成された時点での元の所定のレートと新しい貸し手のための新しい所定のレートとの間の差に対する権利を表す2次トークンまたは利息トークンの形式で表される場合がある。2次トークンの保有者による利息は、時間の経過とともに発生するか、2次トークンの引き換え時に計算されてもよい。いくつかの場合には、債務対象が2次トークンを生成してもよい。いくつかの実施形態では、2次トークンは、最初の貸し手に提供されるのと同じタイプのトークンであってもよい。いくつかの場合には、「トークン」は、単に残高に関連付けられたアカウントであってもよい。この転送プロセスは、追加の貸し手に対して繰り返される場合がある。

貸し手間のそのような転送の一部として、既存の貸し手がそのポジションを新しい貸し手に販売するときの担保の補充によって、カウンターパーティのリスクを低減または排除することができる。

次に図7を参照すると、いくつかの実施形態による、債務対象に関連付けられた貸し手を転送する例示的な方法が示される。方法700は、本明細書に記載されたように、既存の債務対象によって実行されてもよい。

705で、貸し手は、債務対象内に(たとえば、貸し手トークンの形で)CFRAポジションを保持する。

710で、貸し手は、貸し手トークンを新しい貸し手に転送したいことを決定し、転送要求を債務対象に伝送する。転送要求は、転送される貸し手トークンの量、新しい所定のレート、新しい貸し手アドレスを識別し、既存の貸し手によって署名されてもよい。債務対象は、いくつかの場合には、新しい所定のレートが元の所定のレートとは異なると判断する場合がある。

715で、債務対象は、転送の一部として補充されるローン金額の金額を決定する。いくつかの場合には、適切な金額(たとえば、既存の貸し手に払い戻しできるように、ローン金額の2倍の金額に、任意の未払い利息または既存の貸し手に対して、または既存の貸し手によって負われている他の調整額をプラスまたはマイナスした金額)を受信する債務対象によって補充が実行されてもよい。他のいくつかの場合には、補充は、既存の貸し手が新しい貸し手から適切な量(たとえば、返金額)を受け取り、トランザクションを債務対象に通知することによって実行される場合がある。

720で、債務対象は、払い戻し額を受信したことを確認し、必要に応じて、払い戻し額を既存の貸し手に送信する。代替的に、債務対象は、既存の貸し手が新しい貸し手から払い戻し額を受信したことを確認する。次いで、債務対象は、元の所定のレートと新しい所定のレートとの間の差を表す2次トークンを生成し、新しく生成された2次トークンを既存の貸し手に転送する。

725で、債務対象は、ローン金額の所有権を表す新しい貸し手トークンを生成し、新しく生成された貸し手トークンを新しい貸し手アドレスに転送する。次いで、新しい貸し手は、既存の貸し手になる。

次いで、最新の既存の貸し手がそのポジションをさらに新しい貸し手に転送することを望む場合、方法700は、705に戻ってもよい。

いくつかの実施形態では、類似のシステムおよび方法を使用して、借り手が自分のポジションを新しい借り手に転送できるようにしてもよい。

方法700を連続して数回実行する方法を示すために、例示的なシナリオをTable 1(表1)に示す。この例では、第1の金額X₁、第2の金額X₂、および第3の金額X₃は、次のように関連付けられる。
X₃≦X₁≦X₂

X₁、X₂、およびX₃の特定の値は、(たとえば、金利および初期金額が変わる可能性があるので)トランザクションごとに異なる可能性があるが、金利が低下しない限りおよび/または負にならない限り、一般に上記の関係が観察される。

上述のように、いくつかの実施形態では、貸し手または借り手トークン、あるいはその両方が生成されない場合がある。そのような実施形態では、トークンを生成し、転送する代わりに、債務対象は、借り手および貸し手に関連付けられたアドレスを記録し、その後、各アドレスに関連付けられた値を更新することによって債務を追跡してもよい。

次に、図8A〜図8Dを参照すると、少なくともいくつかの実施形態による債務対象を管理する方法のプロセスフロー図が示される。プロセスフロー800a、800b、800c、および800dは、たとえばシステム100の要素によって実行することができる。特に、借り手デバイス830は、借り手デバイス130a、130bなどに類似していてもよく、貸し手デバイス840は、貸し手デバイス140a、140bなどに類似していてもよい。

監視サーバ802は、外部サーバ150などの外部サーバ、または仲介デバイス160などの仲介デバイスであってもよい。監視サーバ802は、本明細書でさらに説明するように、フロー700の一部を開始するために、定期的な監視機能(いくつかの実施形態では"cron"として知られる)を実行してもよい。

Daiスマートコントラクト812は、システム100のノード120など、ブロックチェーンの1つまたは複数のノードによって実行されるスマートコントラクトであり、Dai暗号通貨を実装し、動作する。

CFRA管理スマートコントラクト814は、システム100のノード120など、ブロックチェーンの1つまたは複数のノードによって実行されるスマートコントラクトであり、本明細書に記載されたようにCFRAを実装する。CFRA管理スマートコントラクト814は、概して、別個のスマートコントラクトとして展開することができる個々の債務対象の作成および完了を追跡し、監視するように動作する。

債務対象816は、CFRA管理スマートコントラクト814によって作成されたスマートコントラクトであってもよい個々のCFRAスマートコントラクトであってもよい。

ラッパーコントラクト818は、債務対象816に代わってCDPスマートコントラクトとインターフェースするスマートコントラクトであり、債務対象816が、DSRのチェック、CDP内のDaiのアンロック、CDPの終了など、いくつかの機能を実行できるようにする。

プロキシコントラクト808は、Maker DAO組織に代わってCDPスマートコントラクトとインターフェースするスマートコントラクトであり、Maker DAO組織が本明細書の他の場所で説明するようにCDPを管理できるように許可する。

次に図8Aを参照すると、いくつかの実施形態による、債務対象を作成する方法のプロセスフロー800aが示される。

フロー800aは、832で始まり、新しい債務対象を作成するために、借り手デバイス830がCFRA管理スマートコントラクト814に要求を伝送する。要求は、満期日、担保価値、負債価値、および債務対象の所定の金利を指定してもよい。

834で、CFRA管理スマートコントラクト814は、債務対象816を作成し、インスタンス化し、836で債務対象のアドレスを返す。

838で、債務対象816は、新しいCDPを作成し、暗号通貨額(たとえば、イーサ)をロックし、対応するDai額を引き出す要求を伝送する。すなわち、Makerシステムの担保としての暗号通貨の預金は、引き出すことができるDaiを作成する機能をトリガする。

要求に応答して、841で、ラッパー818は、プロキシ808に、新しいCDPを作成し、暗号通貨額をロックし、Dai額を引き出す旨の要求を伝送する。

CDPの作成時に、プロキシは、842でCDPの識別子で応答し、ラッパーは、844で債務対象に返す。

846で、CFRA管理スマートコントラクト814は、たとえば一致しない貸し手および借り手を含む債務対象のリストの要求に応答して、新しい債務対象の存在を公開し、それによって、貸し手は、参加を希望する債務対象を識別できるようになる。

次に図8Bを参照すると、いくつかの実施形態による、債務対象のリストを閲覧する方法のプロセスフロー800bが示される。

フロー800bは、貸し手デバイス840によって実行されてもよく、貸し手デバイス840は、保留中または不一致の債務対象のリストを求める要求を848でCFRA管理スマートコントラクト814に送信してもよい。CFRA管理スマートコントラクトは、それに応じて要求に応答してもよい。

次に図8Cを参照すると、いくつかの実施形態による、債務対象の管理承認の方法のプロセスフロー800cが示される。

オプションで、いくつかの実施形態では、新しく作成された債務対象ごとに管理承認が必要になる場合がある。そのような場合、管理者801は、各債務対象を検討し、債務対象が許容可能であると納得すると、850で承認をCFRA管理スマートコントラクトに伝送し、CFRA管理スマートコントラクトは、852で承認を債務対象816に通知してもよい。その後、債務対象816は、その状態を854で承認済に変更してもよい。

次に図8Dを参照すると、貸し手についての債務対象を受け入れる方法のプロセスフロー800dが示される。

860で、貸し手デバイス840は、債務対象に基づいて転送されるDaiの金額を承認し、Daiのリリースの承認をDaiスマートコントラクト812に伝送する。862で、貸し手デバイスはまた、合意要求を債務対象816に伝送する。合意要求は、Daiの合意された金額を制御するための権限を含んでいる場合がある。

合意要求に応答して、債務対象816は、864で、Daiスマートコントラクトに確認を伝送する。確認は、貸し手識別子またはアドレスおよび貸出金額を含んでいてもよい。

866で、債務対象816は、Daiロック要求をラッパー818に伝送し、ラッパー818は、868でプロキシ808の識別および要求された金額を含む承認をDaiスマートコントラクト812に送信する。ラッパー818はまた、870で、ロックされたDaiをプロキシ808に登録し、プロキシ808は、872で、登録を転送して、DaiがDSRに従って利息を確実に発生させるようにする。

874で、債務対象816は、その状態をアクティブに更新する。

次に図9を参照すると、少なくともいくつかの実施形態による、トランザクションを行う方法を示すプロセスフロー図が示される。プロセスフロー900は、たとえばシステム100の要素によって実行することができる。特に、借り手デバイス930は、借り手デバイス130a、130bなどに類似していてもよく、貸し手デバイス940は、貸し手デバイス140a、140bなどに類似していてもよい。

監視サーバ902は、外部サーバ150などの外部サーバ、または仲介デバイス160などの仲介デバイスであってもよい。監視サーバ902は、本明細書でさらに説明するように、フロー900の一部を開始するために、定期的な監視機能(いくつかの実施形態では「クロン」として知られる)を実行してもよい。

Daiスマートコントラクト912は、システム100のノード120など、ブロックチェーンの1つまたは複数のノードによって実行されるスマートコントラクトであり、Dai暗号通貨を実装し、動作する。

CFRA管理スマートコントラクト914は、システム100のノード120など、ブロックチェーンの1つまたは複数のノードによって実行されるスマートコントラクトであり、本明細書に記載されたようにCFRAを実装する。CFRA管理スマートコントラクト914は、概して、別個のスマートコントラクトとして展開することができる個々の債務対象の作成および完了を追跡し、監視するように動作する。

債務対象916は、CFRA管理スマートコントラクト914によって作成されたスマートコントラクトであってもよい個々のCFRAスマートコントラクトであってもよい。

ラッパーコントラクト918は、債務対象916に代わってCDPスマートコントラクトとインターフェースするスマートコントラクトであり、債務対象916が、DSRのチェック、CDP内のDaiのアンロック、CDPの終了など、いくつかの機能を実行できるようにする。

プロキシコントラクト908は、Maker DAO組織に代わってCDPスマートコントラクトとインターフェースするスマートコントラクトであり、Maker DAO組織が本明細書の他の場所で説明するようにCDPを管理できるように許可する。

プロセスフロー900は、920で始まり、監視サーバ902は、チェック契約要求をCFRA管理スマートコントラクト914に発行する。この要求は、ユーザ入力に応答して発行されてもよく、または所定の間隔で定期的なチェックとして発行されてもよい。

922で、CFRA管理スマートコントラクト914は、チェック合意要求を処理し、それが作成した(または監視するように構成された)各債務対象916に個々のチェック合意要求を送信する。

924で、チェック合意要求に応答して、各債務対象916は、債務対象916に関連付けられたCDPについて、ラッパーコントラクト918に現在のDSRを要求する。ラッパーコントラクト918は、926で現在のDSRを返す。

928で、債務対象916は、最後のチェックが実行されてから経過した時間の長さを決定し、931で、CDPが保持するすべてのDaiをアンロックする旨の要求をラッパーコントラクト918に発行する。

DSRが現在、債務対象916に関連付けられた所定の金利よりも高い場合、サブフロー941が実行される。DSRが現在、債務対象916に関連付けられた所定の金利よりも高い場合、サブフロー950が実行される。DSRが所定の金利に等しい場合、システムがどのように構成されるかに応じて、サブフロー941またはサブフロー950のいずれかが実行されてもよく、または何も実行されなくてもよい。

サブフロー941が実行されると、債務対象916は、942でDSRと金利との間の現在の差を計算する。現在の差は、たとえば次の式を使用して計算されてもよい。
currentDifference=debtValue*(currentDSR-interestRate)*timeInterval/minsInYear
ここで、debtValueは、CDPに保持されている負債の現在価値であり、interestRateは、所定の金利であり、timeIntervalは、928で計算された間隔であり、minsInYearは、1年の分数である(いくつかの実施形態では、他の粒度が使用されてもよい)。

944で、942で計算された現在の差に基づいて、保留中の注入額(貸し手残高を更新するために貸し手に要求される)が更新される。保留中の注入額が所定の注入しきい値を上回る場合、946で、債務対象916は、保留中の注入額をCDPに転送するようラッパー918に指示し、これはラッパー918が947で行った後、949でプロキシ908に注入を通知する。所定の注入しきい値を使用することによって、債務対象916は、トランザクションおよび計算コストを負う場合があるチェックが発生するたびにCDPを更新することを回避することができる。

サブフロー950が実行されると、債務対象は、952でDSRと金利との間の現在の差を計算し(たとえば、942と同じ式を使用して)、954で借り手残高をそれに応じて更新する。

951で、債務対象916は、ラッパー918にCDP内のDai金額をもう一度ロックするよう要求し、ラッパー918は、953でそれを行い、それに応じてプロキシ908に通知してもよい。

債務対象916の満了日に達したとき、満了または清算サブフロー960が実行されてもよい。

オプションで、サブフロー960が962で始まってもよく、借り手デバイス930が借り手残高を説明するために必要な金額を供給するDaiスマートコントラクトアドレスを確認することを債務対象916が要求する。いくつかの場合には、このアクションは、満了日の前に実行されてもよい。

964で、債務対象916は、CDPに保持されているすべてのDaiをアンロックするようラッパー918に要求する。ラッパー918は、清算ルーチンを実行し、966でプロキシ908に要求を通知する。

968で、ラッパー918は、オプションで、アンロックされたDaiの金額を債務対象916に通知してもよい。

970で、借り手デバイス930は、借り手残高を説明するために必要な資金を供給するためにDaiスマートコントラクトアドレスを確認し、Daiスマートコントラクト912の転送機能を実行する。オプションで、借り手デバイス930は、Daiスマートコントラクトアドレスを供給しないこと、または借り手残高を返さないことを選択してもよい(これによって、CDP、およびしたがって、CDPによって保持される担保の制御が失われる場合がある)。

972で、債務対象は、Daiの借り手残高額をDaiスマートコントラクト912に要求し、974で、借り手残高額は、Daiスマートコントラクト912から転送され返されてもよい。

976で、借り手残高額の受け取りに成功したことに応答して、債務対象916は、アンロックされたDaiの金額をCDPおよび借り手残高額から貸し手デバイス940(または貸し手デバイス940によって指定されたアドレス)に転送する。

974で借り手残高額が受け取られない場合(たとえば、借り手が借り手残高を完済するためにDaiのリリースを承認しなかったため)、サブフロー980が実行されてもよい。

サブフロー980は982で始まり、債務対象916は、ラッパー918を介してCDPの清算を要求する。ラッパー918は、CDPの清算機能を実行し、984で、オプションで、清算に続いて利用可能な資金額を債務対象916に通知する。

986で、債務対象916は、清算後の資金額の転送を要求する。988で、ラッパー918は、清算金額(担保の販売によって生成される場合がある)を債務対象916に転送する。

990で、債務対象916は、アンロックされたDai額を貸し手デバイス940(または指定されたアドレス)に転送する。

992で、債務対象916は、借り手残高を貸し手デバイス940(または指定されたアドレス)に転送するか、または清算金額が借り手残高よりも少ない場合、清算金額を転送する。

清算金額が借り手残高を上回る場合、清算金額と借り手残高との間の差(すなわち、清算金額の残りの金額)は、994で借り手デバイス930(または指定されたアドレス)に転送することができる。

998で、債務対象916は、債務対象の最後のチェック時間を示すパラメータを現在の時間に設定してもよい。

実施形態のいくつかは、債務対象および別個のラッパーコントラクトを伴うものとして本明細書に記載されているが、他のいくつかの実施形態では、債務対象およびラッパーコントラクトの機能をマージしてもよい。すなわち、債務対象は、ラッパーコントラクトによって実行される本明細書に記載された機能のいくつかを直接実行するように構成されてもよく、一方、ラッパーコントラクトの他のいくつかの機能は、ラッパー機能が債務対象に組み込まれているとき、変更される、または不要になる場合がある。

本明細書では、本発明を例としてのみ説明したが、本明細書に記載された例示的な実施形態の完全な理解を提供するために、本明細書には多数の特定の詳細が示される。しかしながら、これらの実施形態は、いくつかの場合には、これらの特定の詳細なしに実施されてもよいことが当業者によって理解されよう。他の例では、実施形態の説明を不明瞭にしないように、周知の方法、手順、および構成要素は詳細には説明されていない。添付の特許請求の範囲によってのみ制限される本発明の意図および範囲から逸脱することなく、これらの例示的な実施形態に対して様々な修正および変更が加えられてもよい。

100 システム
110 ネットワーク
120 ノードデバイス
130a、130b、830、930 借り手デバイス
140a、140b、840、940 貸し手デバイス
150 外部サーバ
160 仲介デバイス
200 コンピューティングデバイス
204 プロセッサ
208 メモリ
212 入力/出力デバイス
220 システムバス
801 管理者
802、902 監視サーバ
808、908 プロキシコントラクト
812、912 Daiスマートコントラクト
814、914 CFRA管理スマートコントラクト
816、916 債務対象
818、918 ラッパーコントラクト

Claims (25)

1. スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うためのコンピュータ実装方法であって、
   1つまたは複数のノードデバイスによって、第1のスマートコントラクトを識別するステップであって、前記第1のスマートコントラクトは、第1のアドレスおよびそれに関連付けられた第1の借り手アドレスを有し、前記第1のスマートコントラクトは、(i)前記第1の借り手アドレスに転送された暗号通貨の金額に最初に基づく未払金額値と、(ii)前記第1の借り手アドレスに関連付けられた前記スマートコントラクトにコミットされる担保オブジェクトの値を表す担保価値と、(iii)外部金利または内部金利に少なくとも基づいて、第1の変動金利を定期的に決定するように構成された金利クエリルーチンとを有する、ステップと、
   前記1つまたは複数のノードデバイスによって、前記第1のスマートコントラクトに関連付けられた少なくとも1つのローントークンを識別するステップであって、前記少なくとも1つのローントークンは、前記担保オブジェクトへの関心を表す、ステップと、
   前記1つまたは複数のノードデバイスによって、第2のスマートコントラクトを識別するステップであって、前記第2のスマートコントラクトは、第2のアドレスおよびそれに関連付けられた第1の貸し手アドレスを有し、前記第2のスマートコントラクトは、(i)前記第1の貸し手アドレスに関連付けられた暗号通貨の貸し手金額を表す貸し手残高と、(ii)前記外部金利または前記内部金利に少なくとも基づいて第2の変動金利を定期的に決定するように構成された第2の金利クエリルーチンとを有する、ステップと、
   前記1つまたは複数のノードデバイスによって、債務対象を生成するステップであって、
   前記少なくとも1つのローントークンの制御を受け取るステップと、
   前記少なくとも1つのローントークンに関連付けられた前記担保価値に基づいて、前記債務対象の借り手残高を生成するステップと、
   前記貸し手金額の制御を受け取るステップと、
   前記貸し手金額に基づいて、前記債務対象の前記貸し手残高を生成するステップと、
   少なくとも1つの貸し手トークンおよび少なくとも1つの借り手トークンを生成するステップと、
   前記少なくとも1つの貸し手トークンを前記第1の貸し手アドレスに関連付けるステップと、
   前記少なくとも1つの借り手トークンを前記第1の借り手アドレスに関連付けるステップと、
   前記債務対象に関連付けられた所定の金利を決定するステップと
   を含む、ステップと、
   前記1つまたは複数のノードによって、前記債務対象を実行するステップであって、
   前記第1の借り手アドレスから少なくとも1回の第1の支払いを受信するステップと、
   前記第1の貸し手アドレスから少なくとも1回の第2の支払いを受信するステップと、
   前記少なくとも1回の第1の支払いおよび前記少なくとも1回の第2の支払いに基づいて前記借り手残高を更新するステップと、
   トリガイベントを検出するステップと、
   前記トリガイベントの検出に応答して、前記1つまたは複数のノードによって、
   i)前記貸し手残高および前記少なくとも1回の第1の支払いに基づいて、貸し手返金額を計算するステップと、
   ii)前記借り手残高および前記少なくとも1回の第1の支払いに基づいて、借り手返金額を計算するステップと、
   iii)前記貸し手返金額および前記借り手返金額に基づいて暗号通貨をリリースするステップと
   を含む、ステップと
   を含む、方法。
2. 前記少なくとも1つの貸し手トークンが複数の貸し手トークンを含む、請求項1に記載の方法。
3. 前記複数の貸し手トークンのサブセットが第2の貸し手アドレスに関連付けられ、前記貸し手金額が、前記第1および第2の貸し手アドレスにそれぞれ関連付けられた前記複数の貸し手トークンの割合に従って、前記第1の貸し手アドレスと前記第2の貸し手アドレスとの間で再割振りされる、請求項2に記載の方法。
4. 前記1つまたは複数のノードによって、前記第1の貸し手アドレスから前記少なくとも1つの貸し手トークンの関連付けを解除するステップと、
   前記1つまたは複数のノードによって、前記ローン金額のサブセットを前記第1の貸し手に転送するステップと、
   前記1つまたは複数のノードによって、前記第2の貸し手から、前記ローン金額の前記サブセットを置き換えるために、2次ローン金額を受信するステップと、
   をさらに含む、請求項3に記載の方法。
5. 前記少なくとも1つの借り手トークンが複数の借り手トークンを含む、請求項1から4のいずれか一項に記載の方法。
6. 前記複数の借り手トークンのサブセットが第2の借り手アドレスに関連付けられ、前記借り手残高が、前記第1および第2の借り手アドレスにそれぞれ関連付けられる前記複数の借り手トークンの割合に従って、前記第1の借り手アドレスと前記第2の借り手アドレスとの間で再割振りされる、請求項5に記載の方法。
7. 前記第1の借り手アドレスから前記少なくとも1つの借り手トークンの関連付けを解除するステップをさらに含む、請求項6に記載の方法。
8. 前記債務対象を生成するステップは、前記所定の金利を決定するために、外部サーバまたはスマートコントラクトにクエリを行うステップをさらに含む、請求項1から7のいずれか一項に記載の方法。
9. 前記所定の金利が固定である、請求項1から8のいずれか一項に記載の方法。
10. 前記債務対象を実行するステップは、
    前記外部金利が前記所定の金利と比較して低下したと判断するステップと、
    前記外部金利と前記所定の金利との間の差に基づいて、前記貸し手アドレスに割り振られる前記ローン金額の割合を増加させるステップと
    をさらに含む、請求項1から9のいずれか一項に記載の方法。
11. 前記貸し手アドレスに割り振られる前記ローン金額の前記割合を増加させるステップは、
    前記ローン金額の前記割合を計算するステップと、
    前記債務対象の部分的清算機能を呼び出すステップと、
    エスクローアカウントで前記ローン金額の前記割合を受信するステップと
    をさらに含む、請求項10に記載の方法。
12. 前記債務対象を実行するステップは、
    前記外部金利が前記所定の金利と比較して増加したと判断するステップと、
    前記外部金利と前記所定の金利との間の差に基づいて、前記借り手アドレスに割り振られる前記ローン金額の割合を増加させるステップと
    をさらに含む、請求項1から11のいずれか一項に記載の方法。
13. 前記貸し手金額の制御を受け取るステップは、前記債務対象が前記貸し手金額の制御を受け取るステップを含み、前記方法は、前記1つまたは複数のノードによって、前記未払金額値を低減するために、前記貸し手金額の一部を前記第1のスマートコントラクトに転送するステップをさらに含む、請求項12に記載の方法。
14. 前記トリガイベントを検出するステップは、前記担保価値が現在前記貸し手に割り振られている前記ローン金額よりも低いことを検出するステップを含む、請求項1から13のいずれか一項に記載の方法。
15. 前記トリガイベントを検出するステップは、前記債務対象の期間が経過したことを検出するステップを含む、請求項1から13のいずれか一項に記載の方法。
16. 前記第1の支払いは、前記第1の変動金利に基づく少なくとも1回の借り手利息払いである、請求項1から15のいずれか一項に記載の方法。
17. 前記第2の支払いは、前記第2の変動金利に基づく少なくとも1回の貸し手利息支払いである、請求項1から16のいずれか一項に記載の方法。
18. 前記債務対象はスマートコントラクトである、請求項1から17のいずれか一項に記載の方法。
19. 前記少なくとも1回の第1の支払いが複数回の支払いを含む、請求項1から18のいずれか一項に記載の方法。
20. 前記暗号通貨は、Daiの形式に基づく、請求項1から19のいずれか一項に記載の方法。
21. 前記外部金利は、Dai貯蓄率である、請求項20に記載の方法。
22. 前記外部金利は、配当率に基づく、請求項20に記載の方法。
23. スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うためのコンピュータ実装方法であって、
    1つまたは複数のノードデバイスによって、債務対象を生成するステップであって、前記債務対象は、第1のアドレスおよびそれに関連付けられた第1の借り手アドレスを有し、前記債務対象は、(i)前記第1の借り手アドレスに転送される暗号通貨の金額に最初に基づく未払金額値と、(ii)前記第1の借り手アドレスによって前記債務対象にコミットされる担保オブジェクトの値を表す担保価値と、(iii)外部金利または内部金利に少なくとも基づいて、第1の変動金利を定期的に決定するように構成された金利クエリルーチンとを有し、前記債務対象は、それに関連付けられた第1の貸し手アドレスと、(i)前記第1の貸し手アドレスに関連付けられた暗号通貨の貸し手金額を表す貸し手残高とをさらに有し、前記債務対象を生成するステップは、
    前記少なくとも1つのローントークンに関連付けられた前記担保価値に基づいて、前記債務対象の借り手残高を生成するステップと、
    前記貸し手金額に基づいて、前記債務対象の前記貸し手残高を生成するステップと、
    少なくとも1つの貸し手トークンおよび少なくとも1つの借り手トークンを生成するステップと、
    前記少なくとも1つの貸し手トークンを前記第1の貸し手アドレスに関連付けるステップと、
    前記少なくとも1つの借り手トークンを前記第1の借り手アドレスに関連付けるステップと、
    前記債務対象に関連付けられた所定の金利を決定するステップと
    をさらに含む、ステップと、
    前記1つまたは複数のノードデバイスによって、前記債務対象を実行するステップであって、
    前記第1の借り手アドレスから少なくとも1回の第1の支払いを受信するステップと、
    前記第1の貸し手アドレスから少なくとも1回の第2の支払いを受信するステップと、
    前記少なくとも1回の第1の支払いおよび前記少なくとも1回の第2の支払いに基づいて前記借り手残高を更新するステップと、
    トリガイベントを検出するステップと、
    前記トリガイベントの検出に応答して、
    i)前記貸し手残高および前記少なくとも1回の第1の支払いに基づいて、貸し手返金額を計算するステップと、
    ii)前記借り手残高および前記少なくとも1回の第1の支払いに基づいて、借り手返金額を計算するステップと、
    iii)前記貸し手返金額および前記借り手返金額に基づいて暗号通貨をリリースするステップと
    を含む、ステップと
    を含む、方法。
24. プロセッサによって実行されると、前記プロセッサに、請求項1から23のいずれか一項に記載の方法を実行させる、前記プロセッサによって実行可能なコンピュータプログラムコードを記憶する非一時的コンピュータ可読記憶媒体。
25. スマートコントラクトを使用して暗号通貨で継続的な金利先渡契約を自動的に行うためのシステムであって、
    データ通信ネットワークと、
    少なくとも1つの貸し手デバイスと、
    少なくとも1つの借り手デバイスと、
    プロセッサおよびメモリを含む少なくとも1つのノードデバイスであって、前記プロセッサが請求項1から23のいずれか一項に記載の方法を実行するように構成される、少なくとも1つのノードデバイスと
    を含む、システム。

Images