XRP Ledger 3.4.0 Ships Code the Vote Has Not Enabled

The XRP Ledger lending protocol is still 17 yes votes short of the 28 it needs, even as xrpld 3.4.0 carries a September 15, 2026 milestone with its v1.1 code. Trusted validators on the default Unique Node List stand at 11 of 35 in favor, which is 31 percent. Activation still needs more than 80 percent, held for 14 days.

That gap is the whole story. A new server build can put loan code on disk. It cannot open a credit market on mainnet.

Eleven of 35 Cannot Open Native Loans

xrpldashboard, reading XRPL Foundation validator history at 03:41 UTC on September 11, 2026, counted 11 of 35 trusted validators voting yes on LendingProtocol. The same snapshot put SingleAssetVault at 14 of 35, or 40 percent. Both amendments have to be live for the lending stack to function. The threshold on a 35-seat Unique Node List is 28 yes votes.

LendingProtocol has been on the ballot since February 2, 2026, after xrpld 3.1.0 shipped on January 28, 2026. Official docs still label the page “Lending (Open for Voting).” XRPSCAN recorded ripple.com among the yes voters in its August log. The September 11 count is still 11.

WHERE THE UNL STANDS

The cleanup amendment had already crossed 80 percent. xrpldashboard timed majority at 11:15 UTC on August 28, 2026, and projected activation at 11:15 UTC on September 11, 2026 if that majority held for the full window. Native lending did not join it. Lending still needs 17 more yes votes. The vault still needs 14. A default Unique Node List of 35, with a quorum of 28, is the whole electorate for this change.

In July, slow software upgrades were a fair explanation, because a validator that had not installed the binary could not vote yes. That excuse is stale. XRPSCAN’s node mix on September 10, 2026 showed 622 of 790 nodes on xrpld 3.3.0 and only 6 on 3.4.0. Most seats can vote. They are not voting yes.

XRPL 3.4.0 Reaches a September Release Candidate

Vet (@Vet_X0), a default UNL validator, wrote on September 10, 2026 that “The XRP Ledger Lending protocol will receive v1.1 update in XRPL 3.4.0 next week” and that it “improves on important aspects of Lending v1.0.” XRP Ledger Operations posted the same day that “Lending v1.1 ships in XRPL 3.4.0.” GitHub already carries the 3.4.0-rc1 tag from September 3, 2026, after 3.4.0-b1 on August 25. The 3.4.0 milestone is due September 15, 2026, with 149 of 149 issues closed.

HOW THE BINARY GOT HERE

1. January 28, 2026: xrpld 3.1.0 is released and the lending code is in a production-line binary.
2. February 2, 2026: LendingProtocol is open for mainnet voting.
3. August 6, 2026: xrpld 3.3.0 is released, with six new amendments aimed at Multi-Purpose Token work.
4. August 25, 2026: the 3.4.0-b1 tag lands.
5. September 3, 2026: 3.4.0-rc1 is tagged.
6. September 15, 2026: the 3.4.0 milestone is due.

The known-amendments list still files LendingProtocolV1_1 under amendments in development. That is the companion change Vet says has to travel with v1.0. A merged pull request named featureLendingProtocolV1_1 gates an optional MemoData field on VaultDelete, with a default vote of No. The XLS-66 lending protocol specification remains Draft, requires XLS-65 and XLS-64, and names Vytautas Vito Tumas and Aanchal Malhotra as authors.

The beta notes add ledger metadata fields and cleaner vault_info errors. They do not create a live loan book on mainnet. Shipping v1.1 in 3.4.0 puts another amendment in the queue. It does not close the 17-vote hole on v1.0.

PermissionDelegation already showed how a “V1_1” suffix works on this ledger. The first version was pulled after a bug, then rebuilt. Lending is picking up a 1.1 patch before 1.0 has ever turned on. Builders get a moving target. Validators get another reason to wait.

Off-Chain Underwriting Is the Actual Product

Call it DeFi if you want. The design is a settlement rail for credit decisions made somewhere else. Official docs describe fixed-term, uncollateralized loans drawn from a Single Asset Vault, with no automated on-chain collateral or liquidation in the current build. Brokers underwrite borrowers off-ledger, then the protocol records the loan, the schedule, and a default.

In building the protocol, we made a deliberate choice to keep credit judgement off-chain, and standardize execution onchain. This is the core design principle.

Ripple, XRPL Lending Protocol note, June 29, 2026

Ripple’s note said a chain should not replace credit teams, legal files, or local rules. Institutions would keep credit judgement off-chain. The ledger would pool one asset, originate the loan, accrue interest, and process a default once terms are agreed. Ripple contrasted that with Aave, Compound, Maple, and Clearpool, arguing those books mix underwriting into protocol logic that can change under a lender.

The vault holds XRP, a trust line token, or a Multi-Purpose Token. Depositors receive vault shares as an MPT. A loan broker, on the same account as the vault owner in the current spec, issues loans from that pool. Ripple’s worked example is a payment firm holding RLUSD that needs cash for 48 hours and borrows against expected inflows instead of a bank line priced at 300-400bps. KYC, underwriting, and contracts are supposed to happen before anything hits the ledger. A public demo on devnet says the same thing on the first screen.

That is why some UNL operators treat this as a base-layer credit product, not a yield farm. If a bug lands in protocol code, every vault inherits it. June’s public case for delay was a stack of reviews (Immunefi, Sherlock, Halborn). Those reviews are months old. The yes count is still 11 of 35.

What First-Loss Capital Covers in a Default

The protocol’s safety story is optional first-loss capital, not a 120 percent collateral ratio. A broker can park the same asset in a pseudo-account so that, on default, some of that cover moves into the vault before depositors take a mark. Docs are plain: the buffer does not wipe out credit risk. It puts the broker’s own funds first, and only up to the rates the broker set.

