XRPLのクリーンアップ修正案は発効に必要な正確な閾値で支持を維持している一方、提案中のレンディング関連修正案は必要な支持を大きく下回ったままである。10月18日時点で、XRPL Dashboardが監視する35の検証ノードのうち29がfixCleanup3_4_0を支持していた。この修正案は80%を厳密に超える承認を必要とするため、29票が最低ラインとなり、35中28では不十分である。修正案（Amendment）はXRP Ledgerが新たなルールを採用する仕組みであり、この票数が一連の修正が予定通り発効するかどうかを左右する。

ダッシュボードは10月9日から過半数を記録しており、2週間の期間を通じて支持が変わらなければ、10月23日の午前9時34分（UTC）頃に発効すると予測している。同修正案は「票の余裕がない（no votes to spare）」状態だと説明されている。

この修正案には約25件の修正が含まれ、そのうち8件がボールトとレンディングに関するものである。その他の変更は自動マーケットメーカー（AMM）、トラストライン、非代替性トークン（NFT）、マルチパーパストークン、エスクロー、スポンサー署名、権委譲に影響する。

XRPLレンディングの設計

提案されているXRPLレンディングシステムは、預入者、ローンブローカー、借り手をボールトを通じてつなぐ。預入者は単一資産をシングルアセットボールトに預け入れ、ブローカーがそのプールから固定期間・無担保のローンを手配する。借り手は合意した条件に従って返済する。詳細はXRPLレンディング文書に記載されている。

台帳はローンを管理するが、審査（アンダーライティング）はオフチェーンで行われる。現在の設計には、オンチェーンでの担保自動清算も含まれていない。この提案の概要は以前Coindooが取り上げた。他のXRPL機能と同様、レンディングシステムは修正案の投票を通じてのみ有効化される。修正案が同じスーパー多数派の閾値と14日間の猶予期間をクリアするまで、ボールトとブローカーの設計は提案のままであり、稼働中の台帳機能ではない。

票数状況と発効スケジュール

fixCleanup3_4_0を支持する29票が重要なのは、XRPLの修正案プロセスが信頼済み検証ノードの80%を厳密に超える多数を要求するためである。ダッシュボードは35の検証ノードを監視しており、したがって閾値は29となる。

このプロセスでは、多数派を失うことが発効スケジュールにどう影響するかがすでに示されている。PermissionDelegationV1_1は9月23日に35中28票まで低下した。BatchV1_1は9月25日の1回の採決で多数派を失い、10月9日の有効化前に2週間の発効カウントが再始動された。公式の修正案プロセスでは、必要な多数派を失うと2週間の期間がリセットされる。

レンディング関連修正案は、さらに8〜10票と、その後の14日間の猶期間を必要としている。そのため、最短でも11月初旬より前に発効することはない。

票数に関しては留意点もある。10月8日にrippledのGitHubリポジトリに提出された報告によると、バージョン3.4.1では、検証ノードが署名鍵をローテーションして閾値から外れると、そのノードの票が計上されなくなるという。報告者は35と28ではなく33件の検証と26の閾値を観測し、いずれの修正案も結果は変わらなかったと述べており、Unchainedが報じた。パッチは10月9日時点で審査中であった。

fixCleanup3_4_0の変更内容

クリーンアップ修正案はレンディングの更新にとどまらない。XRPL修正案リストによると、約25項目のうち主な変更は以下の通りである。

• トラストライン： 発行者による着信トラストラインのブロックはオファーにも適用される。対象の着信トラストラインがブロックされている場合、アカウントはオファーを通じてトークンを受け取れなくなる。
• AMMのクローバック： 丸め処理で金額がゼロになった場合、クローバックは保有者のプールトークンをバーンしても何も回収しなくなることはなくなる。
• エスクロー： トークンを返還するエスクローのキャンセルまたは完了は、所有者がリザーブ境界にある場合でも失敗しなくなる。
• 署名： スポンサーとカウンターパーティの署名には異なるプレフィックスが使われ、あるロール用に作られた署名が別のロールとして再生されることを防ぐ。

これらの変更はxrpld 3.4.0リリースノートに記載されている。10月8日に稼働した機能にも影響する。XRPLの文書は、クリーンアップが有効化されるまで、細分化されたPaymentBurn権限の委譲を避けるよう助言している。これは、同権限を持つ代理人がトークンを破壊するだけでなく、新しいトラストライントークンやマルチパーパストークンを作成できる可能性があるためであるとUnchainedが報ている。クリーンアップは、残高ゼロを横断してミントに至るようなPaymentBurnのみの支払いを拒否する。

ボールトの預入と会計への影響

