Developers working on the XRP Ledger have suggested an update to the lending protocol aimed at refining how loan repayments are rounded. This change seeks to eliminate minor discrepancies in calculations that could build up during scheduled payments.
Summary
- The suggested changes concerning repayment rounding are part of the planned LendingProtocolV1_2 amendment for native lending.
- This adjustment aims to prevent cumulative rounding discrepancies from causing the last loan payments to exceed their intended amounts.
- The developers have run tests on repayment calculations involving Legacy, CashBasis, and FixedPrecision vaults, across various configurations of the amendment.
- Current loans with existing rounding differences may still carry those inconsistencies unless borrowers make certain overpayments during repayment.
- LendingProtocolV1_2 is still in the development phase, and its mainnet activation will rely on ongoing backing from trusted XRP Ledger validators.
On November 6, a proposal on GitHub introduced updates under the forthcoming LendingProtocolV1_2 amendment, aimed at reconciling outstanding loan balances with their respective repayment plans. This correction targets scenarios where rounding errors can cause the final payment to be slightly higher than what borrowers initially agreed to pay.
The proposal is presently under evaluation and has not yet been deployed on the XRP Ledger’s mainnet. Developers have executed tests covering various vault accounting strategies, alongside existing loans and instances of borrowers exceeding their scheduled payments.
Update to XRP Ledger Lending Aims at Payment Rounding Issues
Central to this proposal is the manner in which the XRP Ledger calculates the remaining amount owed by borrowers as they make payments on their loans.
According to the developers, the current approach evaluates each installment in isolation. This method can lead to small rounding errors compounding over time, sometimes resulting in the last payment being slightly higher than the expected periodic payment.
The proposed update suggests a telescoping calculation method, which uses the remaining payment schedule to accurately determine the outstanding balance after each payment.
This approach aims to prevent individual calculations from generating cumulative discrepancies, ensuring the outstanding amount aligns with the remaining scheduled payments.
Under the LendingProtocolV1_2 framework, every on-time LoanPay transaction would reduce the TotalValueOutstanding to the scheduled amount while decreasing the number of remaining payments by one. This adjustment will be capped at the rounded PeriodicPayment.
The developer’s documentation indicates that this change would ensure each scheduled installment matches either the rounded-up or rounded-down periodic payment, maintaining a minimum value of one unit.
As a result, the last payment would accurately correspond with the rounded PeriodicPayment for loans adhering to the refined schedule.
Modifications to LoanSet and LoanPay Calculations
The suggested code updates involve LoanSet, which defines loan terms, and LoanPay, the function processing repayments on the ledger.
The initial commit shifts the computation of the scheduled value for a loan from computeLoanProperties to a dedicated function called scheduledValue.
Developers note that this initial change retains current functionality, primarily aimed at harmonizing rounding methods applied during loan setup and repayment processing.
A subsequent commit incorporates the repayment adjustment within LendingProtocolV1_2, adjusting the remaining balance whenever a borrower makes an recognized overpayment.
Following such a payment, TotalValueOutstanding would revert to the scheduled value computed with the updated PeriodicPayment, enabling subsequent payments to adhere to the adjusted schedule.
Safeguards are also integrated for the principal amount of each installment, preventing any calculations from leading to negative outstanding interest.
Loans without interest necessitate distinct handling, as the total loan value rounds to the nearest unit, while the principal rounds upward.
Developers have trialed the changes across Legacy, CashBasis, and FixedPrecision vault accounting systems, both with and without the proposed amendment activated.
Pre-existing XRP Ledger Loans May Retain Rounding Variances
While the proposed changes aim to enhance repayment calculations moving forward, they won’t automatically resolve all rounding discrepancies attached to existing loans.
The GitHub proposal outlines that older loans already exhibiting a one-unit surplus compared to their scheduled balance will retain this difference unless the borrower opts for an overpayment.
Consequently, these loans may still necessitate a final payment comprising the rounded PeriodicPayment plus an additional unit.
Minor overpayments might be disregarded if they fall within the existing rounding thresholds, allowing the transaction to be processed successfully without incurring an extra loan payment.
Developers have incorporated tests to assess amendment activation while loans remain active, enabling revised calculations to be validated against current repayment records.
These adjustments focus solely on loan accounting within the proposed lending protocol and do not alter standard XRP transactions or introduce a new borrowing option for all XRP holders.
LendingProtocolV1_2 Still Needs Validator Consent
This repayment proposal is part of XRP Ledger’s ongoing efforts in developing native lending capabilities, which would facilitate fixed-term loans financed via Single Asset Vaults.
In September, crypto.news reported on lending modifications launched in XRP Ledger version 3.4.0, noting closed-ended vaults and cash-basis accounting features within LendingProtocolV1_1.
The intended lending framework will rely on pooled assets to finance loans, while brokers will evaluate borrowers and manage credit risks outside the blockchain.
An October validator voting review highlighted that the lending and vault amendments have yet to secure the necessary support for activation.
Meanwhile, an unrelated maintenance amendment was activated on November 4, addressing several transaction-processing challenges without initiating the lending protocol.
According to XRP Ledger’s amendment process, any proposed change must gather over 80% support from trusted validators for two consecutive weeks before it can be activated.
The pull request #8698 is still open, and a mainnet activation date for LendingProtocolV1_2 has not yet been disclosed.