XRP-Ledger rules can leave depositors absorbing 90% of a bad loan

A model of an XRP Ledger lending protocol shows how on‑chain rules can let depositors absorb most losses from a single large loan default even when a broker has a larger reserve on record. The protocol pools lender assets in a vault and allows a broker to originate fixed‑term, uncollateralized loans. Three on‑ledger parameters determine how much reserve can be used when a loan is declared in default.

The parameters are the actual reserve deposited (CoverAvailable), the minimum cover rate a broker must hold relative to its total debt (CoverRateMinimum), and the liquidation rate that limits how much of that minimum cover can be applied to one default (CoverRateLiquidation). The default payout equals the smallest of four values: current broker debt × minimum cover rate × liquidation rate, the defaulted loan amount, the available reserve, and any implementation rounding rules.

The model applies the XLS-66 specification and code matching release 3.3.0, announced Aug. 6. In the base case, broker debt starts at 1,000,000 tokens, the broker has deposited 200,000 tokens of reserve, the minimum cover rate is 10% (requiring 100,000 tokens of cover against the debt) and the liquidation rate is 10%. The per‑default cap in that setup is 1,000,000 × 10% × 10% = 10,000 tokens.

Under those settings, a single 100,000‑token loan that defaults draws 10,000 tokens of cover into the vault and leaves depositors to take a 90,000‑token loss, despite the broker holding 200,000 tokens of reserve. The cap applies to each default separately rather than spreading the reserve pro rata across all losses.

By contrast, dividing the same 100,000 tokens of bad debt into ten loans of 10,000 tokens each changes the outcome. The per‑default cap is recalculated after each default because broker debt falls with each write‑off. Payouts decline from 10,000 on the first default to 9,100 on the tenth. Those ten payouts total 95,500 tokens of cover, leaving the vault with a 4,500‑token loss in the modeled sequence.

The result depends on parameter settings and contract structure. Varying the liquidation rate changes results: with the same starting debt and 10% minimum cover, a 5% liquidation rate produces larger vault losses for both book structures, while setting liquidation to 100% eliminates depositor losses in the examples used. Doubling the cash reserve to 400,000 tokens did not change payouts in the base scenario because the per‑default cap already bound the payment. If available reserve is smaller than required, it becomes an additional limit on payouts.

Other implementation details affect totals. The order in which unequal loans default can change the aggregate cover paid, because each default reduces broker debt and thus the cap on the next payout. The code rounds cover upward at loan precision and rounds vault loss downward at vault precision. A broker owner can submit a default transaction only after the next payment due date plus any grace period, and a loan can be defaulted only once. The amendment registry listed LendingProtocolV1_1 as in development as of Sept. 6 and had not confirmed mainnet activation.

The protocol documentation places credit decisions, legal documentation and institution‑level controls off‑chain. Contractual terms, recovery actions and any post‑default recoveries can change eventual economic outcomes. Prospective lenders should know the two cover rates, the available reserve, current broker debt, loan sizes and borrower concentration, plus any off‑chain recovery arrangements, to understand how much reserve any single default can actually draw.