XRP Ledger's Validator Split: Why the Next XRPL Upgrade Still Needs Network Consensus

By mid-June, the XRP Ledger shipped a fresh server release. Validators moved fast. Most nodes in the wild did not. That mismatch is why people keep asking if the network is actually upgrading or just talking about it.

The short version: xrpld 3.2.0 is out, a big chunk of the default validator set already runs it, yet the main amendment tied to that release has not cleared the bar it needs to activate. Different dials control code versions and governance votes. They do not always sync.

If you are watching dashboards and seeing green checkmarks beside validators but a patchwork of node versions, you are not going crazy. That is exactly what is happening right now.

Here is the state of play. The XRPL reference server 3.2.0 hit GitHub on 15 June 2026, giving operators a stable target to upgrade toward. You can see the tag and notes on the XRPL Foundation repo here: XRPLF/rippled GitHub (release notes). Within a few weeks, 31 out of 35 validators on the default Unique Node List were reported to be running v3.2.0, roughly 89 percent of that set, according to CoinDesk.

Zoom out to the wider network and the picture is messier. XRPSCAN-based reporting shows around 833 active nodes, with about 43 percent on v3.2.0 and roughly 51 percent still on 3.1.3, which means the general node landscape is split while validators are largely current. That split was also cited by CoinDesk from XRPSCAN data.

That last part is critical. An XRPL amendment needs more than 80 percent of votes from trusted validators for two straight weeks to activate. The rule is written down plainly in the docs, and worth rereading right now: XRPL Commons.

How XRPL changes roll out

To understand why the network looks split yet stable, you have to separate mechanics from outcomes. XRPL has a release train for software and a consensus gate for features.

UNL and trusted votes

Most operators track a trusted set of validators, the default UNL. Those validators run the consensus algorithm that finalizes ledgers. Their software version matters for performance and compatibility. Their votes matter for governance.

Amendments are opt-in by votes, not by binaries

Developers can ship a new server version that contains code for one or more amendments. That code sits dormant until validators explicitly vote yes and sustain a supermajority. Even if 100 percent install the new binary, the network will not flip features on until the votes line up for two weeks.

1. Proposal: A change is packaged as an amendment inside a server release.
2. Install: Node operators upgrade binaries to gain compatibility and optional features.
3. Signal: Validators begin voting for or against the amendment.
4. Supermajority: Support must exceed 80 percent of trusted validators.
5. Time lock: That majority has to hold for 14 consecutive days.
6. Activation: The amendment turns on for everyone who is compatible. Old nodes may fall off if they cannot follow the new rules.

These steps mirror the lifecycle described in XRPL Commons and they explain the current holding pattern.

What v3.2.0 ships right now

Version 3.2.0 is the latest reference server from the XRPL Foundation’s implementation. That release carries code paths for new fixes and improvements, one of which is identified as fixCleanup3_2_0. The amendment is open for voting, but recent reporting that cites XRPSCAN has support near 40 percent, nowhere close to the supermajority threshold. See KuCoin for that snapshot, and the release tag on GitHub for the distribution itself.

Who is on which version

Component Version or status Adoption metric Data source UNL validators v3.2.0 31 of 35, about 89% CoinDesk All XRPL nodes v3.2.0 ~43% of 833 nodes CoinDesk citing XRPSCAN All XRPL nodes v3.1.3 ~51% of 833 nodes CoinDesk citing XRPSCAN Amendment vote fixCleanup3_2_0 ~40% validator support KuCoin citing XRPSCAN

Takeaway: you can have a validator supermajority running the same version, but unless those same validators signal yes and keep that vote for two weeks, the amendment does not switch on.

Why upgrades and votes drift apart

There are good reasons validators will install the latest binary but hold off on votes. Some are conservative by design. Others operate under risk committees that need more time. A few simply prefer to see a week or two of live data before flipping their vote to yes.

Binary vs ballot

Upgrading a server is an operational chore. You schedule downtime, roll the change, watch logs, and move on. Voting is policy. It is a promise to follow new rules and force that reality on every other participant once the clock runs out. The bar should be higher.

Operational constraints

Many validators run more than one chain or support exchange infrastructure. They stage upgrades in rings and keep a rollback plan. If a vote risks orphaning old nodes or breaking an integration, they will logically wait until their dependent systems, partners, or clients are also in a safe place to follow along.

Communication lags

Even with public release notes, it takes time for operators to digest the change list, test their own workloads, and check third party tooling. Monitoring still catches edge cases days later. That soft lag shows up as a gap between version uptake and firm votes.

Where the network stands right now

