リップル基盤の融資設計の落とし穴｜同じ貸倒れでも損失は20倍に

XRPレジャーの融資機能をめぐって、担保設計の読み方を問い直す試算が示されました。同じ債務総額100万トークン、同じ準備金20万トークンの2つの貸出簿を用意し、どちらも合計10万トークンが貸倒れになる場合を比べたものです。それが1件の大口ローンだった場合、預金者の持ち分から失われるのは9万トークン。同じ10万トークンが1万トークン×10件に分かれていた場合は4500トークンにとどまります。差は20倍です。

この差は準備金が足りなくなったから生じるのではありません。XRPレジャーの融資設計では、預けられた準備金の全額ではなく、ブローカーの現在の債務に対して求められる「最低必要カバー額」を基準に支払上限が決まります。最低カバー率10%、清算率10%という設定なら、債務100万トークンに対する最低必要カバーは10万トークン、その10%にあたる1万トークンが1件あたりの支払上限になります。10万トークンのローンが飛んでも、出てくるのは1万トークンだけという計算です。

分割すれば守られるという逆説

10件に分かれている場合は挙動が変わります。1件目のデフォルトで1万トークンが支払われ、ブローカーの債務は99万トークンに減るため、2件目の上限は9900トークンになります。この連鎖が10件目の9100トークンまで続き、支払総額は9万5500トークンに達します。金庫側の損失は1件目のゼロから10件目の900まで積み上がって合計4500トークン。この時点で準備金は10万4500トークン残り、残債90万トークンに対する必要額9万トークンを上回っています。

つまり、ブローカーがカバーを使い切ることも、必要水準を割り込むこともないまま、預金者が9万トークンを失う事態が起こりうるということです。分割の粒度も効き、同じ設定で2分割なら8万500、5分割なら5万2000、20分割ならこのモデル上はゼロになります。

「準備金の額」は保護の指標にならない

もっとも実務的な含意は、準備金を積み増しても基本ケースの結果が変わらないという点です。準備金を40万トークンに倍増しても、1件あたりの上限が先に効いているため支払額は同じになります。逆に準備金が不足している場合には、それが別の制約として効いてきます。しかもブローカー作成後に変更できるのはフラグ、データ、債務上限のみで、2つのカバー率は固定される設計です。積み増しはできても割合は動かせません。

貸し手が本当に見るべき数字が「準備金がいくらあるか」ではなく「1件のデフォルトでその準備金からいくら引き出せるか」だという指摘は、日本のソーシャルレンディングにおける劣後出資比率の読み方にもそのまま重なりそうです。

記事ソース：資料