XRP Ledger’s Amendment Clears the Bar as Exchanges Still Lag

XRP Ledger’s fixCleanup3_2_0 amendment is set to switch on July 29 at 09:57 UTC, and the vote that decides that outcome runs through a far narrower group than the headline adoption numbers suggest. Only 489 of the network’s 843 tracked nodes, or 57.87%, run the required v3.2.0 software so far. The 35 validators whose votes actually count already cleared 85.71% support, comfortably past the 80% threshold the protocol requires.

Hundreds of the remaining nodes belong to exchanges, custodians and smaller platforms that never show up in that vote at all. Miss the deadline, and a node simply goes dark. Nobody is publishing a list of which exchanges or projects are still exposed.

The Vote That Actually Decides July 29

The clock traces to a single social post.

In less than 1 Week all nodes running XRPL versions below 3.2.0 will experience service interruptions. Please update your nodes, remind exchanges and projects to update as well!

Hussein Zangana, the XRP Ledger Foundation’s director of community who posts as Vet, urged operators to update their nodes in a July 22 post on X, adding a lighter greeting for anyone who had already made the switch.

The number that actually matters is 35. That is how many validators sit on the network’s default Unique Node List (UNL, the roster of validators most servers trust automatically for consensus). Of those 35, 30 back fixCleanup3_2_0, the 85.71% figure in the source data, well clear of the supermajority line.

That line has to hold. XRP Ledger’s own documentation lays out the rule plainly: an amendment needs 80% support sustained for two full weeks before it locks in permanently. Support has already been sitting above that mark for more than a week. If it slipped below 80% before July 29, the two-week countdown would reset and start over from zero.

Three Tiers, One Deadline

XRP Ledger Explorer folds three separate populations into the adoption numbers everyone quotes, and only one of them controls what happens on July 29.

The gap between the first row and the last one is the whole story. A server can sit entirely outside the UNL and still lose the ability to process transactions the moment the amendment flips on, because those 35 are the entities whose votes determine activation, not the wider pool of active nodes that simply store and relay ledger data.

That split explains why two very different numbers can describe the same week without contradicting each other. Earlier reporting on this same rollout found 89% of UNL validators already running the release while barely 43% of the roughly 833 active nodes had done the same. Both were accurate. They were just measuring different populations.

Who Actually Goes Dark When the Clock Runs Out

XRPL calls the fallback state amendment blocked. Once a server can no longer parse an activated rule change, it loses the ability to determine whether a ledger is valid, submit or process transactions, take part in consensus, or vote on future amendments.

It is a safety mechanism, not a crash. XRP Ledger’s documentation frames amendment blocking as a security feature built to protect the accuracy of ledger data, not a sign the network itself is breaking.

For everyday users, the practical effect shows up somewhere else entirely. Exchanges, custodians and infrastructure providers running an unpatched node lose the ability to process XRP transactions until they finish the upgrade. That is where the deadline stops being a developer housekeeping item and starts being a service risk.

Nobody publishes a running tally of which platforms that includes. Recent analysis of this same upgrade cycle noted that how many of the lagging nodes belong to exchanges, custody providers or other user-facing services is not publicly tracked, even though the operational risk is real and specific to whichever platforms are still exposed.

A Rename Nobody Asked For

Buried inside the same release is a bigger structural change than a routine version bump. Proposal XLS-0095 renames the XRP Ledger’s core server software from rippled to xrpld, and swaps the default configuration file from rippled.cfg to xrpld.cfg.

The XRPL Foundation says the change addresses long-running confusion between XRP, the XRP Ledger and Ripple, the company. Configuration paths, deployment scripts, metadata references and database directories all need updating as part of the switch, and the network’s own release notes describe the update as “primarily a cleanup and maintenance release.”

Operators moving between the two names are pointed to a dedicated migration guide covering the binary and config swap, which also flags a changed package-signing key that Debian and RHEL based installs need to pick up before updating.

