XLS-66 Lending Protocol Shows 37.14% Vote Consensus, Still Not Live

Direct answer: XLS-66 is in the voting pipeline, not a live lending market

As of August 13, 2026, the XRP Ledger's XLS-66 Lending Protocol is available for testing and mainnet voting, but it is not enabled on the production ledger. The official status page shows 37.14% vote consensus, while a validated feature response marks LendingProtocol and SingleAssetVault as supported but disabled.

Confirmed record: Ripple Open Source lists the XLS-66 specification as live on December 1, 2025, available on Devnet January 13, 2026, and open for mainnet voting with version 3.1.0 on January 27, 2026. That timeline describes readiness and governance state. It does not establish activation, customer use, deposited assets, or a live borrowing market.

Editorial boundary: not live here means the amendment was disabled in the validated feature response checked for this report. It does not mean the code is absent, that nobody is testing it on Devnet, or that no off-ledger lender offers XRP-related credit. Those are separate questions that the cited records do not answer.

Section sources[1][11][3]

What the 37.14% status record actually measures

The live XLS-66 page labels 37.14% as Vote Consensus. On the page checked for this report, that figure is not accompanied by a validator-by-validator list, a vote-weight denominator, or a projected activation date. The responsible reading is therefore narrow: 37.14% is the published consensus metric, not a measure of XRP lending volume, liquidity, users, or market share.

The XRP Ledger amendment documentation supplies the governance context. Validators vote on amendments, and an amendment passes permanently when it receives more than 80% support for two weeks. The same documentation explains that support can move below 80% before activation, which temporarily rejects the amendment and restarts the two-week period. A release being available and a feature being supported are not the same as that condition being met.

Inference, clearly labeled: because 37.14% is below the documented more-than-80% support level, the current snapshot does not show XLS-66 meeting the numeric part of the activation condition. Uncertainty remains around the future path. One snapshot cannot predict whether support will rise, fall, or remain unchanged, and the public status page does not explain why the current percentage is 37.14%.

Section sources[1][2]

Why a code release, a vote, and activation are separate milestones

XRP Ledger version 3.1.0, published January 28, 2026, introduced the SingleAssetVault and LendingProtocol amendments in the reference server implementation. That release made the functionality available to software that supports it. The validated feature response is the separate check that matters for current mainnet behavior: both features are supported, but neither is enabled in the response checked on August 13.

The release trail also shows why a protocol should not be treated as finished merely because its first implementation shipped. Version 3.1.3, published May 14, included fixes affecting Single Asset Vaults and the Lending Protocol. Version 3.2.0, published June 15, bundled additional cleanup fixes affecting those features. These records show continued software maintenance. They do not, by themselves, create an activation event or prove production usage.

Confirmed fact: the implementation exists in the supported server code path. Confirmed fact: the current mainnet feature response returns enabled false for LendingProtocol and SingleAssetVault. Unresolved question: the records reviewed here do not name a date on which those flags will change, identify the validators currently voting for or against the amendment, or promise that activation will occur.

Section sources[8][9][10][11]

What XLS-66 would add if the amendment activates

The XRP Ledger documentation describes Lending Protocol as a DeFi primitive for fixed-term, uncollateralized loans funded by pooled assets in a Single Asset Vault. A loan broker can create and manage loans, while depositors provide assets to the vault. This is a native transaction and ledger-entry design, not a promise that a ready-made public lending marketplace is already operating.

The design is deliberately different from an automated collateralized lending market. The current implementation relies on off-chain underwriting and risk management, and it uses first-loss capital to help offset defaults. The documentation says automated on-chain collateral and liquidation management are not part of the current implementation. Issuers can also use clawback and freeze controls for issued assets, while XRP itself is not an issued token.

Practical implication: activation would make a protocol primitive available to builders and risk managers. It would not automatically supply borrowers, attract deposits, set a sustainable yield, or create XRP demand. Those outcomes would require separate evidence about deployments, users, asset flows, underwriting, and risk performance. No such outcome should be inferred from a 37.14% vote metric.

Section sources[3][4][5]

Security review is evidence of work, not a launch certificate

