XRP Ledger developers have proposed a new lending protocol update that would correct how loan repayments are rounded, preventing small calculation differences from accumulating across scheduled payments.
Summary
- XRP Ledger developers proposed repayment rounding changes under the planned LendingProtocolV1_2 amendment for native lending.
- The correction would prevent accumulated rounding differences from making final loan installments exceed scheduled amounts.
- Developers tested repayment calculations across Legacy, CashBasis and FixedPrecision vaults under several different amendment configurations.
- Existing loans carrying rounding differences may retain them unless borrowers make qualifying overpayments during repayment.
- LendingProtocolV1_2 remains under development, with mainnet activation requiring sustained support from trusted XRP Ledger validators.
The November 6 GitHub proposal introduces changes under the planned LendingProtocolV1_2 amendment, which would align outstanding loan balances with their repayment schedules. The correction addresses cases where rounding differences can leave the final installment slightly higher than the amount borrowers were originally scheduled to pay.
The proposal remains under review and has not been activated on XRP Ledger’s mainnet. Developers have included tests covering different vault accounting methods, existing loans and situations where borrowers pay more than their scheduled installments.
XRP Ledger Lending Fix Targets Repayment Rounding
At the center of the proposal is how the XRP Ledger calculates the remaining amount owed after borrowers make payments toward a loan.
Under the existing calculation described by the developer, each installment’s value is worked out separately. Small rounding differences can accumulate as payments progress, occasionally leaving the final installment one unit higher than the rounded periodic payment.
The proposed correction introduces a calculation method known as telescoping, which uses the remaining repayment schedule to determine the outstanding balance after each installment.
Rather than allowing individual calculations to produce cumulative differences, the system would bring the outstanding value back into line with the remaining scheduled payments.
Under LendingProtocolV1_2, each on-time LoanPay transaction would reduce TotalValueOutstanding to the scheduled amount with one fewer payment remaining. The adjustment would remain capped at the rounded PeriodicPayment.
The developer’s description states that the change would make the value portion of each scheduled installment equal to either the rounded-down or rounded-up periodic payment, while keeping it at least one unit.
The final installment would then match the rounded PeriodicPayment exactly for loans following the corrected schedule.
Developers Adjust LoanSet and LoanPay Calculations
The proposed code changes involve LoanSet, which establishes loan terms, and LoanPay, which processes repayments on the ledger.
The first commit moves the calculation of a loan’s scheduled value out of computeLoanProperties and into a separate function called scheduledValue.
Developers said this initial adjustment does not change existing behavior. Its purpose is to ensure that loan creation and repayment processing use the same rounding method.
A second commit introduces the repayment correction under LendingProtocolV1_2, including adjustments to the remaining balance whenever a borrower makes an accepted overpayment.
After such a payment, TotalValueOutstanding would reset to the scheduled value calculated using the revised PeriodicPayment, allowing subsequent installments to follow the updated schedule.
The proposal includes safeguards for the principal portion of each installment, preventing calculations from leaving a negative amount of unpaid interest.
Zero-interest loans require separate handling because the loan’s total value uses rounding to the nearest unit, while the principal amount rounds upward.
Developers have tested the changes across Legacy, CashBasis and FixedPrecision vault accounting models, both with and without the proposed amendment enabled.
Existing XRP Ledger Loans Would Keep Some Rounding Differences
Although the proposed changes would correct repayment calculations going forward, they would not automatically eliminate every rounding difference attached to existing loans.
The GitHub proposal explains that older loans already carrying one unit above their scheduled balance would retain that difference until the borrower makes an overpayment.
Such loans could therefore still require a final installment equal to the rounded PeriodicPayment plus one additional unit.
Small overpayments may be ignored when they fall within existing rounding limits. In those cases, the transaction can return a successful result without charging an additional loan payment.
The developer has included tests covering amendment activation while a loan remains outstanding, allowing the revised calculations to be checked against existing repayment records.
These adjustments concern loan accounting within the proposed lending protocol. They do not change ordinary XRP transfers or establish a new borrowing product available to all XRP holders.
LendingProtocolV1_2 Still Requires Validator Approval
The repayment proposal forms part of XRP Ledger’s continuing work on native lending, which would allow fixed-term loans funded through Single Asset Vaults.
In September, crypto.news covered the lending changes introduced in XRP Ledger version 3.4.0, including closed-ended vaults and cash-basis accounting under LendingProtocolV1_1.
The proposed lending framework would use pooled assets to fund loans, while brokers would assess borrowers and manage credit risk outside the blockchain.
An October review of validator voting found that the lending and vault amendments had not secured the required support to activate.
Meanwhile, a separate maintenance amendment activated on November 4, addressing several transaction-processing issues without enabling the lending protocol.
Under XRP Ledger’s amendment process, a proposed change must receive support from more than 80% of trusted validators for two consecutive weeks before activation.
Pull request #8698 remains open, and no mainnet activation date has been announced for LendingProtocolV1_2.