David Schwartz, Ripple’s chief technology officer emeritus and one of the ledger’s original architects, upgraded his own independent hub server within days of the release, taking it offline for roughly ten minutes to complete the switch. Ripple itself, the payments company whose founders built the original XRP Ledger, has voted in favor of fixCleanup3_2_0.

Beyond the name change, the amendment bundles fixes across a specific set of newer features:

• Single Asset Vaults – corrects rounding and accuracy errors in vault accounting.
• Lending Protocol – fixes similar accuracy issues in XRPL’s native on-chain lending system.
• Permissioned DEX – resolves bugs affecting the permissioned decentralized exchange feature.
• Permissioned Domains – patches issues in the permissioned domains framework.

None of it adds new capability. The release also retires amendments that have been active for more than two years, trimming legacy code rather than expanding what the ledger can do.

XRPL Has Run This Playbook Before

This is not the first time an XRPL software deadline has produced this exact headline shape. In May, node operators faced a near-identical countdown tied to version 3.1.3, with a former Ripple executive warning that servers left behind would become amendment blocked and lose access to ledger validation, transactions and governance participation once the May 27 deadline passed.

A similar dynamic surfaced in December 2025, when community trackers flagged that nearly 45% of public XRPL servers were on track to be amendment blocked over a different upgrade window. Each time, the trusted validator set kept functioning normally while a large share of the broader node population scrambled to catch up.

What Do We Actually Know So Far?

The amendment is on track to activate July 29 because the validator set that actually decides it is already ready. What is not known is exactly which exchanges, wallets or smaller platforms still run outdated nodes, since public trackers show software versions rather than company names.

What we know:

• fixCleanup3_2_0 holds 85.71% support from the 35-member default UNL, already above the 80% activation threshold.
• Activation is scheduled for July 29, 2026, at 09:57 UTC, provided support holds through the countdown.
• 489 of 843 tracked nodes (57.87%) run v3.2.0, while 319 (37.75%) remain on v3.1.3.

What’s unconfirmed:

• How many of the lagging nodes belong to exchanges, custodians or other consumer-facing platforms.
• Whether any specific exchange or wallet provider will pause XRP deposits or withdrawals around the activation window.

The countdown runs regardless. At 09:57 UTC on July 29, XRP Ledger will find out exactly how many of its 843 nodes made it.

Frequently Asked Questions

What happens if an XRP Ledger node misses the July 29 deadline?

It becomes amendment blocked, unable to validate ledgers, submit or relay transactions, or vote on future amendments. According to XRP Ledger’s documentation, a blocked server can rejoin the network immediately once it installs the current release, so the state is reversible, not permanent.

Does the fixCleanup3_2_0 amendment add new features to XRP Ledger?

No. It only corrects existing code across Single Asset Vaults, the Lending Protocol, the Permissioned DEX and Permissioned Domains. The same release also retires amendments that have been active on the network for more than two years, clearing out old code rather than adding capability.

What else changed besides the rippled to xrpld name?

The update changed the GPG key used to sign installer packages, meaning Debian and RHEL based operators need to refresh that key before installing. It also set a new default peering port for xrpld servers, alongside the configuration and database directory changes tied to the rename.

Could the July 29 activation still slip?

It is possible but would require a fast reversal. Support for fixCleanup3_2_0 sat near 40% through most of early July before climbing to 85.71% within about two weeks, showing validator sentiment can move quickly in either direction during an active countdown.

Does the upgrade affect hardware requirements for running a node?

Yes. Developers behind the release have described node memory requirements dropping by an estimated 30% to 40%, which lowers the cost of running XRPL infrastructure and could make it easier for smaller operators to join the validator pool over time.

Do everyday XRP holders need to do anything before July 29?

Most individual holders using a major exchange or hosted wallet do not need to take direct action, since that falls to the platform’s own infrastructure team. The exposure sits with node operators, exchanges and custodians whose servers process transactions on users’ behalf.

Disclaimer: This article is for informational purposes only and does not constitute financial, investment or technical advice; node operators and exchange users should verify upgrade status directly with XRP Ledger’s official documentation, and figures are accurate as of publication.