Halborn's Lending Protocol re-audit, last updated June 12, 2026, records five findings: zero critical, zero high, one medium, two low, and two informational. Its summary says 100% of reported findings were addressed. That is useful evidence of a review and remediation process, but it is not a validator vote, an activation record, or a guarantee that the system will be used safely in every future deployment.

The finding-level statuses also matter. Halborn lists the medium issue as solved and one low issue as solved. A second low issue is marked risk accepted. One informational issue is marked risk accepted and another is acknowledged. The distinction prevents a clean-sounding summary from being mistaken for a claim that every observation was eliminated or that every operational risk is closed.

Confirmed fact: the independent audit page documents a defined scope, remediation status, and residual risk labels. Inference: that security work helps explain why the protocol remains a staged feature rather than an automatic market launch. Uncertainty: the audit does not tell readers how validator support is changing today, whether a future code change will alter the risk profile, or when mainnet activation will happen.

Section sources[12][1][2]

Implications for validators, developers, depositors, and XRP holders

For validators, the relevant operational distinction is support versus enabled state. Operators can consult the official amendment process and release notes when deciding how to configure and maintain a server, but a supported feature response is not permission to treat LendingProtocol transactions as active on mainnet. The current record supports a careful status update, not a launch announcement.

For developers, the status page's Devnet milestone is a testing signal, not a production guarantee. Builders can study the concepts and tutorials, model the broker, vault, depositor, and borrower roles, and keep assumptions explicit about amendment availability. Developers should not represent a test deployment or code path as a live XRPL lending venue without a mainnet feature check and ledger evidence.

For potential depositors and borrowers, the practical takeaway is to wait for independently verifiable activation, terms, counterparties, and risk disclosures before treating XLS-66 as a usable credit product. For XRP holders and market readers, the current record is not a dated price catalyst. It does not establish new XRP demand, protocol revenue, deposits, or adoption. Those would be separate, time-sensitive claims requiring separate primary records.

Section sources[11][2][6][3]

Confirmed facts, bounded inference, and unresolved uncertainty

Confirmed: the official XLS-66 page currently reports 37.14% vote consensus; its timeline identifies Devnet availability and a mainnet voting milestone; the validated feature response returns supported true and enabled false for LendingProtocol and SingleAssetVault; and the XRP Ledger documentation sets a more-than-80% support condition lasting two weeks for permanent amendment activation.

Bounded inference: the current record supports describing XLS-66 as a supported but inactive protocol candidate. It does not support describing it as launched, adopted, liquid, profitable, or bullish for XRP. The audit record supports saying that security review and remediation occurred. It does not support saying the protocol is risk-free or that the review guarantees a future launch.

Unresolved: the sources reviewed do not disclose a firm activation date, the reasons behind the 37.14% consensus figure, a complete current validator vote breakdown, a mainnet borrower or depositor roster, or a production loan book. Those gaps are not defects in the report. They are the boundary between what the public records establish and what would require new evidence.

Section sources[1][11][2][12]

What to watch next

The next meaningful update should be a primary-record change, not a more confident headline. Watch the official XLS-66 page for a changed consensus figure or dated activation notice, the known-amendments registry for an activation record, and a validated feature response for enabled true on both LendingProtocol and SingleAssetVault. A future release note or independent security update would add context, but neither would replace the mainnet state check.

If activation occurs, the follow-up questions are concrete: which vaults are created, what assets are deposited, which brokers publish terms, how first-loss capital is structured, whether borrowers can be verified on-ledger, and what independent risk reporting exists. Those are the records that could establish a functioning lending market. Until then, the defensible status remains supported, under vote, and disabled.

• Consensus percentage and any official activation notice on the live XLS-66 status page.
• An enabled state and activation transaction for LendingProtocol and SingleAssetVault in current XRPL records.
• A dated xrpld release, amendment update, or security disclosure that changes the protocol's production path.
• Independent evidence of mainnet vault creation, deposits, loans, terms, and risk controls after activation.
• A follow-up Halborn or equivalent review if the code scope or amendment implementation materially changes.

Section sources[1][7][11][12]