XRP Ledger developers have released xrpld version 3.4.0 on Sept. 16, adding two amendment packages that revise proposed native lending functions and harden several transaction paths while asking server operators to upgrade.
- XRPL version 3.4.0 introduces two amendments covering lending changes plus a bundled protocol-fix package now.
- LendingProtocolV1_1 adds closed-ended vaults and cash-basis accounting, but mainnet activation still requires sustained validator consensus.
- Server operators are urged to upgrade quickly as XRPL Foundation now distributes signed Linux packages.
- fixCleanup3_4_0 hardens vaults, AMMs, MPTs, escrow, signing, credentials, and permissioned trading behavior across transaction paths.
- The new lending amendment depends on XLS-65 and XLS-66, which remain below activation thresholds.
XRPL’s official release says version 3.4.0 introduces LendingProtocolV1_1 and fixCleanup3_4_0, while retiring fixAMMOverflowOffer after its post-amendment behavior became a permanent part of the protocol.
The software release does not mean either new amendment is active on mainnet. XRPL’s amendment process requires a proposal to receive more than 80% support from trusted validators continuously for two weeks before its rules become active.
Lending V1.1 adds closed-ended vaults and cash accounting
XRPL’s 3.4.0 release says LendingProtocolV1_1 changes the design of Single Asset Vaults and the Lending Protocol by introducing closed-ended vaults with defined subscription, investment and redemption periods.
Ripple’s technical documentation says depositors can add or withdraw assets during the subscription phase. During the investment period, deposits and withdrawals stop while assets can fund loans. Redemption begins once the investment period ends, allowing depositors to recover their share after loans mature.
Once LendingProtocolV1_1 becomes active, XRPL’s documentation says new loan brokers can only be attached to closed-ended vaults. Existing loan relationships created under earlier rules receive separate handling so outstanding positions can continue to be managed.
The accounting model changes at the same time. Ripple’s documentation says new vaults would recognize interest only when borrowers actually make payments.
Under the earlier model, all scheduled interest was recognized when a loan originated. Cash-basis accounting leaves unpaid future interest outside vault income until payment arrives, affecting AssetsTotal, loan debt calculations and the accounting treatment of defaults.
The V1.1 rules would not retroactively convert older vaults. Ripple’s documentation says vaults created under the previous accounting method retain that model after V1.1 activation.
As earlier amendment coverage reported, Ripple’s validator had already voted for the underlying SingleAssetVault and LendingProtocol proposals in August, but validator approval remained well below the level required for mainnet activation.
XRPL 3.4.0 packages a large set of transaction fixes
The second amendment, fixCleanup3_4_0, contains fixes covering lending, vaults, Automated Market Makers, Multi-Purpose Tokens, NFTs, escrow, permissioned trading and account authorization.
The official release says one change prevents AMMClawback from burning a holder’s liquidity-provider tokens while recovering zero underlying assets when MPT rounding reduces the calculated recovery amount to zero.
Another fix strengthens MPT invariants. XRPL developers said the ValidMPTBalanceChanges and ValidMPTTransfer checks, which previously generated logs, are enforced under the amendment and continue to apply when transactions fail.
For Single Asset Vaults, the release lists precision and rounding changes across deposits, withdrawals and clawbacks. The rules are designed to keep recorded assets, available assets and outstanding share supply aligned when conversions reach precision boundaries.
Permissioned trading receives several corrections. The package excludes deleted domain offers from one Permissioned DEX invariant, tightens domain checks and corrects how expired credentials are removed when OfferCreate or Payment transactions run.
Signing behavior receives a separate safeguard. The release says version 3.4.0 assigns different signing hash prefixes to counterparty and sponsor signatures so a signature created for one role cannot be replayed as the other.
The release contains lower-level node hardening outside the amendment package. Developers fixed an unbounded database seek through TMGetLedger, capped the size of incoming TMTransactions lists and introduced a fee for transactions that cannot be deserialized.
XRPL developers said version 3.4.0 incorporates phase-one fixes arising from MPT and DEX audit and attackathon findings. The release does not identify those fixes as evidence of an active exploit on mainnet.
In previous upgrade coverage, version 3.3.0 had already introduced code for several separate proposals, including corrected Batch functionality, sponsored fees and confidential MPT transfers, with validator approval still required before activation.
Validator approval still separates release from activation
XRPL’s official amendment rules state that installing software containing an amendment only gives a server the code needed to understand the proposed rules. Validators separately choose whether to vote for activation.
The current XRPLF feature code lists both LendingProtocolV1_1 and fixCleanup3_4_0 as supported while retaining DefaultNo voting behavior. A default-no setting means running the software does not itself cast an affirmative amendment vote when an operator has not configured another choice.
The underlying lending components remain short of activation. A Sept. 17 snapshot based on XRPL Foundation validator-history data showed 16 of 35 trusted validators supporting SingleAssetVault and 13 of 35 supporting LendingProtocol.
Those counts are time-sensitive and come from an independent network tracker, not a fixed figure published in the release notes. The official rule remains more than 80% support maintained for two continuous weeks.
The new V1.1 amendment depends on the underlying lending architecture. The current XLS-66 specification describes fixed-term, uncollateralized lending using funds pooled through Single Asset Vaults, while borrower underwriting and credit-risk assessment remain off-chain.
The same specification remains classified as Draft. No source reviewed for this update showed a mainnet loan executed through the proposed native protocol or an activation date for LendingProtocolV1_1.
Node operators now receive packages from XRPL Foundation
Version 3.4.0 changes the distribution path for Linux server packages. The official release says Debian and RPM packages are now hosted through packages.xrplf.org and signed with an XRPL Foundation key.
XRPL developers urged server operators to install 3.4.0 “as soon as possible” to maintain service continuity. The published DEB and RPM files include SHA-256 checksums so operators can verify downloaded packages before installation.
GitHub now lists 3.4.0 as the latest immutable xrpld release, tied to commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17. The repository says the release tag and version commit carry verified signatures.
The same release retires fixAMMOverflowOffer. Under XRPL’s amendment model, retirement does not reverse the fix. It removes obsolete pre-amendment behavior after the new rules have become established as permanent protocol behavior.
Client support and security review are still developing
Application libraries are moving alongside the server release. XRPLF’s JavaScript client history lists LendingProtocolV1_1 support under the unreleased section following xrpl.js 5.2.0, which shipped on Sept. 11.
The binary-codec history shows version 2.11.0 already contains the role-specific sponsor and counterparty signing prefixes used by fixCleanup3_4_0, along with protocol definitions generated from xrpld 3.4.0.
Security testing of the lending work has continued separately from validator voting. Sherlock said in an Aug. 27 review that Ripple had started an AI-only examination of Lending Protocol V1.1 through its Audit Engine.
Sherlock said it would publish more information after the review finished, but no final V1.1 findings were located in its public materials checked for this report. Earlier testing covered a previous version of the lending system; prior independent audit coverage reported that Halborn’s earlier re-audit found no critical or high-risk issues while identifying one medium, two low and two informational findings.
