Two XRP Ledger development proposals opened on November 4, 2026, would give lending applications a way to reject an unexpected loan identifier and retrieve a loan's descriptive data directly from its ledger record. Both remained open on November 6, with their behavior tied to the proposed LendingProtocolV1_2 amendment.
The changes address separate questions: does a transaction create the loan an application expects, and where should software look for information attached to that loan? They are development proposals in the XRP Ledger Foundation's repositories, with no mainnet activation established by these submissions.
A loan number can change before a transaction lands
In the documented lending design, a LoanBroker maintains a sequence counter that advances whenever it creates a loan. The broker's identifier and that sequence help determine the new loan's unique identifier. The number is therefore part of how other software can refer to the right agreement.
Pull request 8685 proposes an optional LoanSequence field on LoanSet, the transaction used to create a loan. The submitted code checks the supplied number against the broker's next loan sequence. If they differ, it returns a new error instead of creating a loan under the next available identifier.
The proposal describes a timing problem for applications that assemble several related operations together. An application may predict a loan identifier and prepare associated escrows, but another loan can be processed first by the same broker. Without an explicit check, the new loan can receive a different identifier from the one the application expected.
This is a proposed safeguard for that development workflow. The submission does not establish a mainnet incident or identify affected users. It also makes the new field optional, so application developers would have to supply the expected sequence to use the check.
Making a bundle fail when its assumption changes
XRP Ledger documentation describes a Batch transaction type for grouping operations. Its documentation describes four execution modes, including All or Nothing, in which every inner transaction must succeed for the group to take effect. Other modes have different rules, including allowing operations to succeed independently.
The proposed sequence check matters when lending operations are combined with escrows in an All or Nothing batch. If the expected loan number is no longer available, the failed loan operation would cause the related operations to roll back. Simply grouping transactions does not make an application's prediction about another ledger entry correct; the proposed check makes that prediction an explicit condition.
The submitted test code covers a competing loan taking the expected sequence first, followed by a batch whose escrows do not remain. It then checks a submission using the updated sequence. These are tests included in a proposed change, rather than evidence of production deployment.
Batch transactions also carry their own cost calculation. Official documentation includes an outer charge, signature charges and the costs of the inner operations. That is a separate consideration from whether a bundle succeeds, as explained in the guide to crypto transaction fees.
Putting a loan's data beside its terms
The second implementation proposal, pull request 8684, concerns the optional Data field in LoanSet. Official transaction documentation permits descriptive information of up to 256 bytes. The proposal identifies a storage gap: that information is accepted in the originating transaction but is not copied into the Loan ledger entry.
Under the proposed change, the loan record would retain that data when the relevant amendment is enabled. Applications requesting a loan through the ledger_entry or account_objects interfaces would then receive it alongside the loan record. They would no longer need to find the creation transaction solely to retrieve that field.
A companion standards proposal, numbered 680 and labeled XLS-66.3.4, sets out the same change. The existing Loan record already represents the agreement's state, including the borrower, fees, interest and outstanding amounts. The addition concerns where a small piece of descriptive information is available, rather than a new repayment formula.
Review and activation remain separate steps
Both implementation submissions place their new behavior behind LendingProtocolV1_2. A proposed code change must still pass through development before it can become a network rule. XRP Ledger documentation explains that transaction-processing amendments are included in software releases and then need more than 80% support from trusted validators for two weeks to activate.
The wider lending design also retains risks that these changes do not address. It uses pooled assets for fixed-term, uncollateralized loans, with borrower assessment and risk management conducted outside the ledger. Optional first-loss capital can absorb some losses, but the documentation says it does not eliminate credit risk.
The immediate development is narrower and useful: applications could check that they are creating the expected loan, while reading its descriptive data from the loan itself. Whether either proposal is accepted, how the final implementation is shaped and when the required amendment could activate remain open.