On June 15, 2026, the XRP Ledger Foundation published version 3.2.0 of the protocol’s reference software, xrpld. As of today, July 10, the network presents a scenario that warrants detailed examination: 89% of the validators on the default Unique Node List (UNL)—31 out of 35—are already executing the new version. However, the amendment associated with this update, fixCleanup3_2_0, currently holds the support of only 19 of those 35 validators (≈54%), falling well short of the 80% threshold required for definitive activation.
Nevertheless, it compels a necessary reflection on the governance of decentralized networks and, specifically, on the fragile relationship between software adoption and the political will of the stakeholders who sustain the network.
XRP Ledger Two Processes, One Network
The current confusion stems from a flawed premise frequently echoed across forums and social media: assuming that installing a new binary is equivalent to voting in favor of its changes. On the XRP Ledger, the software update and the activation of an amendment are independent processes that operate on entirely distinct planes.
The first is purely technical: node operators download, compile, and execute the new binary. This is voluntary and requires no consensus beyond the individual decision of each operator. The second is governance: validators must cast an explicit vote for each amendment contained within that software. An amendment does not activate automatically merely because the code resides on a validator’s hard drive; it requires over 80% of the UNL validators to vote affirmatively and maintain that support for two consecutive weeks.
It responds to a well-documented security logic: separating the technical capacity to implement a change from the political willingness to adopt it. A validator may have the software installed and yet vote against an amendment because they consider it insufficiently audited, because it impacts their operational interests, or simply because they have not yet finalized their decision. The XRP Ledger consensus process therefore demands a supermajority that is not merely technical, but also political.
The Gap Between Validators and General Nodes in XRP Ledger
Beyond the amendment voting, a second gap deserves attention: the one separating the UNL validators from the rest of the network’s nodes. While the former have largely adopted v3.2.0, only 43% of the approximately 833 active nodes have performed the update. The remaining 51% are still executing v3.1.3, revealing a fragmented adoption at the base infrastructure layer.
This disparity is not unusual in the XRP Ledger’s update cycles, but the magnitude of the difference suggests that a significant portion of operators are deliberately adopting a wait-and-see strategy. They are not updating until the associated amendment has been approved. From an operational risk management perspective, this is understandable: investing time and resources in an update whose fundamental changes have not yet received the necessary backing is premature and costly.
However, when the fixCleanup3_2_0 amendment finally activates—if it does—nodes still running previous versions will enter an amendment-blocked state. In that state, the server can no longer determine ledger validity, process transactions, or participate in consensus. It is not a permanent lockout, but it implies a service interruption until the operator performs a forced migration, creating a window of instability for services dependent on those specific nodes.
What Does fixCleanup3_2_0 Actually Contain?
The amendment is neither a cosmetic change nor a controversial modification to the token’s economics. fixCleanup3_2_0 groups strictly technical corrections for functionalities introduced in previous cycles: precision and rounding adjustments for Single Asset Vaults and the Lending Protocol, invariant corrections for the permissioned DEX, validation of non-canonical amounts in Multi-Purpose Tokens, and a new check to prevent deleted accounts from leaving accessible artifacts in the global state.
Additionally, it removes over 30 amendments that have been active for more than two years, cleaning the codebase of obsolete legacies. It is, definitively, a maintenance update that resolves known issues and reduces the accumulated technical debt of the network. That an amendment of this profile—technically necessary and uncontroversial in its content—faces difficulty in reaching quorum is a datum that should be interpreted as a symptom of either fatigue or extreme caution within the current governance framework.
Ripple’s Vote of the UNL
Ripple, whose founders created the XRP Ledger, has voted in favor of the amendment. Bitso, Peersyst, and a group of university validators have also done so. However, 19 affirmative votes out of 35 are insufficient; at least 28 are needed to reach the required supermajority. The 35-validator UNL is not a monolithic body nor subject to a single voting discipline. Each operator has its own risk assessment, its own commercial incentives, and, in many cases, its own fiduciary obligations to the users relying on its infrastructure.
That an amendment fails to reach 80% does not necessarily mean there is active opposition; it may simply indicate indecision, a lack of coordination, or diverging priorities among operators. The process is designed to require a supermajority precisely to prevent an active minority from imposing changes on a passive majority. But the reverse side of this coin is that a passive minority—validators who do not vote, who delay their decision, or who have not configured their server to cast an automatic vote—can indefinitely block an update. The system does not distinguish between an active “no” and a “no” by omission, and it is this asymmetry that currently sustains the stalemate.
The software update is necessary but not sufficient; the governance of the XRP Ledger demands active and sustained participation in votes, not merely passive technical upgrading. Nodes that wait for the amendment to activate before updating risk being temporarily cut off from the network at a time when transactional activity could be at its peak.
For developers and proponents of changes, the stagnation of fixCleanup3_2_0 raises a broader structural question: is the XRP Ledger’s amendment process becoming excessively conservative and slow for maintenance corrections? The 80% barrier over two weeks is intentionally high, and that is a strength of the system when facing radical changes. But if maintenance amendments—those that fix bugs and improve stability without altering the protocol’s economy—encounter resistance or indifference, the cost of governance could begin to weigh on the network’s technical evolution, discouraging future optimization proposals.
The current state of the XRP Ledger is not a failure. It is a rigorous illustration of how decentralized governance operates in practice: with noise, with operational delays, with actors making decisions based on their own incentives, and with processes that demand patience, but also active vigilance.
Software adoption by validators has surpassed the technical threshold; the amendment vote has not. This discrepancy is not a problem to be “solved” hastily or with emergency patches; it is the symptom of an ecosystem still finding the balance between technical efficiency and governance prudence. The v3.2.0 update is already on the servers, but the genuine consensus required to activate it remains in the hands of a few validators who, for now, are staying on the sidelines.
For industry observers and risk managers, the operational lesson is that on decentralized networks, code updates are merely the first step. Genuine consensus—the one that changes the network’s validation rules—requires more than installing a binary. It requires that actors with veto power exercise that power deliberately and in a coordinated manner.
