XRP Ledger Repayment Proposal Targets Final Installment Rounding Gap
Tapanito’s Nov. 6 proposal remains under review. The change is not active on Mainnet.

Tapanito has proposed a change to XRP Ledger loan repayments that would prevent a rounding difference from adding one accounting unit to a future loan’s final installment.
The Nov. 6 proposal remains under review. It targets LendingProtocolV1_2, a proposed lending revision still marked unsupported in the development branch. The repayment change is not active on Mainnet.
The current calculation works out scheduled installments separately. Small rounding differences can accumulate, leaving the last payment one accounting unit above the rounded periodic payment. That unit is part of the loan calculation; the proposal assigns it no dollar value and does not say every loan is denominated in XRP.
Under the proposal, an on-time payment would set the outstanding balance in line with the remaining schedule. After an accepted overpayment, the balance would be recalculated using the revised periodic payment. Loan creation and repayment would also use the same rounding calculation.
The proposed tests cover three vault accounting types — Legacy, CashBasis and FixedPrecision — both with and without the amendment. The change addresses the recorded repayment balance. It does not change how borrowers are assessed.
The planned lending system would use pooled funds in single-asset vaults to make fixed-term loans without on-chain collateral. Borrower underwriting and risk management would take place off-chain. A loan created before the repayment change takes effect could still carry an extra accounting unit into its final installment unless the borrower makes an overpayment.
The repayment proposal is separate from a cleanup amendment that took effect Nov. 4. At 9 p.m. ET Nov. 8 (02:00 UTC Nov. 9), the earlier LendingProtocol and LendingProtocolV1_1 amendments each had 21 votes from 35 trusted validators, below the 29 needed. Those figures do not measure support for LendingProtocolV1_2.
The repayment fix must pass code review and enter a software release before it can reach the network’s amendment process. Activation would then require more than 80% support from trusted validators for two weeks.