XRP Ledger Native Lending Is Still Short 16 Votes

The XRP Ledger’s native lending code still has 13 of 35 validator votes, less than half the supermajority it needs to go live. XLS-66, the Lending Protocol amendment, sits at 37.14 percent on the public board, and the vaults it depends on are only a little further along. The product everyone is selling is credit. The thing the network is actually about to turn on is a batch button.

XRPL Commons spent 23 September telling builders that native lending is coming, and a New York hackathon in October is already recruiting around that claim. The vote record says something slower. Validators have had XLS-65 and XLS-66 in front of them since winter, and they have treated those two files as a different class of risk from the ops upgrades now sitting in the activation window.

Lending Protocol Has 13 of 35 Validator Votes

XLS-65 (SingleAssetVault) and XLS-66 (LendingProtocol) shipped in xrpld 3.1.0 in January 2026. SingleAssetVault has been in voting since 2 February 2026. On the live validator vote counts, it has 17 of 35 yes votes, or 48.57 percent. LendingProtocol has 13 of 35, or 37.14 percent. LendingProtocolV1_1, the closed-ended vault and cash-basis rewrite that landed with xrpld 3.4.0 on 17 September 2026, has 0 of 35.

AMENDMENT BOARD

An XRPL amendment needs more than 80 percent support for two weeks before it becomes a network rule. With 35 trusted validators, that bar is 29 yes votes. Support at 80 percent or less drops the majority flag and restarts the clock. LendingProtocol still needs 16 more yes votes. SingleAssetVault needs 12. V1.1 needs 29 from a standing start. BatchV1_1 is the only one of this cluster listed as activating, and it is hanging on that 29-vote floor.

The board is tracking 105 amendments in all, with 1 activating, 10 voting, 94 already on, and 7 deprecated. Credentials, Permissioned Domains, PermissionedDEX, and TokenEscrow already made it through that filter. The credit layer is the piece that has not.

The Protocol Leaves Credit Decisions Off the Ledger

Official docs describe the Lending Protocol as a primitive for on-chain, fixed-term, uncollateralized loans drawn from a Single Asset Vault. Underwriting and credit checks stay off-chain. Loan creation, repayments, grace periods, and defaults are written on the ledger. There is no automated collateral grab and no liquidation engine of the kind DeFi pools use. The current build, the docs say, focuses on on-chain credit origination.

XLS-65 is the pool. The standard is an on-chain primitive for aggregating assets from multiple depositors and issuing Multi-Purpose Token shares for their slice of the vault. The asset can be XRP, a trust-line token, or an MPT. A vault can be public, or private and gated by Credentials. Shares can be transferable or locked to redemption. A pseudo-account holds the assets, because a Vault object cannot hold them itself.

XLS-66 sits on top of that pool. A loan broker, depositors, and a borrower are the three parties. The broker creates the vault and the loan terms. Depositors put in the asset. The borrower takes a fixed-term loan and pays it back on a schedule. Issuers can still claw back funds from a vault and freeze accounts, including a broker’s pseudo-account, which is how a regulated token is supposed to stay inside existing controls.

LOAN LIFECYCLE ON THE LEDGER

• Vault setup: A loan broker creates a single-asset vault and the matching LoanBroker entry.
• Deposits: Liquidity providers add the asset and receive vault shares.
• First-loss cover: The broker may deposit extra units of the same asset as a buffer against default.
• Origination: Broker and borrower lock terms on-chain, and principal moves to the borrower.
• Servicing: Payments hit principal, interest, and fees; missed payments open a grace period, after which the broker can default the loan.
• Close: The loan is deleted at maturity or default, cover can be withdrawn, and empty broker and vault objects can be removed.

LendingProtocolV1_1 would then restrict new loans to closed-ended vaults with a fixed Subscription, Investment, and Redemption calendar, and it would switch new vaults to cash-basis accounting so interest counts only when it is actually paid. Older vaults would keep the earlier instant-interest model. That amendment has no yes votes, so the version of lending institutions keep describing is not the version that would turn on if XLS-65 and XLS-66 passed tomorrow.

First-Loss Cover Takes 10.9 Tokens of a 1,090 Default

