Nodes Upgrading to XRP Ledger’s xrpld 3.2.0 Fall Out of Sync

Validator support for the XRP Ledger’s next mandatory software fix hit 85.71% this week, five points clear of the threshold it needs to activate on July 29. But the GitHub queue tracking xrpld 3.2.0, the release carrying that fix, is filling with a different kind of number: bug reports from node operators who upgraded on schedule and got a worse connection to the network for their trouble.

Four separate reports filed on the XRP Ledger Foundation’s repository describe servers that synced fine on the old software and now lag, stall, or misreport their own identity after moving to 3.2.0. None of the reports has stopped the network. All of them landed inside the same week validators pushed the fixCleanup3_2_0 amendment past the point of no return.

Four Reports Land on the Same GitHub Queue

The complaints span hardware, operating systems, and roles on the network, but they share a pattern: the software that is supposed to keep a node current is the one knocking it out of step.

One operator running xrpld 3.2.0 on Windows 10 reported a server that holds around 30 stable peers, has loaded a valid unique node list (UNL, the list of validators a server trusts) with 35 trusted validators, and keeps receiving proposals and validations, yet never advances past the “connected” state. Instead of joining the current ledger, the machine keeps closing its own ledgers dating back to the network’s genesis. The same hardware ran the old rippled software without issue.

A separate mainnet validator operator reported the server cannot download ledger data from peers at all, stuck at “connected” instead of reaching “syncing,” “tracking,” or “full.” Acquiring a ledger from an empty datastore took roughly 13 minutes, slower than on the prior 3.1.3-1 release, leading the reporter to suspect a regression. The open report of a server_state stuck at disconnected tracks a closely related failure mode on the same repository.

The project’s own guide for servers stuck mid-sync already existed before this batch of reports, evidence that connected-but-not-syncing failures are a recognized, if unresolved, category of rippled and xrpld bug rather than something entirely new.

Rolling Back Fixes What Upgrading Broke

The clearest case is the consensus-lag report. A node operator described nodes that once updated validated ledgers in step with the network on 3.1.3 now gradually falling behind after the same hardware moved to 3.2.0. The reporter called it plainly: “a performance regression in 3.2.0.”

The fix, for now, is to not fix anything. Reinstalling 3.1.3 on the same box restores normal sync, according to the GitHub thread. That is an awkward answer nine days before nodes running anything below 3.2.0 are warned they will face service interruptions.

The validator key mismatch adds a quieter but stranger wrinkle. A validator’s public identity is what lets peers and monitoring tools confirm they are talking to the right server. On the affected node, the front-end validator-info service returned the new key while the underlying server_info call kept returning the key of the validator it replaced, a discrepancy developers are still working through rather than a network-wide failure.

The Amendment Clears Its Threshold Anyway

None of the open bugs has slowed the vote. Xrpld 3.2.0 shipped June 15 as what the XRP Ledger’s developers describe as a maintenance release retiring amendments active for over two years, alongside the fixCleanup3_2_0 amendment it introduces. That amendment bundles accuracy and rounding corrections for Single Asset Vaults and the Lending Protocol, plus fixes to the permissioned decentralized exchange and permissioned domains.

Amendment support has to clear 80% of trusted validators and hold there through the countdown; drop below that line before activation and the two-week timer restarts from zero. As of this week, 30 of the network’s 35 trusted validators, 85.71%, back fixCleanup3_2_0. Activation is scheduled for 09:57 UTC on July 29.

A Rename Forces Every Config Path to Change

Part of why this upgrade is more disruptive than a routine patch is that 3.2.0 is not just a bug-fix release. It renames the XRP Ledger’s core server software under proposal XLS-0095, a change that touches how operators configure and run their machines.

• Binary: rippled renamed to xrpld
• Config file: rippled.cfg renamed to xrpld.cfg
• Namespace: the internal ripple C++ namespace renamed to xrpl
• Defaults: default configuration and database directory paths moved

The tagged changelog behind the xrpld rename also notes changes to the server’s user agent and version string returned over RPC, details that matter to anyone running automated monitoring against a node’s API rather than to a typical XRP holder.

