XRP lending model leaves depositors with 90% of a bad loan’s loss despite reserves twice its size

The value backing depositors' shares in a modeled XRP Ledger loan book falls by 90,000 tokens when one loan defaults, compared with 4,500 when the same 100,000 tokens of bad debt sits in ten smaller loans. Both books start with 1 million tokens of debt, a 200,000-token reserve and identical protection settings.

The 20-fold gap comes from how the documented lending rules release that reserve. Each default gets a separate cover calculation. Loan size therefore changes how much loss reaches depositors, even when the total unpaid debt and the capital available to absorb it stay the same at the outset.

XRPL's lending design pools assets in a vault and extends fixed-term, uncollateralized loans through a broker responsible for underwriting. Depositors hold shares in the vault, whose value falls when the assets backing them suffer losses. The pooled asset can be XRP, a trust-line token or a Multi-Purpose Token (MPT).

CryptoSlate's comparison models that immediate write-down using documented rules and matching 3.3.0 release code, announced Aug. 6. The figures are hypothetical. Mainnet activation was unconfirmed in the official amendment registry checked Sept. 6, which listed LendingProtocolV1_1 as in development. Prospective lenders need the loan sizes and payout settings behind a reserve to judge its protection.

How the same bad debt produces different losses

Three fields govern the protection. CoverAvailable is the reserve actually deposited. CoverRateMinimum sets how much cover the broker must maintain relative to its debt. CoverRateLiquidation determines how much of that minimum required cover can be used for one default.

The payout calculation uses minimum required cover. In the base example, the broker has deposited 200,000 tokens, but the 10% minimum requires 100,000 against its 1 million of debt. The 10% liquidation rate applies to that 100,000 minimum, producing a 10,000-token cap. The XLS-66 specification describes the mechanism, and the pinned LoanManage implementation also caps the payment by the cover actually available.

For this model, whose computed amounts are all representable whole tokens:

Cover paid = the smallest of current broker debt × minimum cover rate × liquidation rate, the defaulted loan's debt, and available reserve.

After each default, broker debt falls by the full amount defaulted. The reserve falls by the amount paid into the vault. The next loan's payout is calculated using those updated balances.

With both rates at 10%, the first cap is 1,000,000 × 10% × 10%, or 10,000 tokens. A 100,000-token loan therefore gets 10,000 of cover and leaves 90,000 of vault loss, even though the broker began with enough reserve cash to absorb the entire default.

The comparison uses two loan books that were already originated in different structures. Each has the same 900,000 tokens of performing debt and 100,000 of debt that defaults. One holds that defaulting debt in a single loan; the other holds it in ten loans of 10,000 each.

The base case uses zero interest and fees, with every default eligible to be declared by the broker. There are no intervening repayments, recoveries, new loans, changes in reserve funding or interest balances, or vault deposits and withdrawals. Transaction fees and ledger owner reserves sit outside the calculation.

For interest-bearing loans, default debt also includes the vault's remaining interest entitlement, net of broker management fees. The code rounds cover upward at loan and asset precision, and vault loss downward at vault precision. The base example's whole-token results are unaffected; fractional balances require those rounding rules.

Modeled allocation using the same starting debt, reserve and two 10% cover settings. Both structures default on 100,000 tokens in total.

For the ten-loan book, the first default receives 10,000 tokens of cover. Broker debt then drops to 990,000, making the second payout 9,900. The sequence continues down to 9,100 for the tenth loan.

Those payouts total 95,500 tokens. The losses passed to the vault run from zero on the first loan to 900 on the last, totaling 4,500. Dividing the single-loan loss of 90,000 by 4,500 gives the headline's factor of 20.

The reserve remains sufficient throughout. After ten defaults, 104,500 tokens of cover remain, above the 90,000 minimum required against the remaining 900,000 debt. The gap occurs without the broker running out of cover or falling below its required minimum.

The comparison concerns loan books formed with different contract structures. A single loan can be defaulted only once. Contract count also says little about borrower diversification: ten contracts can still represent concentrated economic exposure.

Which settings and controls change the result

The 20-fold result belongs to this particular comparison. Under the same base settings, dividing the defaulting debt into two equal loans leaves 80,500 tokens of loss; five leaves 52,000; twenty leaves none in this model.

Changing the liquidation rate produces another range of outcomes:

Modeled losses. Starting debt stays at 1 million tokens, reserve at 200,000 and the minimum cover rate at 10%; only the liquidation rate changes.

Adding cash alone has a different effect. Doubling the starting reserve to 400,000 tokens leaves the base-case payouts unchanged because the per-default limit already binds. If available reserve is too small, it becomes a further constraint on payouts.

For example, an already-undercovered broker with only 50,000 tokens available could pay no more than that across the ten defaults. The documentation bars brokers below minimum cover from issuing new loans.

Processing order also matters for unequal loans. Under the base settings, defaulting 90,000 tokens and then 10,000 produces 19,100 of cover; reversing the order produces 19,900. Reordering the ten equal loans does not change their result. This sensitivity makes default procedures relevant alongside the loan-size distribution.

The cover settings are consequential choices at broker creation. LoanBrokerSet documentation permits subsequent changes only to Flags, Data and DebtMaximum. The two cover rates are fixed. A top-up increases available reserve; the fixed cover rates remain the same. Extra cash helps when reserve availability limits the payment.

DebtMaximum limits aggregate broker debt. It does not promise that a particular large default will be fully covered. To assess protection, prospective lenders would need both cover rates, available reserve, current debt, loan sizes and borrower concentration, along with the contractual support and recovery terms outside the model.

Default timing also rests with the broker. The inspected implementation requires the broker owner to submit the default transaction after the next payment due date plus grace period has expired. Impairment can move a future due date forward. Once a loan is defaulted, it cannot be defaulted again.

Ripple's description of the design places credit judgment, legal documentation and institution-specific controls off-chain. Additional contractual support or later recoveries could change the eventual economic loss. The reserve calculation alone cannot establish those rights or their value.

For a prospective XRP lender, the decisive disclosure is how much of the reserve each plausible default can actually draw. In this example, 200,000 tokens of first-loss capital coexists with either 90,000 or 4,500 tokens of depositor loss, depending on the loan book it protects.