ボールトシェアはマルチパーパストークンであり、その価値はボールトが保有する資産に連動する。台帳は、不良とマークされたローンの「未実現損失」も追跡する。ボールト文書の例では、100万ドルのボールトに90万ドルの未実現損失がある場合、引き出し交換レートは0.1となる。

クリーンアップはこの部分に3つの変更を加える。預け入れ・引き出し・クローバックの丸めがより正確になり、ボールトの総資産、利用可能資産、シェア供給の一貫性が保たれる。完全に不良となったボールトからの固定シェア引き出しは、失敗する代わりにゼロの資産を移動できる場合がある。取引は一切の資金回収なしに完了し、リリースノートはこの挙動が失敗に置き換わった理由を説明していない。

この修正案は、ローンの遅延・不良・デフォルト判定にも変更を加える。期日を厳密に経過していなければローンをフラグできないため、期日当日に遅延やデフォルトとマークされることはない。

これは対象コードに向けられた4番目のクリーンアップ修正案である。XRPLのボールト文書によると、fixCleanup3_1_3からfixCleanup3_4_0までの各修正案は、2025年の監査後にボールト挙動に対する精度・丸め・正確性の修正を行った。

LendingProtocolV1_1における利息と引き出し

バージョン3.4.0で導入されたLendingProtocolV1_1は、ボールトが利息を計上する方法を変更する。以前は、ローンが組まれた時点でボールトは予定利息の全額を収益として計上し、借り手が支払いを停止した場合はそれを取り消す必要があった。

レンディング文書の例では、利用可能トークン99,000のボールトに、予定利息90トークンを伴う1,000トークンのローンがある場合を扱う。従来の方式では、ボールトの総資産は100,090と報告される。キャッシュベースの会計では、利息は支払いが実際に届いた時点でのみ計上される。したがって、シェア価格は予定された未収収益では引き上げられず、元本のみがリスクにさらされるため損失は小さく表示される。

同じ修正案はクローズドエンド型（期限付き）ボールトも追加する。これらは作成時に固定され変更できない日付に沿って3つのフェーズを進み、V1.1が有効化されると、新しいローンブローカーはクローズドエンド型ボールトのみを使用できる。XRPLシングルアセットボールト文書による。

どの会計モデルが適用されるかはボールトの作成時期による。V1.1発効前に作成されたボールトは、V1.1有効化後も永久に従来の利息モデルを保持する。文書は2つの修正案の発効間に隙間が生じることも想定している。10月18日のスナップショットでLendingProtocolとV1.1はともに19票だったが、同一の票数でも両方が同時に発効する保証はない。

ファーストロス資本とローンデフォルト

ブローカーは任意でファーストロス資本を提供できるが、2つの設定がデフォルト時にその資本のうちボールトに到達する額を制限する。CoverRateMinimumはカバーすべき債務の割合を指定し、CoverRateLiquidationはデフォルト時にその最低額のうちボールトに送られる分を制限する。

XRPLレンディングプロトコル文書の例では、ブローカーが1,000トークンのカバーを提供し、1,090トークンのローンがデフォルトした場合を扱う。両レートが10%に設定されていると、適用されるのはカバーのうち10.9トークンのみで、ボールトは1,079.1トークンの損失を負う。レートはブローカーが設定するため、実際のプールでは異なるパラメータが使われる可能性がある。

利用可能なカバーが必要最低額を下回ると、ブローカーは新しいローンを組めなくなり、手数料はカバーに充てられる。これにより新規エクスポージャーは制限されるが、既存の借り手の返済義務が生じるわけではない。

資産発行者も一定の管理権を持つ。ボールトの資産が凍結された場合、引き出しは発行者に対してのみ可能となる。発行者はボールトシェアをクローバックして資産として自身に送ることもできる。凍結された借り手は支払いができないが、債務は消滅しない。

注目すべき日付と論点

クリーンアップは、支持する29の検証ノードが発効期間の全期間にわたって票を維持すれば、10月23日の午前9時34分（UTC）頃に発効すると予測されている。1つの検証ノードでも支持を撤回すれば2週間の期間が再始動される。PermissionDelegationV1_1``BatchV1_1で実際に起きた通りである。

レンディング関連修正案は29票と14日間の猶予期間を必要とするため、最短の発効は11月となる。LendingProtocolとV1.1の間の時間的ずれも重要である。その間に作成されたボールトは従来の利息会計モデルを保持するためである。

最後に、提案中の票計算パッチも引き続き注目対象である。これは、署名鍵のローテーション後に検証ノードが票計算から消えるのを防ぐものである。

この記事は情報提供のみを目的としており、金融または投資助言を構成するものではない。修正案のスケジュールは変更される可能性があり、レンディングには信用リスクと流動性リスクが伴う。

出典：Coindoo