THE THREE PARTIES ON A LOAN

• Loan brokers: They create the vault, set fees and cover rates, underwrite the borrower off-chain, and can impair or default a loan after a grace period.
• Depositors: They put one asset in the vault and hold shares. Their protection is the broker’s cover, if any, plus whatever the underwriting was worth.
• Borrowers: They take a fixed-term principal, pay on a schedule, and can be frozen by an issuer, which stops payments but does not cancel the debt.

The documentation’s own numbers show how thin that buffer can be. A vault with 100,090 tokens total and 99,000 available sits against 1,090 tokens of protocol debt. CoverRateMinimum is 0.1. CoverRateLiquidation is 0.1. CoverAvailable is 1,000. The loan has 1,000 of principal and 90 of interest outstanding, so a full default is 1,090 tokens. Cover paid into the vault is the minimum of (1,090 × 0.1) × 0.1 and 1,090, which is 10.9 tokens. Depositors absorb 1,079.1. In that example the cover meets 1 percent of the default.

Brokers pick those two rates. A pool can be stricter. A pool can also be this loose, and the ledger will still process the loan. If available cover falls below the minimum, the broker cannot issue new loans and cannot take fees; those fees go to refill cover. Issuers can claw back some first-loss funds on trust line tokens and MPTs, though not down through the minimum. They can freeze a borrower, which blocks repayment and leads to default. That is not a liquidation engine. It is credit, with a broker in the middle.

Fees are configurable too: a management cut on interest, an origination take from principal, a service fee on each payment, plus late and early payment charges. If cover is short, the protocol will not pay those fees to the broker. Depositors still face the 1,079.1-token style loss if the broker set the example rates and a loan blows up.

Two Weeks Above 80 Percent, or the Clock Resets

XRP Ledger changes that affect transaction processing do not go live because a GitHub tag exists. They go live when trusted validators vote them on. Docs say an amendment needs more than 80% support for two weeks. If support drops to 80 percent or below, the two-week clock starts again. The network checks this around every flag ledger, every 256 ledgers, roughly every 15 minutes.

THREE STAGES PEOPLE KEEP MERGING

• Code in a binary: The function exists in xrpld. Operators can install it. Mainnet rules have not changed.
• Amendment on the ballot: Validators can vote. A default vote in the source, No for SingleAssetVault on the latest stable release, applies if the operator never sets a preference.
• Enabled on mainnet: More than 80 percent held for 14 days. Then an EnableAmendment pseudo-transaction fires and the new rules apply to later ledgers.

Clawback sat in voting for 152 days before it enabled on February 8, 2024, per XRPSCAN. LendingProtocol has been open since February 2, 2026. Months of security work were the stated reason the yes votes moved slowly through the spring. A default No does not expire. One reply on a September 9 thread about the stall put the blunt version: there is little extra reason for a validator to bother. The UNL is not paid a bonus for flipping credit on.

xrpldashboard counted 93 amendments already live on mainnet, 11 still in-flight, and 1 in a 14-day countdown, against validated ledger 106904205 at fetch. BatchV1_1 sat at 25 of 35, or 71 percent. PermissionDelegationV1_1 sat at 17 of 35, or 48 percent. Those figures are a picture of a network that will pass a cleanup with 31 of 35 and still leave a loan book in the teens.

Servers that lack the code for an enabled amendment become amendment blocked. They cannot validate, submit, or vote until they upgrade. That is a reason to install 3.4.0 when it is stable. It is not a reason to talk as if loans already clear.

The September 11 Space Cannot Cast a Vote

XRP Ledger Operations scheduled a Space for September 11, 2026 at 1 p.m. EST on why v1.1 matters, what is new, and what it unlocks. The billed speakers were XRPL Foundation CTO Angell Denis, RippleX head of engineering Ayo Akinyele, RippleX head of product Jazzi Cooper, and RippleX engineer Vito Tumas, who is also on the XLS-66 spec. Vet invited listeners the day before.

Lending v1.1 ships in XRPL 3.4.0

Join us on why it matters, what's new, and what it unlocks.

• @angell_denis CTO, XRPLF
• @ja_akinyele Head of Engineering, RippleX
• @jazzicoop Head of Product, RippleX
• @v_tumas Senior Software Engineer, RippleX
https://t.co/jbIxkCPxv3

— XRP Ledger Operations (@XRPLOperations) September 10, 2026

A software tag, a Space, and a milestone date are easy to flatten into “native lending is live.” Some posts on X did exactly that after the Operations note. The ledger’s own rules say otherwise. Until 28 of 35 trusted validators hold yes for 14 days on LendingProtocol and on SingleAssetVault, a depositor cannot fund a mainnet vault share that pays interest from an on-ledger loan. Devnet can keep demoing brokers, depositors, and borrowers. Mainnet stays a payments and tokenization chain with the credit layer still in source.

v1.1 can still ship in the 3.4.0 binary around the September 15, 2026 milestone. Validators can still leave the default No in place. The 17 missing yes votes are the switch, and they are not on the Space stage.

Disclaimer: This article is news reporting and analysis of XRP Ledger software and amendment votes. It is informational only and is not investment, trading, legal, or credit advice. It does not recommend buying, selling, or holding XRP, RLUSD, vault shares, or any loan product, and it does not assess whether any broker, vault, or borrower is sound. Readers should consult a qualified financial adviser and, where a loan or deposit is involved, a licensed credit professional before acting. Vote counts, software tags, and amendment statuses reflect the sources named above as of September 11, 2026 and can change at the next flag ledger.