XRP Ledger Lending Fix Awaits 80% Validator Vote to Spare Borrowers the Extra Unit

Repayment Fix Detailed in Pull Request 8698

Vault operators and borrowers who use the XRP Ledger's native lending protocol are the parties a newly published code change is written for. The fix tidies how loan repayments are rounded, and it is set out in pull request 8698 against rippled, the reference server software that runs the XRP Ledger, the layer-1 network behind XRP. Once active, the change would make the balance after every payment match the loan schedule exactly instead of drifting by small amounts across the life of the debt.

Two bookkeeping terms carry the whole proposal. TotalValueOutstanding is the running measure of what a borrower still owes at any point, while PeriodicPayment is the scheduled amount each on-time installment is supposed to clear. Under LendingProtocolV1_2, each on-time LoanPay would carry TotalValueOutstanding down to the scheduled value, one payment fewer in total and never above the rounded PeriodicPayment. When a borrower overpays, TotalValueOutstanding resets to the scheduled figure for the restructured PeriodicPayment. Small rounding differences sound trivial, but a ledger that settles loans programmatically needs its arithmetic to be deterministic, since every node must reach the same balance after the same transaction.

The amendment extends the ledger's push into native lending, a market usually filed under DeFi, and it sits on the same chain as Ripple's RLUSD, with half issued on the XRP Ledger. The change is a code-level correction to loan accounting, so it has no direct bearing on the XRP price today; its real effect lands on the XRP ecosystem's lending stack, where issuers set loan terms and borrowers follow the schedule.

How Rounding Drifts Across Loan Payments

The current implementation prices each payment's value component in isolation. Because of that, rounding errors accumulate over a loan's life: a final installment can end up demanding one unit more than the rounded PeriodicPayment, and the value components of consecutive payments can alternate up and down instead of holding steady. The pull request's first commit lifts the scheduled-value calculation out of computeLoanProperties and into its own scheduledValue function, with no behavior change on its own. Routing both sides through one shared routine means LoanSet, the transaction that creates a loan, and LoanPay, the transaction that records a payment, round the figure the same way.

Loans written without any APY also need a floor on the principal part, since their value rounds to nearest while the principal rounds up. The core of the fix is a method the developers call telescoping. It sets the value component of each on-time payment at the floor or the ceiling of PeriodicPayment, and never below one unit. The last installment then lands exactly on the rounded PeriodicPayment, closing the gap that used to surface at the end of the schedule and removing the alternating pattern between installments. Vaults are the ledger's pooled credit structures, and testing covered Legacy, CashBasis and FixedPrecision vaults, run both with and without the amendment active so reviewers can isolate its effect.

Where the 80% Validator Vote Stands

Our reading is that the amendment is aimed at issuers and vault tooling far more than at everyday borrowers. Users and investors feel little to no effect today: the extra unit on a final payment changes little in practice, and older loans that already carried one unit above their schedule keep it, so the last installment still needs the PeriodicPayment plus a single unit unless the borrower overpays first. Small overpayments are mostly ignored, the transaction still succeeds and no extra XRP is charged. The ledger's credit stack, which also reaches into PayFi settlement, gets cleaner arithmetic without any migration burden on existing loans.

The party that has not moved is the validator set. Activation requires agreement from 80% of validators sustained for two weeks in a row, and no public vote on LendingProtocolV1_2 has been announced yet, so the activation date remains undetermined. The open question is timing rather than merit: the code and its tests exist, and the missing piece is the vote itself.