It is tempting to call this a split network, but it is more like staggered readiness. The consensus rules let older binaries track the chain as long as no activated amendment requires behavior they do not understand. With fixCleanup3_2_0 sitting near 40 percent support, the 14 day clock has not even started.

Recent timeline

Date Event Why it matters Source 2026-06-15 xrpld 3.2.0 release published Operators get a stable target to upgrade XRPLF/rippled GitHub Early July 31 of 35 UNL validators on v3.2.0 Validator majority is already on the new binary CoinDesk 2026-07-07 fixCleanup3_2_0 ~40% validator support Below the 80% supermajority, no activation window yet KuCoin citing XRPSCAN

Until an amendment crosses the 80 percent threshold and holds it for 14 days, old and new nodes can keep coexisting. Once activation happens, laggards risk falling out of consensus if they cannot follow the new rules.

What it means for builders, exchanges, and holders

Different groups have different jobs to do here. The main one is pretty simple: do not confuse a version number with a vote tally.

Builders shipping apps

If you run infrastructure, stage your 3.2.0 rollouts, but plan your feature flags around when amendments actually activate. Treat fixCleanup3_2_0 as pending until you see support rise above 80 percent and stay there for at least two weeks. Keep an eye on XRPSCAN or other trackers, and confirm against the official amendment rules.

Exchanges and custodians

Map your upstream dependencies. If your validators are already on 3.2.0 but some internal services still expect 3.1.3 behavior, that is your cue to test failovers now. Document what will happen the moment an amendment activates so your support desk is not guessing during live traffic.

Everyday XRP holders

This is not financial advice, but in general, network upgrades can be noisy without changing anything about your wallet or deposits. What matters most is the amendment vote, not the chatter around who runs what binary. Be wary of social posts that treat validator software counts as if they were binding governance tallies.

What to watch in Q3

A few signals will tell you where this is going next. None of them require a PhD to follow.

The 80 percent line

Watch the vote share for fixCleanup3_2_0. If it crosses 80 percent and stays there, the 14 day timer starts. If it dips, the timer resets. That is all there is to it, and it is clearly spelled out in the amendment lifecycle.

UNL composition

Changes in who is on the default UNL can shift the vote math. A new validator joining or an existing one dropping can nudge percentages without anyone changing their mind. Keep that in the back of your head when you see small swings.

Node version catch-up

If the node landscape converges on 3.2.0 in the coming weeks, the operational risk of activation falls. If the split lingers, expect a slower path, more warnings, and maybe some validators choosing to abstain longer.

Risks and what could go wrong

• Activation before broad node readiness could cause temporary fragmentation for operators who stayed on older binaries.
• Unexpected bugs that only appear under mainnet load could force emergency patches or vote reversals.
• UNL concentration risk means a small set of operators can swing the vote, which may frustrate app teams waiting on features.
• Exchange or wallet integrations tied to 3.1.3 assumptions may break when rules change, causing deposit or withdrawal delays.
• Confusion in public comms could be exploited by scammers pushing fake upgrade tools or phishing around the amendment name.

For steady coverage that separates version adoption from governance signals, Crypto Daily tracks validator moves, amendment votes, and rollout notes across ecosystems. You can follow our ongoing reporting here: Crypto Daily.

Frequently Asked Questions

Does 89 percent of validators on 3.2.0 mean the amendment is live?

No. Running the binary is not the same as voting yes. An amendment only activates after more than 80 percent of trusted validators vote in favor and that majority holds for 14 continuous days, per the XRPL Commons rules.

What happens if my node stays on 3.1.3 when an amendment activates?

If your node cannot follow the new rules, it may fall out of consensus or refuse to validate the newest ledgers. You will likely need to upgrade to regain full functionality. Until activation, an older node can still track the network.

Why is fixCleanup3_2_0 getting only around 40 percent support?

Operators may be evaluating the change, staging internal tests, or waiting for broader node readiness. The figure is a snapshot reported from XRPSCAN by third parties like KuCoin, and could move as validators update their votes.

What is the difference between validators and general nodes in this context?

Validators on your trusted list decide governance outcomes through votes. General nodes relay transactions, serve APIs, and keep copies of the ledger. Both matter for network health, but only validator votes determine amendment activation.

How can I track the vote without relying on rumors?

Use recognized dashboards such as XRPSCAN and compare against official documentation on the activation process. Cross reference any claims with primary sources, like the 3.2.0 release and the amendment lifecycle.

Could this affect XRP price?

Network changes can influence sentiment, but prices move for many reasons and remain volatile. Focus on whether an amendment actually activates. Nothing here is financial advice.

Is it safe to transact on XRPL during this period?

Transactions are processing as usual. The key risk window is around activation if many nodes are outdated. If you operate infrastructure, upgrade in advance and monitor validator votes closely.

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.