See more like this on Google
Share article
Share article
XRP$1.104 Ledger wants native lending, but the chain's DeFi arc is still stuck at the "waiting for validators to click yes" screen (this is fine meme, but with governance).
Enjoy articles without ads?
Register for free and get unlimited access to all articles.
What XLS-66 is trying to ship
XLS-66 (often referenced as XLS-66d, "Lending Protocol") is a proposed amendment that would add lending and borrowing primitives directly to the XRP$1.104 Ledger (XRPL). The pitch is simple: move beyond swaps and payments, and let capital on XRPL earn yield through a standard, protocol-level lending flow instead of relying entirely on app-specific smart contract systems elsewhere. [1]
The spec was introduced alongside XRPL version 3.1.0 and is credited to Ripple developers Vytautas Vito Tumas and Aanchal Malhotra, according to the proposal documentation referenced by XRPL community trackers. [2]
At a high level, XLS-66 is designed to support fixed-term loans funded by pooled liquidity with pre-set terms, where interest accrues based on those terms. The intent is to make lending a first-class feature of the ledger, not a bolt-on product.
That matters because XRPL has historically leaned into payments, token issuance, and DEX rails, while "native credit" has been the missing leg of the DeFi stool. Supporters frame lending as the last major DeFi primitive XRPL needs to compete for serious on-chain liquidity. [3]
The key design choice: no on-chain liquidations
Here's the part that will make DeFi degenerates do a double take: XLS-66 explicitly avoids complex, automated on-chain collateral and liquidation systems.
Instead of building something Aave-like (overcollateralized lending with liquidation bots fighting in the mempool), the protocol focuses on:
- Flexibility and reusability: a base set of lending objects and flows that different products can build on.
- Regulatory alignment: a structure that can plug into KYC, underwriting, and compliance workflows more naturally than anonymous liquidation-based lending.
- On-chain settlement and auditability: the ledger becomes the source of truth for ownership, repayment events, and accounting trails.
XRPL validator and community researcher Vet has summarized the philosophy bluntly: lenders are not expected to blindly send funds to unknown borrowers. The risk decision happens off-chain, including identity checks and underwriting, while XRPL handles the settlement logic and recordkeeping. [4]
That makes XLS-66 feel closer to "institutional-grade credit rails" than permissionless DeFi lending. Whether you see that as a feature or a compromise depends on what you want out of crypto.
Why XRPL wants this: yield, but with a different vibe
Native lending is ultimately about one thing: putting idle assets to work.
On most chains, yield comes from some combination of lending markets, liquidity provision, staking, or structured products. XRPL has had pieces of that story, but protocol-level lending would give the ecosystem a standardized way to structure credit products without reinventing the wheel for every app.
If XLS-66 activates, builders could create products that look like:
- fixed-term lending pools for XRP$1.104 or issued tokens
- on-chain "notes" or credit instruments with clear maturity and rate schedules
- compliant lending programs that integrate with off-chain underwriting desks
Supporters argue that XRPL's strengths, including fast settlement, built-in DEX plumbing, and a long-running validator network, make it a reasonable base layer for credit settlement. [5]
Critics will point out the obvious trade: if underwriting is off-chain, then "native DeFi lending" is not fully permissionless, and yield is not magically free. It's credit risk, just packaged differently.
The real blocker: the 80% validator approval threshold
None of this goes live unless validators approve it.
XRPL amendments typically require at least 80% validator support to pass, and that support has to be sustained long enough to be considered stable (XRPL governance commonly references a multi-week validation window for amendment activation). The idea is to prevent contentious or unstable changes from shipping off a temporary spike in votes.
Right now, XLS-66 is not over the line.
Community reporting around the proposal has pointed to support levels in the low-to-mid 60% range (one widely-circulated figure is about 62.86%), which is meaningful but still far from the 80% needed to activate. Treat that percentage as a snapshot, validator votes can move as operators update their configs, review risk, or wait for more testing.
Translation: the code may be specced, the narrative may be ready, but the chain does not care about vibes. It cares about validator consensus.
What approval could change, and what it will not
If the amendment passes, XRPL gets a native lending baseline that could attract:
- fintechs and institutions that want on-chain settlement and auditable loan records
- regulated entities that need identity-linked credit origination
- ecosystem builders who want standardized components instead of bespoke lending contracts
What it will not magically do:
- It will not eliminate default risk. Off-chain underwriting is still underwriting.
- It will not guarantee juicy yields. Rates will reflect real borrower demand and lender risk appetite.
- It will not automatically turn XRPL into an Aave competitor, because the design goals are different.
The interesting middle ground is whether XLS-66 can create a credible "credit layer" that complements XRPL's existing tokenization and DEX capabilities, while staying palatable to operators who care about compliance and operational risk.
What to watch next
Validator sentiment is the whole game here.
If support climbs toward 80% and holds, watch for a timeline discussion around activation windows, early lending pool experiments, and which wallets, explorers, and infra providers add first-class support.
If support stalls or drops, expect the usual: more revisions, more debate about risk and scope, and builders delaying launches until governance stops being a question mark.