The protocol’s loss buffer is optional, and it is thin by design. A broker can lodge first-loss capital in a separate pseudo-account. If a loan defaults, a slice of that cover moves into the vault. The rest of the hole lands on depositors through a lower vault value. If cover falls below the broker’s own minimum, the broker cannot issue new loans and cannot take fees until the buffer is rebuilt. That is an incentive for the broker, not a guarantee for the pool.

The worked example in the protocol docs starts with 100,090 tokens in the vault, 99,000 of them free, and 100,000 shares outstanding. Debt on the book is 1,090 tokens. The broker has 1,000 tokens of cover, a 10 percent minimum cover rate, and a 10 percent liquidation rate on that minimum. A loan then defaults with 1,000 of principal and 90 of interest still outstanding, which is 1,090 tokens.

Cover pays 10.9 tokens, which is 1 percent of that default. Depositors absorb 1,079.1 tokens. Vault assets fall to 99,010.9. Cover left on the broker’s side is 989.1. First-loss capital does not make the loan safe. It makes the broker eat first, then passes almost the entire miss through to the people who filled the vault.

Impairment is the other risk tool, and it is also a broker action. If the broker thinks a payment will not arrive, it can pull the next due date forward so the loan can default faster. A payment before that date clears the flag. Credit judgment stays with the people running the book.

Clearpool and Cicada Lined Up in August

The queue in front of those amendments is already named. On 20 August 2026, Cicada Partners, Clearpool, and Ripple described an institutional credit product on the ledger that uses XLS-65 vaults and XLS-66 loans, with working-capital loans denominated in RLUSD. Clearpool is building the vault and marketplace layer and says it has originated more than $930 million in institutional loans since 2021. Cicada is the credit manager and cites more than $860 million of underwritten credit. Ripple is joining the fund as a limited partner on the same terms as other investors, not as a backstop. The fund size was not disclosed. Hex Trust is named for custody. Testing is on Devnet. Mainnet still depends on the vote.

Hussein Zangana, the dUNL validator who posts as Vet and contributes to the XRP Ledger Foundation, treated that announcement as the moment the lending work stopped being hypothetical.

Institutions are coming on to the XRP Ledger for borrowing and lending amendment with clear commitment. Not a “maybe” or “perhaps”. It’s happening.

Vet, dUNL validator, on X, 20 August 2026

He mapped the roles the same way the companies did: Clearpool on the permissioned vault, Cicada as loan broker, Ripple as depositor, and fintechs as the borrowers. XRP in that flow is for fees and reserves, not the loan asset. The partnership is real. It is also still waiting on 16 validators who have not moved.

Odelia Torteman, head of digital assets at XRPL Commons, put the same design in writing on 2 September 2026. She called native, underwritten credit the missing layer after settlement, and she described credit as protocol infrastructure rather than a DeFi app sitting on top of the ledger. The Commons essay is explicit that institutions keep underwriting, documents, collateral, and compliance, while the ledger standardises drawdown, interest, repayment, and default once those terms exist. That is the inverse of Aave-style pools, and it is why the vote is slow. Validators are not turning on a money market. They are turning on a credit-servicing machine whose quality depends on whoever is allowed to be a loan broker.

Ripple and Immunefi already ran a $200,000 Attackathon against this code, covering 35,498 lines of C++ across XLS-66, XLS-65, and related standards, with a Halborn assessment of the vault dated 27 June 2025. The contest paid out. A finished bounty does not cast a validator vote.

Batch V1.1 Is Due on September 29

While lending idles, BatchV1_1 is listed as activating on 29 September 2026. It holds 29 of 35 votes, or 82.86 percent, which is exactly the floor above 80 percent. One validator flipping to no would drop it to 28 of 35, or 80.00 percent, and the two-week clock would start over. The feature lets an account submit up to eight transactions that all settle or all fail together. That is the plumbing for delivery-versus-payment, repo-style swaps, and any loan flow that cannot leave a half-finished state on the ledger.

If XLS-66 ever turns on, Batch is how a broker wants origination, vault movement, and fee collection to fire as one unit. The network is delivering that rail first. It is not delivering the loan object. ConfidentialTransfer and DynamicMPT, which rode in the same 3.3.0 cycle, are still at 13 of 35. Sponsor is at 5 of 35. The validators who said yes to Batch have not said yes to the rest of the institutional bundle.

Permission Delegation Fell Out of Its Window

