{"id":12935,"date":"2026-09-08T01:39:33","date_gmt":"2026-09-08T01:39:33","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=12935"},"modified":"2026-09-08T01:39:33","modified_gmt":"2026-09-08T01:39:33","slug":"xrp-lending-model-reveals-a-20-fold-vault-loss-gap","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=12935","title":{"rendered":"XRP lending model reveals a 20-fold vault-loss gap"},"content":{"rendered":"

<\/p>\n

\n

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.<\/p>\n

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.<\/p>\n

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).<\/p>\n

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.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Ripple bets XRPL lending can give XRP a future beyond payments as price struggles<\/h3>\n<\/p>\n

<\/span> <\/div>\n

How the same bad debt produces different losses<\/h2>\n

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.<\/p>\n

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.<\/p>\n

For this model, whose computed amounts are all representable whole tokens:<\/p>\n

Cover paid = the smallest of current broker debt \u00d7 minimum cover rate \u00d7 liquidation rate, the defaulted loan’s debt, and available reserve.<\/strong><\/p>\n

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.<\/p>\n

With both rates at 10%, the first cap is 1,000,000 \u00d7 10% \u00d7 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n\n\n\n\n\n\n
Defaulting loan structure<\/th>\nCover paid<\/th>\nVault loss<\/th>\nReserve remaining<\/th>\n<\/tr>\n<\/thead>\n
One loan of 100,000 tokens<\/td>\n10,000 tokens<\/td>\n90,000 tokens<\/td>\n190,000 tokens<\/td>\n<\/tr>\n
Ten loans of 10,000 tokens<\/td>\n95,500 tokens<\/td>\n4,500 tokens<\/td>\n104,500 tokens<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Modeled allocation using the same starting debt, reserve and two 10% cover settings. Both structures default on 100,000 tokens in total.<\/em><\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n