XRP Ledger v3.2.0 Upgrade at 55% Adoption, Amendment Stuck

More than half of XRP Ledger validators now run xrpld v3.2.0, the cleanup release that renamed the network’s core server from rippled to xrpld three weeks ago. The figure, 55.63% of validators running the new build, sits well above last quarter’s milestones but still leaves the protocol short of the threshold required for activation, with the bundled fixCleanup3_2_0 amendment at 48.57% support per the live amendment voting registry. A separate validator pubkey-mismatch bug filed on GitHub has added a fresh wrinkle for operators mid-migration.

v3.2.0 shipped on June 15, 2026 and is the first major release to bundle a core daemon rename with a sweeping cleanup amendment. The numbers point to a network that likes the rename but has not yet embraced the most consequential part of the bundle. Whether that gap closes in time is the bet every UNL validator operator now holds.

The Mechanics of the v3.2.0 Release

The headline change is the daemon rename. Under XLS-0095, the network’s main server software now goes by xrpld instead of rippled, with configuration paths, database directories and version metadata all updated to match. The package on the official xrpld 3.2.0 release notes ships as RPM and DEB builds hashed to a June 15 commit. Operators should upgrade to keep service continuity.

Alongside the rename, v3.2.0 retires a long list of amendments that have been live for over two years, including Checks, ExpandedSignerList and NonFungibleTokensV1, per the release page. A new –definitions CLI flag lets wallets, APIs and explorers pull the protocol’s full transaction, ledger entry and flag definitions without running a server. The release also adds optional TLS and mTLS to the gRPC server, typed wrapper classes for ledger entries, and peer public keys to log output while keeping IPs masked. For anyone running a C++ node, the move from boost::coroutine to boost::coroutine2 is a quiet practical fix for ARM-based builds that previously hung the embedded tests.

The change operators feel first is path-related. The default database directory moves with the binary, configuration files now live under an xrpl-prefixed layout, and standalone mode restores a config change that had been broken in v3.1.3. None of these are visible on-chain, but they all show up the first time a 3.1.3 server is restarted on a 3.2.0 build.

Validator Adoption at the Halfway Mark

XRPL Explorer data, cited in third-party coverage this week, counts 84 validators on v3.2.0, or 55.63% of the validator set. Another 58 validators (38.41%) remain on v3.1.3, the build that locked in the previous fixCleanup3_1_3 cleanup on May 27, 2026. That earlier upgrade put a sharper point on the same deadline dynamic, as documented in the May 27 deadline that required rippled 3.1.3.

On the node side the lag is wider. Just 353 nodes, or 42.12% of the network, have moved to v3.2.0, while 440 nodes (52.51%) remain on v3.1.3. By contrast, validators are ahead on percentage terms, with 55.63% on the new build against 38.41% on v3.1.3. The two versions are still talking to each other today. A network upgrade requires the approval of over 80% of trusted validators maintained across two weeks. That puts the bar roughly 25 percentage points above current validator share.

The Slow Lane for fixCleanup3_2_0

The amendment the network is voting on, fixCleanup3_2_0, is the slower part of the deal. Per the live amendment voting registry, 17 of the 35 UNL validators are voting yes, which works out to 48.57% support. The threshold to activate is 28 of 35, or 80% maintained across two weeks. With 11 more yes-votes needed inside the two-week window, the amendment trails both the software version and the votes on related features tracked on the same registry.

fixCleanup3_2_0 bundles bug fixes that touch the most consequential live features on the chain. Per the release notes, it adds precision and rounding fixes for Single Asset Vaults and the Lending Protocol, validates non-canonical Multi-Purpose Token amounts, and patches a ValidPermissionedDEX invariant that was firing on a valid offer deletion. It also adds a zero DomainID check for permissioned domains and a new AccountRootsDeletedClean invariant that prevents deleted accounts from leaving artifacts behind. These are the kind of fixes that get missed until a vault or a loan broker is the unit being measured.

Lending and vaults are the same surface Halborn has been auditing since December 2025. The amendment’s slower vote suggests the UNL is treating it as the load-bearing piece rather than the rename.

• Yes votes: 17 of 35 UNL validators
• Activation threshold: 28 of 35 (80% maintained for two weeks)
• Status: Voting, not enabled
• Coverage: Single Asset Vaults, Lending Protocol, permissioned DEX, Multi-Purpose Tokens, permissioned domains
• New invariant: AccountRootsDeletedClean

Issue #7581 and the Validator Pubkey Drift

Beyond the slower amendment vote, a specific migration bug is now public. The open issue tracking the validator pubkey mismatch, filed against the rippled repository and tagged for v3.2.0, describes a server whose service log shows the new validator pubkey while its wallet.db still holds the old one.

The reporter’s steps to reproduce are simple: take an already running RPC node and add an existing validator token to its configuration, then restart. After restart, the service log reports the new pubkey while a server_info call returns the old one. The reporter was on Ubuntu 22.04 running xrpld 3.2.0 from the release-3.2 branch, with the git commit hash matching the tag on the release page.

