XRP Ledger’s v3.2.0 Wins Over Trusted Validators While Most Nodes Wait

The XRP Ledger’s newest software upgrade has crossed an important validator signal, but the rollout is not finished.

That split is the story.

The trusted validator set is moving faster than the broader active-node network, while a related cleanup amendment is still working through voting.

For XRP, this is an infrastructure test more than a price headline.

LATEST: The XRP Ledger's new v3.2.0 upgrade is adopted by 89% of trusted validators but only 43% of all active nodes, with a bundled security amendment still in the voting phase requiring 80% UNL support to activate. pic.twitter.com/DiTNsOfeJe

— CoinDesk (@CoinDesk) July 8, 2026

CoinDesk reported that XRP Ledger v3.2.0 has been adopted by about 89% of trusted validators on the default Unique Node List, while only about 43% of all active nodes were running the new software.

The report said the network had roughly 833 active nodes, with 51% still on v3.1.3. That makes the rollout look very different depending on whether the focus is default trusted validators or the full active-node population.

CoinDesk reported that 31 of 35 validators on the default UNL had upgraded to v3.2.0. That is above the 80% threshold the network uses for upgrade support on the trusted list, but it does not mean every node has moved.

The report also separated the software upgrade from the fixCleanup3_2_0 amendment. That amendment is a formal on-ledger vote, and it is still a distinct step from installing the new server version.

That difference matters. A validator can run newer software while the amendment vote still has its own support level and timing.

Network users, infrastructure operators, and exchanges have to track both layers.

CoinDesk reported that Ripple has voted in favor of fixCleanup3_2_0. It also noted that validators that fail to upgrade before an amendment activates risk entering an amendment-blocked state.

That is why these maintenance releases matter. They determine whether the ledger’s operators remain aligned as new features and fixes become part of the network.

XRPL.org published the official v3.2.0 release notes on June 15, describing the new version of xrpld as the reference server implementation for the XRP Ledger protocol.

The release notes describe v3.2.0 as primarily a cleanup and maintenance release. That may sound quiet, but maintenance releases are often where a network proves whether it can keep older technical debt from slowing newer product ambitions.

The release retires amendments that have been active for more than two years, continues modularization of libxrpl, and renames rippled to xrpld under XLS-0095. That naming change also affects default configurations and database directory paths.

XRPL.org told server operators to upgrade to ensure service continuity. That is direct operational language, and it explains why node adoption is being watched closely.

The release also introduced fixCleanup3_2_0, which bundles fixes affecting Single Asset Vaults, the Lending Protocol, the permissioned DEX, Multi-Purpose Tokens, and permissioned domains.

That list connects the upgrade to XRPL’s larger tokenization and DeFi roadmap. The amendment reaches old-code cleanup and feature areas that matter for lending, vaults, permissioned markets, and institutional-style asset flows.

$XRP Ledger v3.2.0 adoption continues to grow.

✅ 89% of trusted validators have upgraded.
✅ 43% of all active nodes are now running v3.2.0.

The bundled security amendment remains in the voting phase & will activate once it maintains 80% UNL support. pic.twitter.com/qp0fLRLqUQ

— XRP Update (@XrpUdate) July 8, 2026

XRPSCAN provides the public amendment and network-status context that market watchers use to follow XRPL software adoption and amendment voting.

The amendment page is the relevant status reference for the kind of voting process behind fixCleanup3_2_0. CoinDesk cited XRPSCAN data while reporting the split between active-node adoption and trusted-validator adoption.

That public-data layer is important because XRPL upgrades are tracked beyond press releases. They show up through server versions, validator behavior, and amendment support that can be checked on the network.

The key point is that an amendment vote and a software version are separate signals. Blending them would make the rollout look cleaner than it is and obscure where coordination still has to happen.

That is also why the 89% figure and the 43% figure can both be true. They are measuring different parts of the network.

For a payments and tokenization ledger trying to court serious financial users, that nuance is the whole point. Reliability comes from coordination, not slogans.

XRPL.org describes Multi-Purpose Tokens as fungible tokens on the XRP Ledger designed for greater efficiency and easier use than older trust line token patterns.

The documentation says MPTs offer ready-to-use tokenization features, including on-chain metadata, transfer controls, supply caps, fees, freezing, clawback, and fields meant to support asset-class information.

Those are the kinds of controls institutions look for when they evaluate tokenized real-world assets or regulated token flows. They also raise the bar for cleanup, testing, and amendment discipline.

If a network wants to support serious token issuance, the boring parts of software governance become visible. Issuers need predictable behavior, operators need clear upgrade paths, and users need confidence that feature fixes are actually adopted.

That is why fixCleanup3_2_0 touches more than a single token feature. It is part of the hygiene behind a broader tokenization stack.

XRPL.org says Single Asset Vaults aggregate assets from multiple depositors and make those assets available to on-chain protocols such as the Lending Protocol.

The documentation says vault assets can include XRP, trust line tokens, or Multi-Purpose Tokens. It also explains public and private vault structures, share redemption, and how vault shares are represented onchain.

That matters because vaults and lending features are exactly where software consistency becomes more important. A small bug in a feature that holds pooled assets can become a large trust problem if operators are fragmented.

The current rollout shows XRPL moving in two directions at once. The default trusted validators are largely on the new software, but the broader node base is still catching up and the cleanup amendment remains a separate vote.

The cleaner read is a live coordination test.

For XRP holders and XRPL builders, the question is whether the network can keep shipping institutional-grade primitives while keeping its operator base aligned enough to absorb the changes.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.