XRP Ledger Developers Propose Fix for Loan Repayment Rounding Issues
A loan can follow its repayment schedule and still end with a small accounting discrepancy. Rounding across installments may leave the final payment one unit higher than scheduled. XRP Ledger developers have proposed recalculating the balance from the payments still due, though existing loans may keep discrepancies that have already built up.
- The issue: Rounding differences can build up across repayments.
- The proposed fix: Recalculate the balance using the remaining schedule.
- The caveat: Some existing loans may retain a discrepancy.
- The status: The change has not been activated on mainnet.
How rounding can affect a loan’s final payment
The proposal addresses loan accounting in the XRP Ledger’s planned lending protocol. Under the calculation it describes, each installment is rounded separately. Small differences can add up, sometimes leaving the final payment one unit above the rounded scheduled payment, known in the protocol as PeriodicPayment.
Here, “one unit” means one accounting unit of the loan asset, not necessarily one XRP. For a loan denominated in XRP, the smallest unit is a drop. Other assets may use different precision. The proposal addresses rounding in loan calculations, not a one-XRP surcharge on every loan.
A proposal dated November 6 and documented in GitHub pull request #8698 would use a method called telescoping. In plain terms, the ledger would calculate the balance from the remaining repayment schedule instead of carrying forward small rounding differences from earlier installments.
Under the proposed change, each on-time LoanPay transaction would set TotalValueOutstanding to the scheduled amount for a loan with one fewer payment remaining. The adjustment would be capped at the rounded PeriodicPayment.
The proposal says an installment’s scheduled value would be rounded up or down to the nearest applicable unit, but never below one unit. For a loan following the corrected schedule, this calculation is intended to make the final installment match the rounded periodic payment.
What the code changes would do
Pull request #8698 changes the logic used by LoanSet, which establishes loan terms, and LoanPay, which processes repayments.
One commit moves the scheduled-value calculation out of computeLoanProperties and into a separate scheduledValue function. Developers say this does not change existing behavior. It lets loan creation and repayment use the same rounding method.
A second commit adds the correction under the proposed LendingProtocolV1_2 amendment. It also recalculates the remaining balance after an accepted overpayment, resetting it to the scheduled value based on the revised PeriodicPayment.
The proposal includes safeguards to prevent a negative unpaid-interest amount when calculating the principal portion of an installment. Zero-interest loans need separate handling because total loan value is rounded to the nearest unit, while principal is rounded upward.
Developers report testing the changes with the Legacy, CashBasis and FixedPrecision vault accounting models, both with and without the amendment enabled. They also tested activating the amendment while a loan is outstanding. The pull request describes this testing but does not say how often the correction would matter.
Existing loans may keep their rounding difference
The proposed fix would not necessarily erase discrepancies in outstanding loans. A loan with one unit more than its scheduled balance may keep that difference until an accepted overpayment triggers a recalculation.
The proposal also says small overpayments within existing rounding limits may be ignored. In that case, the transaction can succeed without the payment counting as an additional loan payment. The proposal does not say how often this would happen or give a general threshold for qualifying overpayments.
A lending-accounting change, not a general XRP loan offer
The proposal concerns repayment accounting in a planned lending framework. It would not change ordinary XRP transfers or make borrowing available to every XRP holder.
The framework would use Single Asset Vaults, which pool one type of asset, to fund fixed-term loans. Brokers would assess borrowers and manage credit risk outside the ledger. More consistent on-ledger accounting can keep repayments aligned with loan terms, but it cannot determine whether a borrower is creditworthy or likely to repay.
XRP Ledger version 3.4.0 included earlier lending-related changes, including closed-ended vaults and cash-basis accounting under LendingProtocolV1_1. Those changes did not put the lending framework into operation. An October review reported that the lending and vault amendments had not secured the support needed for activation. A separate maintenance amendment activated on November 4 to address transaction-processing issues, but it did not enable lending.
What needs to happen before activation?
Pull request #8698 remains open, and LendingProtocolV1_2 has not been activated on mainnet. The usual process is code review and merge, inclusion in a software release, then validator support for the amendment. An open pull request is not a validator vote.
Under the XRP Ledger amendment process, an amendment needs support from more than 80% of trusted validators for two consecutive weeks to activate. Trusted validators are the ones whose votes count toward that threshold. This is not a general vote by every XRP Ledger user. No mainnet activation date has been announced.
Key questions about the XRP Ledger lending proposal
-
What problem is the proposed change meant to solve?
Rounding differences across installments can leave the final payment one accounting unit above schedule. The proposed calculation aims to keep the outstanding balance aligned with the remaining repayments.
-
Will it correct every existing loan?
No. Some loans may retain an existing difference unless an accepted overpayment triggers recalculation. Small overpayments may not count as additional payments.
-
Is LendingProtocolV1_2 active on mainnet?
No. The amendment has not been activated, and no activation date has been announced.
-
What does the amendment need to activate?
More than 80% of trusted validators must support it for two consecutive weeks, after the code has been reviewed, merged and included in a release.
-
Does this let all XRP holders borrow?
No. It concerns accounting for loans in a planned framework using pooled assets and fixed terms. It does not create a general-purpose XRP borrowing product.
Rounding may not be the flashiest part of lending, but it matters when a ledger is expected to keep loan balances true to their terms. This proposal targets a narrow accounting problem. Whether it reaches mainnet depends on code review, release planning and validator support.