The reporter’s proposed fix is to align the log line with the pubkey the server actually uses, or to print both. The mismatch itself doesn’t change consensus, but it breaks operator trust in the migration path at exactly the moment trust matters most. If a validator’s monitoring pulls from logs and a downstream tool pulls from server_info, the two will disagree on the validator’s identity until the wallet is rebuilt.

The bug is open and the project’s migration guide for moving from rippled to xrpld walks through a clean rebuild. For operators running a single upgrade window the practical move is to wipe the local wallet and re-add the validator token under v3.2.0, rather than carry the legacy key forward.

Halborn’s Five Findings From the Lending Re-Audit

Independent of the upgrade timing, Halborn finished a focused re-audit of the XRPL Lending Protocol. The engagement ran from December 16, 2025 to January 12, 2026, covering code changes since the prior audit and stress-testing whether the implementation still matches the XLS-0066d specification. The Halborn re-audit report summary lists zero critical issues and zero high-risk issues. One medium and two low-risk findings were logged alongside two informational items.

All five findings are marked addressed in the report’s status table. The medium finding, a bypass of vault asset maximums through loan interest, was fixed. The lone low-risk freeze-check gap in LoanBrokerSet was also fixed. A degraded state design flaw, a grace period edge case and a cover rate validation issue were accepted or acknowledged after review.

The audit covers the same lending and vault surface that fixCleanup3_2_0 touches, which is why the amendment’s vote matters even after Halborn signs off. The lending protocol targets uncollateralized on-chain fixed-term loans, with off-chain underwriting sitting between borrowers and Single Asset Vaults as the credit layer. That design, closer to a private credit facility than a typical DeFi money market, is part of why trading on RLUSD has climbed in the last year, as data on RLUSD’s growing share of XRPL trading documented. Halborn’s clean bill covers the code and the amendment covers the runtime invariants that guard the same features against state drift.

What Still Has to Happen for Activation

For v3.2.0 to formally activate, the fixCleanup3_2_0 amendment needs 28 of 35 UNL validators voting yes across two weeks. Today that count sits at 17, with another 11 yes-votes and a maintained two-week clock required. On the broader software front, validators on v3.2.0 have crossed the halfway line, but the rule for protocol changes follows UNL votes, not raw validator count. Ripple is publicly voting in favor of the amendment, and the lending re-audit adds confidence.

Two earlier clocks anchor the operator calendar. fixCleanup3_1_3, the previous amendment under v3.1.3, switched from voting to enabled on May 27, 2026, a date that put a hard floor under operators running older builds at that point. The v3.2.0 release marks its own three-week mark on July 6, the date by which a confirmed maintained 80% would already have triggered activation if the threshold had been crossed. Both dates set the operating tempo for this network: it votes on a fix-release cadence, not a feature cadence, and operators who want the latest invariants live on their node should plan for the next fixCleanup drop rather than the next feature amendment.

Frequently Asked Questions

What is the fixCleanup3_2_0 amendment?

The fixCleanup3_2_0 amendment is a bundled set of bug fixes that shipped with xrpld v3.2.0 on June 15, 2026. It covers Single Asset Vaults, the Lending Protocol, the permissioned DEX, Multi-Purpose Tokens, and permissioned domains, and adds the AccountRootsDeletedClean invariant that prevents deleted accounts from leaving artifacts behind.

Why did the XRP Ledger rename rippled to xrpld?

The rename is part of XLS-0095, a standard approved to remove the Ripple name from the core server software. Per the project’s release notes, the change covers the system name, default configuration and database directory paths, as well as RPC metadata such as the server’s user agent. The migration guide walks operators through moving a node from the legacy path.

Has fixCleanup3_2_0 been activated?

No. Per XRPSCAN’s live registry, fixCleanup3_2_0 is in voting status with 17 of 35 UNL validators voting yes, which is 48.57% support. Activation requires 28 of 35 validators, or 80%, maintained across two consecutive weeks.

Do node operators need to upgrade to xrpld v3.2.0?

Operators can stay on v3.1.3 for now, since both versions are still talking to each other and the prior fixCleanup3_1_3 amendment is fully enabled. Upgrading is required if operators want the fixes bundled into fixCleanup3_2_0 to apply on their node, or if they want monitoring logs that align with the migrated wallet.

Was the XRP Ledger lending protocol audit successful?

Halborn completed a focused re-audit of the XRPL Lending Protocol between December 16, 2025 and January 12, 2026. The firm logged zero critical issues, zero high-risk issues, one medium issue, two low-risk issues and two informational items. All five findings are marked addressed in the report’s status table.

Disclaimer: This article is informational only and is not financial advice. Cryptocurrency protocols carry technical and market risks, including the possibility that proposed amendments do not activate and that validator or node migrations introduce identity or consensus mismatches. Figures are accurate as of publication on July 8, 2026.