XRPL v3.2.0 Adoption Looks Slow. The 35 Validators Tell a Different Story

Three weeks after the XRP Ledger shipped version 3.2.0 on June 15, the network’s adoption picture splits in two. Of roughly 833 active nodes, about 43% have upgraded to v3.2.0 while 51% remain on the older v3.1.3, according to XRPScan data cited by CoinDesk on July 8, 2026. The headline read is slow uptake. The consequential read sits on a different set of numbers.

The decision-makers on the XRPL are not the 833 nodes. They are the 35 validators on the default Unique Node List, the trusted set whose agreement the network treats as binding. On that list, 31 validators are already running v3.2.0, or about 89%, clearing the 80% threshold the network requires for upgrades to take effect. The migration that matters most is already over. The migration still unfinished is the one sitting inside the software itself.

Two Adoption Numbers, One Network

Public dashboards draw attention to the raw node count because it is the largest, most visible signal. On the XRPScan explorer, the split between v3.2.0 and v3.1.3 trackers dominates the upgrade story. The 43% figure translates to roughly 358 servers running the new binary; the 51% figure translates to about 425 still on the May release.

Those nodes perform useful work, relaying transactions and storing the ledger. They are also the most expensive group for the project to migrate, because many are run by exchanges, custody providers, and infrastructure teams with their own change-control windows. The upgrade guide published alongside v3.2.0 gives operators a six-month window of backward compatibility before the legacy symlinks and config fallbacks disappear, which is why slow uptake among non-validator nodes is treated by the network as expected rather than alarming.

The 35 Validators Who Actually Move the Network

The XRPL consensus protocol gives the final say to a curated list of trusted validators, the Unique Node List, not to the long tail of passive relay nodes. An amendment or software version only activates after more than 80% of those validators sustain support for two straight weeks.

On the default UNL of 35 validators, 31 are running v3.2.0. That is well past the threshold. The four validators still on v3.1.3 have until the back-end of that two-week window to catch up or lose standing on the network. CoinDesk reports the upgrade has cleared the bar the network treats as binding. Whether every node operator eventually follows is a maintenance question, not a consensus one.

The fixCleanup3_2_0 Amendment Is a Separate Vote

Bundled inside the v3.2.0 binary is a piece of protocol business the software itself does not decide. fixCleanup3_2_0 is a formal on-ledger amendment: it requires the same 80%-of-UNL, two-straight-weeks rule, but it is counted independently of how many servers have downloaded the software. A validator can run v3.2.0 and still vote no on the amendment.

On the XRPScan amendments registry as of July 9, 2026, fixCleanup3_2_0 has 19 validators voting in favor, against a threshold of 28 of 35, putting consensus at 54.29%. The amendment sits in voting status. It has crossed neither the two-week window nor the 80% bar.

The two older voting items in the table are relevant context, not new news: Single Asset Vaults and the Lending Protocol were both launched in 2025 and still have not reached their activation thresholds, polling at 25.71% and 22.86% respectively. fixCleanup3_2_0 is closer to passing than either, but it is not close to passing.

What fixCleanup3_2_0 Actually Patches

The amendment is a cleanup bundle for the network’s newer DeFi features, per the official v3.2.0 release notes. It adds precision and rounding fixes for Single Asset Vaults and the Lending Protocol, corrects a permissioned DEX invariant that was firing on a valid offer deletion, adds stricter validation for Multi-Purpose Token amounts, and introduces a zero DomainID check for permissioned domains.

It also adds a new invariant called AccountRootsDeletedClean, a check that a deleted account does not leave behind directly accessible artifacts. None of these are flashy protocol upgrades. They are the kind of fix that closes gaps before something exploits them, and they are the reason the network treats amendment activation as a separate gate from binary adoption.

The Real Operator Headache Is the rippled-to-xrpld Rename

For most node operators, the bigger migration in 3.2.0 is not the amendment. It is the rebrand. The reference server software, first shipped before 2013, has been renamed from rippled to xrpld under the XLS-0095 community standard. The binary, the configuration file, the C++ namespace, the package names, and the Docker images all change.

Default configuration files, database directory paths, and the server’s user-agent string all carry the new name. A temporary rippled-to-xrpld symlink and a config fallback ship with the release to ease the transition, but both disappear after the six-month compatibility window closes. Operators who delay past that window will find their scripts, monitoring, and automation pointing at paths that no longer exist.

What Happens to Validators That Don’t Catch Up

The XRPL’s amendment governance gives non-upgrading validators a way to fall off the network without a hard fork. Servers that have not upgraded to a release supporting an enabled amendment are placed in what the protocol calls an amendment-blocked state. Per the XRPL documentation, an amendment-blocked server cannot determine the validity of a ledger, submit or process transactions, or participate in the consensus process.

Ripple has voted in favor of fixCleanup3_2_0. If the amendment clears 28 of 35 UNL validators for two weeks and then activates, validators that have not yet upgraded will be cut off from the ledger until they install the supporting binary. The vote count today, at 54.29%, suggests that deadline is not imminent, but the mechanism that would enforce it is already in place.

Frequently Asked Questions

What does XRPL v3.2.0 change for users?

For end users holding XRP, v3.2.0 is mostly an infrastructure release. It cuts node memory usage by up to 40% for operators, retires amendments that have lived on the network for over two years, and renames the reference server from rippled to xrpld. The user-facing protocol behavior does not change.

Why are only 43% of nodes on v3.2.0?

Many of the 800-plus XRPL nodes are run by exchanges, custodians, and infrastructure providers with their own change-control cycles. The release notes give those operators a six-month backward-compatibility window, so slow uptake among non-validator nodes is expected and does not affect consensus.

What is fixCleanup3_2_0?

It is a bundled amendment that ships with v3.2.0 and bundles bug fixes for Single Asset Vaults, the Lending Protocol, the permissioned DEX, Multi-Purpose Tokens, and permissioned domains. It activates independently of how many servers have installed the software, after 28 of 35 UNL validators vote in favor for two straight weeks.

How many UNL validators need to vote yes for the amendment to pass?

Twenty-eight of the 35 default UNL validators need to sustain support for two consecutive weeks. As of July 9, 2026, 19 of 35 validators, or 54.29%, have voted in favor, per the XRPScan amendments registry.

What happens if a validator does not upgrade before the amendment activates?

The server enters an amendment-blocked state and cannot determine the validity of a ledger, submit or process transactions, or participate in consensus, according to the XRPL documentation. It stays disconnected until it installs the supporting software version.

Disclaimer: This article is for informational purposes only and does not constitute financial advice. Cryptocurrency assets and network upgrades carry technical and market risk, including the potential loss of principal. Figures and validator counts are accurate as of publication and may change as adoption continues.