PermissionDelegationV1_1 had a cleaner story on 21 September 2026, when it entered the two-week window with 29 yes votes and an earliest go-live of 5 October 2026 at 11:18 UTC. The live board now shows 28 of 35, or 80.00 percent, and a status of Voting, not Activating. Under the written rule, support at 80 percent or less is a lost majority. The October date is dead until 29 validators hold the line again for two full weeks.

The amendment is the second try. An earlier Permission Delegation build never reached mainnet after a fee-handling flaw, and V1.1 shipped in xrpld 3.3.0 as the replacement. It would let one account grant another account limited powers, up to 10 permissions, without handing over full signing control, and those grants can be changed or revoked. A stablecoin issuer could let a compliance box approve holders while the master keys stay offline. A payments desk could send funds without the power to rewrite those keys. For the lending design, that split is how a broker, a compliance officer, and a treasury function share one vault without sharing one secret.

THE FORTNIGHT AROUND THE VOTE

1. 15 September 2026: BatchV1_1 first holds a majority, starting the two-week clock toward 29 September.
2. 17 September 2026: xrpld 3.4.0 adds LendingProtocolV1_1 for voting, with closed-ended vaults and cash-basis accounting.
3. 21 September 2026: PermissionDelegationV1_1 enters its two-week window on 29 yes votes.
4. 23 September 2026: XRPL Commons promotes a Lending and Borrowing hackathon track in New York and says XLS-65 and XLS-66 are in live voting.
5. 24 September 2026: The public board still shows LendingProtocol at 13 of 35 and SingleAssetVault at 17 of 35; PermissionDelegationV1_1 is back at 28 of 35 and listed as Voting.

The pattern is not mysterious. Safety patches and tightly scoped ops features clear the 29-vote line. A new credit primitive that can lose depositor money on an uncollateralized default does not. Mayukha Vadari, a RippleX engineer, put that caution in one line in June when asked about the stall: safety comes first, and some validators were still waiting on cleanup fixes. Those fixes have since moved. The lending votes have not.

New York Hosts a Lending Hackathon in October

XRPL Commons is not waiting for 29 validators. With the XRP Ledger Foundation, it is hosting a 36-hour in-person hackathon in New York on 24 and 25 October 2026, three days before Ripple Swell on 27 to 29 October. One of the four tracks is Lending and Borrowing, aimed at credential-based lending, secondary markets, risk tools, and interfaces on top of XLS-65 and XLS-66. RippleX, Mastercard, Ledger, and Quicknode are named as supporters on the Commons post.

Track: Lending & Borrowing ✅
Native lending and borrowing is coming to XRP Ledger.
Build the tooling, integrations, and applications for the XRP Ledger Hackathon: Lending & Borrowing Track in NYC.

XLS-65 (Single Asset Vaults) and XLS-66 (Lending Protocol) are in live validator… pic.twitter.com/WKiyaEaPWJ

— XRPL Commons (@xrpl_commons) September 23, 2026

The post tells builders that native lending and borrowing is coming, that the two amendments are in live validator voting, and that almost no other layer-1 can claim fixed-term credit in protocol rather than in a smart contract. That last point is fair. The missing clause is the vote count. Builders in New York will be writing against Devnet objects and a reference app that Ripple published for test use only. They will not be writing against a live mainnet market unless 16 more validators change their minds and then hold that majority for two weeks, after which V1.1 still has to repeat the whole process if closed-ended vaults are the product institutions actually want.

Clearpool and Cicada can keep testing RLUSD credit on Devnet. Batch can still turn on 29 September if that 29-vote floor does not crack. Permission Delegation can re-enter its window as soon as one more validator comes back. That is not native lending. Native lending is still a 13-vote object, a 0-vote rewrite, and a hackathon selling the work those votes would unlock.

Disclaimer: This article is news reporting and analysis of XRP Ledger amendment votes and related protocol documents, and it is for information only. It is not investment advice, not a recommendation to buy or sell XRP, RLUSD, or any other token, and not a credit, legal, or technical audit of the proposed lending system. Readers who may lend, borrow, or build on these features should consult a qualified financial adviser, counsel, or protocol engineer before acting. Vote counts, activation windows, and product plans change as validators vote and as software is revised, and figures here reflect the public sources cited at the time they were checked.