Adoption Climbed From a Quarter of Nodes to Two-Thirds

Weeks ago, when the first 3.2.0 bug reports began surfacing, barely a quarter of tracked nodes, around 26%, had made the move. This site’s own coverage found adoption stalled near 55 percent with the amendment vote still short of its threshold.

That has since shifted. According to XRP Ledger Explorer, 499 of 843 nodes (59.69%) now run version 3.2.0, while 303 nodes (36.24%) remain on 3.1.3. Validator adoption has moved faster still, reaching 65.77% with 98 validators upgraded. The climb continued even after the amendment first cleared its activation bar while exchanges lagged behind the rest of the network.

The bug reports, in other words, did not appear because too few nodes tried the new release. They appeared because enough of them finally did.

Exchanges and Small Operators Carry Different Risks

The four bug reports came from individual node and validator operators posting directly to GitHub, not from exchanges or large infrastructure providers with dedicated engineering staff. That split matters for who absorbs the risk in the final stretch before July 29.

A validator operator posting under the handle Vet used a lighter tone to deliver a blunt warning.

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!

Vet had opened the post with “Happy Hump Day to everyone, especially those who have upgraded their XRP Ledger nodes to 3.2.0!” before adding the warning about exchanges and projects still needing to move. For an exchange running redundant infrastructure, a stalled sync is an inconvenience to route around. For a single validator operator on Windows hardware watching their node close its own ledgers since genesis instead of joining the network, it is the whole job.

What Happens at 09:57 UTC on July 29

Two open questions define the next nine days: whether the reported bugs get patched before activation, and whether the roughly 40% of nodes still on older versions move in time.

• What we know: support sits at 85.71%, comfortably above the 80% floor; activation is set for 09:57 UTC on July 29; reverting to 3.1.3 resolves the consensus-lag regression; four distinct bugs are open and under review on GitHub.
• What is unconfirmed: the root cause of the Windows sync stall; whether the validator key mismatch is cosmetic or affects peer trust; whether any fix lands before the deadline; how many of the remaining unupgraded nodes will move in the final week.

Support currently sits 5.71 percentage points clear of the 80% floor, enough cushion that the amendment is on track to activate at 09:57 UTC on July 29 without triggering the two-week restart clause that kicks in only if support slips below threshold before then.

Frequently Asked Questions

What Is xrpld and How Is It Different From Rippled?

Xrpld is the same reference server software previously called rippled, renamed under proposal XLS-0095 as part of version 3.2.0. The consensus protocol itself did not change, but the binary name, default config file, internal namespace, and default data directories did, so operators with scripts or monitoring tools pointed at the old file paths need to update those references even after a clean upgrade.

What Happens If a Node Never Upgrades to 3.2.0?

A node still running 3.1.3 or earlier keeps validating by its own rules, but once fixCleanup3_2_0 activates it will not process the new transaction rules the amendment introduces. Validator Vet’s warning describes the practical result as service interruptions rather than an immediate shutdown, since the node effectively drifts out of sync with the rest of the network.

Does the Amendment Affect Regular XRP Holders or Just Node Operators?

The bundled fixes target Single Asset Vaults, the Lending Protocol, the permissioned decentralized exchange, Multi-Purpose Tokens, and permissioned domains, features used mainly by developers and institutions building on those newer XRPL modules. Someone simply holding or sending XRP is unlikely to notice the switch directly.

Who Maintains the XRP Ledger’s Software?

The XRP Ledger Foundation (XRPLF), a nonprofit separate from Ripple the company, maintains the open-source xrpld codebase on GitHub and runs the amendment process that governs upgrades like fixCleanup3_2_0, even though Ripple remains the network’s best-known corporate backer.

Where Can Node Operators Report Bugs From the 3.2.0 Upgrade?

Reports go directly to the XRPLF/rippled repository’s issue tracker on GitHub, the same place where the stalled-sync and validator key mismatch reports referenced above were filed. The project also maintains a wiki troubleshooting page specifically for servers stuck in a connected or syncing state.