XRP Ledger Lending Protocol: Why It's Getting Fixed Before Launch

The XRP Ledger's new lending protocol hasn't gone live yet, and it's already getting a second version. Developers published a follow-up amendment, LendingProtocolV1_1, while the original LendingProtocol is still waiting for validators to approve it, so if the feature turns on, it turns on with the changes baked in from day one. I'm not an XRP person and I'm not here to tell you to use it. I'm writing about it because "fix it before it ships, not after people's money is in it" is exactly the standard I want for my own first launch. Here's what actually changed, in plain words, with the sources so you can check me.

What is the XRP Ledger lending protocol?

According to the official XRPL docs, it's a built-in feature for fixed-term loans with no collateral, paid out of a shared pot of money called a Single Asset Vault. Three parties are involved. A loan broker sets up the vault and manages the loans, depositors put assets into the vault, and borrowers take loans and pay them back on a schedule.

Two things make it different from most DeFi lending you've seen. First, there's no automatic liquidation. On a typical DeFi lending app, you lock up more than you borrow, and if prices move against you, a bot sells your collateral. Here, the docs say the protocol "relies on off-chain underwriting," meaning a human or company checks whether the borrower is good for it, the way a bank would. Second, the main safety net is "first-loss capital": money the broker deposits that gets used up first when a loan defaults. The docs are honest about its limits, saying it "doesn't eliminate credit risk." Their own worked example shows a 1,090-token default where the cover pays back 10.9 tokens and the vault eats the other 1,079.1.

Token issuers also keep compliance tools. They can freeze accounts and claw back funds from the vault side. So this is built for institution-style credit, not anonymous degen borrowing.

Why can it be fixed before it goes live?

This comes down to how the XRP Ledger ships rule changes. New features arrive as "amendments," and the known amendments page explains that an amendment only turns on if it holds a supermajority of trusted validators for at least two weeks. That supermajority is 80%, according to the same page. Validators are the servers that agree on each new ledger, so they're the ones voting.

That waiting room is what makes this possible. Decrypt reports that the original LendingProtocol amendment is still open for voting, and the lending docs now list both LendingProtocol and LendingProtocolV1_1 as requirements for the feature. Instead of launching the first version and scrambling to patch it with real loans on the books, the second version goes through the same vote.

What does the second version actually change?

This is where I'd push back a little on the "repair" headline. Decrypt frames V1_1 as correcting issues in the original. But read the official description on the known amendments page and it sounds more like a design change than a small bug patch. It adds "closed-ended" vaults with three phases: subscription (when deposits come in), investment (when loans go out) and redemption (when depositors get paid back). After it's enabled, new loan brokers can only be created against these closed-ended vaults.

It also switches to "cash-basis accounting." In plain words, the vault only counts interest as income when a borrower actually pays it. Under the old model, all the scheduled interest was counted the moment the loan was made. That's a meaningful change. Counting interest you haven't received yet can make a vault look healthier on paper than it really is, especially if borrowers later default.

It's not the only lending-related change in the queue, either. Several cleanup amendments on the same page, like fixCleanup3_3_0 and fixCleanup3_4_0, list precision, rounding and default-handling fixes for the lending protocol and vaults. So "repaired before launch" is accurate, but it's more than one patch.

Why the caution makes sense right now

The XRP Ledger just had a real scare. Earlier this month, its maintainers published a vulnerability disclosure report about an integer overflow in the payment engine. A researcher reported it through the bug bounty program on September 22. Using hundreds of specially crafted offers and one payment, an attacker could have created XRP from nothing and spent it.

The part that stuck with me: the ledger has a built-in safety check that confirms no transaction creates XRP. That check did the math the same broken way, so it wrapped around identically and caught nothing. The report says the bug had likely been there since the payment engine was written in 2015, that the fix shipped in xrpld 3.4.1 on September 25, and that they found no evidence it was ever exploited.

That's a decade of code running in public, and the guardrail shared the same blind spot as the thing it was guarding. After a lesson like that, slowing down a brand-new lending feature before money touches it looks like the right call, not an embarrassment.

What I'm taking from this for my own launch

I don't run a blockchain, but the same rules scale down to a memecoin and the stuff around it. Here's what I'm keeping:

• Changes before launch are cheap. Changes after launch cost people money. If something feels off in the setup, the time to fix it is before anyone buys in, even if that means pushing the date.
• A check is only as good as its independence. The XRPL safety check failed because it used the same math as the code it was checking. When I verify a launch, I want a second method, not the same tool run twice.
• Say what changed, out loud. The XRPL team published both amendments and a full write-up of the bug. If I change anything about a launch, it goes on the Legion roadmap before it happens, not in a quiet edit after.
• Read the actual docs, not just the headline. "Repairs its lending protocol" and "adds closed-ended vaults with cash-basis accounting" are pretty different stories. The second one only shows up if you open the source.

What this doesn't tell you

To be fair, a lot is still open. I couldn't see a live vote count for either amendment, so I can't tell you whether LendingProtocol is anywhere near activating. Neither the docs nor Decrypt say exactly which problems in the original pushed the second version, beyond what the amendment description lists. And a careful release process doesn't mean the code is safe. The 2015 bug made it through years of reviews before a bug bounty hunter found it.

It's also worth being clear about who this is for. Uncollateralized loans backed by off-chain underwriting mean you're trusting the broker's judgment, and first-loss cover is a cushion, not a guarantee. If you ever see a yield product built on top of this, that tradeoff is the first thing I'd want explained.

What I'm watching next

Whether LendingProtocol and LendingProtocolV1_1 actually reach the 80% bar, and whether the first vaults launch with clear public terms for depositors. For another look at how a network's validators shape what happens on it, my read on Solana network health digs into concentration on our side of things. Big headlines land on the live crypto news page, and if you're new here, start with why I built this home base.

The takeaway: the best time to fix code that holds other people's money is before it holds any, and the best safety check is one that doesn't share the original's blind spots. If you're building anything, or putting money into something someone else built, ask what changed before launch and who checked it independently.

Still building. Still here. 🫡