TL;DR: Technical documentation for the proposed LendingProtocolV1_1 amendment describes closed-ended vaults with defined subscription and redemption dates on the XRP Ledger.
XRP Ledger developers have outlined a more structured approach to lending vaults, adding a design that would let some pools run for a fixed period rather than remain permanently open to deposits and withdrawals.
The LendingProtocolV1_1 documentation introduces a VaultKind setting in the VaultCreate transaction. An open-ended vault remains the default, while a second value would identify a closed-ended vault with additional dates controlling when new subscriptions close and when redemption can begin.
Those fields matter for products that need a predictable investment period. Institutional-style lending arrangements often have subscription windows, capital lockups and maturity schedules that are harder to represent using a continuously open pool.
The proposal describes the mechanics of creating such a vault, not the launch of a live lending product. It also does not erase the credit and liquidity risks associated with on-chain lending. A technical standard can define how a position behaves, but it cannot guarantee that a borrower will repay or that a market will remain liquid.
XRPL’s broader lending discussions have attracted attention because they point to potential financial products built directly around ledger-level features rather than solely through external applications.
For now, the important question is whether validators and developers are satisfied with the amendment’s implementation and how any final version would interact with the rest of the network.
Written by the News Desk and edited by Samuel Rae.
TL;DR: Technical documentation for the proposed LendingProtocolV1_1 amendment describes closed-ended vaults with defined subscription and redemption dates on the XRP Ledger.
XRP Ledger developers have outlined a more structured approach to lending vaults, adding a design that would let some pools run for a fixed period rather than remain permanently open to deposits and withdrawals.
The LendingProtocolV1_1 documentation introduces a VaultKind setting in the VaultCreate transaction. An open-ended vault remains the default, while a second value would identify a closed-ended vault with additional dates controlling when new subscriptions close and when redemption can begin.
Those fields matter for products that need a predictable investment period. Institutional-style lending arrangements often have subscription windows, capital lockups and maturity schedules that are harder to represent using a continuously open pool.
The proposal describes the mechanics of creating such a vault, not the launch of a live lending product. It also does not erase the credit and liquidity risks associated with on-chain lending. A technical standard can define how a position behaves, but it cannot guarantee that a borrower will repay or that a market will remain liquid.
XRPL’s broader lending discussions have attracted attention because they point to potential financial products built directly around ledger-level features rather than solely through external applications.
For now, the important question is whether validators and developers are satisfied with the amendment’s implementation and how any final version would interact with the rest of the network.
Written by the News Desk and edited by Samuel Rae.
XRP Ledger validators are advancing a maintenance amendment while the network’s proposed native lending features face a more complicated path through governance.
TL;DR: The fixCleanup3_4_0 amendment has cleared the 80% support threshold in recent validator snapshots, beginning the sustained-consensus period required for activation. The separate lending amendments have not reached the same level.
The cleanup package addresses technical issues around several XRPL features, including vault and lending-related logic. That may sound routine, but enabling complex financial functions directly in a blockchain’s rules creates little room for improvisation once the code is live. Validators need confidence that edge cases are resolved before activation.
XRPL amendments require support from more than four-fifths of a server’s trusted validator list over a sustained period. A temporary majority is not enough. Recent published snapshots showed fixCleanup3_4_0 over the line and pointed toward a possible late-October activation if that support continues.
Meanwhile, native lending is still a separate matter. The presence of code in a server release does not mean the lending protocol is available for users, and the cleanup amendment should not be mistaken for a vote approving the entire feature set.
This difference can be frustrating for investors focused on new products, but it is an intentional part of the ledger’s upgrade process. Validators are effectively being asked to approve changes to shared financial infrastructure that every participant must respect.
The immediate milestone to watch is whether the cleanup amendment maintains its necessary voting support for the full activation window. Lending will require its own consensus outcome.
Written by the News Desk and edited by Samuel Rae.
TL;DR: The XRP Ledger’s BatchV1_1 amendment remains in its activation window and is expected to enable around October 9 if validator support stays above the required threshold. The upgrade allows multiple transactions to be bundled into an atomic group, replacing an earlier Batch version that was halted after a critical bug was found.
A major XRP Ledger upgrade is approaching activation after one of the more unusual validator coordination episodes in the network’s recent history.
BatchV1_1 is currently inside the XRPL amendment process and is expected to activate around October 9 if support remains above the required supermajority threshold.
The feature allows multiple transactions to be bundled together so they either succeed as a group or fail as a group.
That opens the door to more complex operations such as atomic swaps and workflows where several ledger actions need to complete together.
The route to activation has not been smooth.
An earlier version of Batch was prevented from activating after a critical issue was discovered.
Validators then coordinated around a corrected version, with support temporarily adjusted so the activation countdown could reset and the Batch amendment could arrive alongside its associated fix.
XRPL amendments require more than 80% support from trusted validators for two consecutive weeks before they can become active.
If support falls below that threshold, the clock resets.
That mechanism is deliberately conservative.
An amendment changes the rules understood by the network. Once it activates, servers that do not support the new rules can become amendment blocked and stop following the ledger correctly.
The corrected BatchV1_1 feature is therefore being paired with newer software designed to address the earlier problem.
The upgrade matters because atomic transaction groups are a basic building block for more sophisticated financial applications.
Without them, a developer may need to coordinate several separate ledger operations and deal with the possibility that one succeeds while another fails.
Batching lets the application treat those actions as one logical unit.
That can be useful for trading, tokenization and other workflows where partial execution would create risk.
The XRP Ledger has increasingly been adding features aimed at institutional assets and more complex on-chain finance.
Batch transactions fit into that broader direction, alongside work on multi-purpose tokens, permission controls and other features designed to support financial applications beyond basic XRP transfers.
The current countdown is not an absolute guarantee.
Validator support has to remain above the required level until the activation process completes.
But the network is much closer to enabling Batch than it was when the first version ran into trouble.
In some ways, the delay may be the more reassuring part of the story.
A decentralized network found a serious issue before activation, validators coordinated to stop the change, and the amendment process was reset around a fix.
Now the feature gets another attempt.
This time, the XRP Ledger is trying to make sure the batch arrives as a complete package rather than simply arriving on time.
Login