James Watt
The architectural design of the proposed XRP Ledger (XRPL) lending protocol introduces a significant divergence in risk outcomes for depositors based on how a broker’s loan book is structured. In a simulated model of the protocol’s mechanics, a single loan default of 100,000 tokens results in a 90,000-token loss for depositors, whereas the same 100,000-token debt spread across ten smaller loans results in a loss of only 4,500 tokens. This 20-fold difference in loss exposure occurs despite both scenarios starting with identical variables: 1 million tokens of total debt, a 200,000-token reserve, and identical protection settings. This phenomenon highlights a critical nuance in how the XRPL’s lending rules release reserve funds to cover bad debt, suggesting that the granularity of a loan book is as vital to depositor safety as the total capital held in reserve.
The Mechanics of XLS-66: Understanding the Reserve Release
The XRPL lending protocol, primarily defined under the XLS-66 specification, is designed to facilitate fixed-term, uncollateralized lending. Unlike traditional decentralized finance (DeFi) protocols like Aave or Compound, which rely on over-collateralization, the XRPL model utilizes a vault-and-broker system. In this ecosystem, depositors pool their assets (XRP, trust-line tokens, or Multi-Purpose Tokens) into a vault. A broker, acting as an underwriter, manages the distribution of these assets to borrowers. To protect depositors from defaults, brokers must maintain a reserve, often referred to as "first-loss capital."
The disparity in losses identified in recent modeling stems from the mathematical formula used to calculate "Cover Paid" during a default event. Three specific parameters govern this calculation:
- CoverAvailable: The actual quantity of tokens the broker has deposited into the reserve.
- CoverRateMinimum: The percentage of the total outstanding debt that the broker must maintain as a minimum reserve (e.g., 10%).
- CoverRateLiquidation: The percentage of that minimum required cover that can be deployed to satisfy a single default event.
According to the documentation and the 3.3.0 release code of the rippled server software, the payout for a default is capped. The amount of cover paid into the vault is the smallest of three values: the product of the current broker debt, the minimum cover rate, and the liquidation rate; the actual debt of the defaulted loan; or the total available reserve. Because each default is processed as a separate transaction with its own cover calculation, the sequence and size of loans drastically alter the effectiveness of the reserve.
Chronology of Development and Mainnet Status
The evolution of lending on the XRP Ledger has moved through several stages of proposal and technical refinement. The XLS-66 lending protocol was initially introduced to bring credit infrastructure on-chain, allowing for more capital-efficient lending than traditional collateral-heavy models.
- April 2024: Detailed discussions regarding the lending protocol’s integration with the XRPL’s Automated Market Maker (AMM) and Multi-Purpose Tokens (MPT) began to gain traction within the developer community.
- August 6, 2024: Ripple announced the release of
rippledversion 3.3.0. This update included the foundational code for the lending protocol, specifically theLoanManage.cppimplementation, which contains the logic for managing defaults and reserve payouts. - September 6, 2024: A review of the official XRPL amendment registry indicated that while the code exists in the latest release, the amendment
LendingProtocolV1_1remained in the "in development" stage. It has not yet reached the voting threshold required for mainnet activation.
As of early September, the protocol remains a prospective feature. For it to go live, it must pass through the XRPL’s standard amendment process, where 80% of validators must support the change for a continuous two-week period. Consequently, the figures discussed in recent risk models remain hypothetical, serving as a guide for prospective lenders and brokers to understand the platform’s risk-reward profile before capital is committed.
Modeling the 20-Fold Loss Gap
To understand why the loss gap is so pronounced, one must look at the step-by-step processing of defaults within the protocol. In the base model, the broker has a 1,000,000-token debt and a 10% minimum cover requirement, meaning they must maintain at least 100,000 tokens in reserve. With a liquidation rate set at 10%, the maximum cover payout for any single default is capped at 10,000 tokens (1,000,000 0.10 0.10).
Scenario A: The Single Large Default
When a single loan of 100,000 tokens defaults, the system applies the cap. Even though the broker may have 200,000 tokens available in the reserve, the protocol limits the payout to 10,000 tokens. The remaining 90,000 tokens of unpaid debt are written off as a loss to the vault, directly reducing the value of the shares held by depositors.
Scenario B: The Ten Small Defaults
In contrast, if the same 100,000-token debt is split into ten loans of 10,000 tokens each, the outcome changes.
- First Default: The cap is 10,000 tokens. The loan is 10,000 tokens. The reserve pays the full 10,000. Vault loss: 0.
- Second Default: The total broker debt has fallen to 990,000 tokens. The new cap is 9,900 tokens. The reserve pays 9,900. Vault loss: 100.
- Subsequent Defaults: The cap continues to decrease slightly as the total debt decreases.
By the tenth default, the cumulative cover paid reaches 95,500 tokens, leaving a total vault loss of only 4,500 tokens. This iterative process allows the reserve to absorb the vast majority of the debt, whereas the single-loan scenario hits a hard ceiling immediately.
Sensitivity Analysis: Settings and Controls
The magnitude of depositor loss is highly sensitive to the specific parameters chosen at the time a broker is created on the ledger. Once a broker is established via the LoanBrokerSet transaction, the CoverRateMinimum and CoverRateLiquidation settings are fixed and cannot be changed, although the broker can top up the CoverAvailable (the actual cash in the reserve).
The following table illustrates how changing the Liquidation Rate affects losses for a 100,000-token total default (with 1M total debt and 10% min cover):
| Liquidation Rate | Loss (One 100k Loan) | Loss (Ten 10k Loans) |
|---|---|---|
| 5% | 95,000 tokens | 52,250 tokens |
| 10% | 90,000 tokens | 4,500 tokens |
| 20% | 80,000 tokens | 0 tokens |
| 100% | 0 tokens | 0 tokens |
Furthermore, the model shows that simply adding more cash to the reserve (increasing CoverAvailable) does not necessarily protect depositors if the per-default cap is the binding constraint. If a broker doubles their reserve from 200,000 to 400,000, the payout for a single 100,000-token default remains capped at 10,000 tokens. The extra cash only becomes useful if the broker’s total reserve was otherwise too low to meet the calculated cap.
Institutional Implications and Official Perspective
Ripple’s architectural overview of the XRPL lending protocol emphasizes that the on-chain mechanism is only one part of the credit lifecycle. According to Ripple, the protocol is designed to bring "credit infrastructure" on-chain, but credit judgment, legal enforceability, and the vetting of brokers remain off-chain activities.
Financial institutions and prospective brokers are expected to use these on-chain settings as a "first-loss" buffer. However, the eventual economic recovery of defaulted funds would likely involve legal proceedings or secondary insurance outside of the XRP Ledger’s protocol. The "vault loss" represents the immediate impairment of the asset’s value on-chain, which could be reversed if a broker manages to recover funds from a borrower and performs a subsequent "recovery" transaction to the vault.
Industry analysts suggest that the design choice to cap payouts is likely intended to prevent "cascading liquidations" or the total depletion of a broker’s reserve by a single malicious or unfortunate borrower, which could leave other loans in the book entirely unprotected. By limiting the payout per default, the protocol ensures that the broker remains somewhat capitalized to cover other obligations, albeit at the expense of the depositors involved in the large default.
Broader Impact on the XRPL Ecosystem
The introduction of the lending protocol represents a significant shift for the XRP Ledger, moving it closer to becoming a full-spectrum decentralized financial hub. By enabling uncollateralized lending, the XRPL could attract institutional credit markets that find the high collateral requirements of other chains prohibitive.
However, the findings regarding loan structure and loss distribution impose a new burden of due diligence on depositors. Prospective lenders cannot simply look at the "Total Reserve" of a broker to judge safety. They must evaluate:
- Loan Granularity: Does the broker issue many small loans or a few large ones?
- Concentration Risk: Are the loans distributed among different borrowers, or do ten contracts represent the same economic entity?
- Protocol Constants: What are the fixed liquidation and minimum cover rates?
As the XRPL community moves toward a potential vote on the lending amendment, these technical nuances will likely become central to the debate. The balance between protecting the broker’s long-term solvency and protecting the depositor’s immediate principal is a delicate one. For the XRP Ledger to succeed as a lending platform, transparency regarding these "hidden" risk factors—specifically how loan sizing interacts with reserve release rules—will be paramount for maintaining market confidence.
