XRPL’s known amendments page lists fixCleanup3_1__3 for activation on May 27, and by design the event is a maintenance upgrade.
Version 3.1.3 of rippled bundles fixes for NFTs, Permissioned Domains, Vaults, and the Lending Protocol, and the XRPL blog set the default vote to Yes because of the importance of those fixes.
The amendment process requires more than 80% support from trusted validators sustained for two weeks before the new rules become permanent.
What makes the episode worth examining beyond the deadline is what XRPL co-creator David Schwartz said about what a real fork would actually require, because his answer reveals how protocol legitimacy works on any blockchain.
Schwartz’s central point is that raw node count is a poor proxy for consensus power. A system where nodes vote in proportion to their number creates an attack surface where anyone can spin up thousands of machines at low cost.
In the XRPL model, each server operator maintains a curated set of validators the server trusts not to collude, the Unique Node List, and the UNL determines which validation votes the server counts during consensus.
A server receives validation messages from many nodes across the network, and the validators on its UNL determine which of those messages shape the server’s view of the ledger.
Schwartz explained that consensus legitimacy on XRPL flows through trust lists and validator coordination, producing a system in which UNL alignment and economic adoption determine which ledger survives a split.
Why a real fork requires a full coordination campaign
For the XRPL vote on May 27, servers that become amendment-blocked lose the ability to determine ledger validity, submit or process transactions, participate in consensus, or vote on future amendments.
That makes the deadline operationally important for any exchange, wallet, explorer, or infrastructure operator still running pre-3.1.3 software, as those servers become non-participants in the canonical ledger until the operator updates.
Amendment-blocked infrastructure loses access to the upgraded chain and lacks the coordination infrastructure to anchor a functional rival.
To produce a credible fork, a dissenting group would need validators willing to keep producing ledgers under the old rules, and without validators, there is no ledger stream to follow.
They would then need a competing Unique Node List that servers can configure or software can default to, because without a trusted validator list, nodes have no mechanism for coordinating around the old rules.
On top of that, they would need a code distribution that preserves the old rules and ships with defaults pointing to the rival UNL, and they would need infrastructure support from wallets, exchanges, explorers, and apps sufficient to make the old-rule ledger accessible and tradable.
XRPL documentation cites research showing that competing UNLs may need 90% overlap in the worst case to prevent a fork, meaning any rival UNL would need to share nearly the entire trusted validator set with the canonical one to maintain internal coherence.
A fork forming around a radically different validator set risks producing a ledger that cannot sustain its own consensus, let alone attract market adoption.
What the amendment process actually tracks is validator support, and the 80%-for-two-weeks threshold ensures that the entities the network trusts have reached a durable agreement before new rules become permanent.
A large share of unupgraded non-validator nodes can reflect infrastructure lag without implying anything about the canonical ledger’s trajectory.
The distance between infrastructure lag and a rival chain
In the bear case, exchanges, wallets, or infrastructure operators that lag behind the May 27 activation become amendment-blocked and stop functioning as ledger participants.
Users routing through those providers encounter service disruptions, such as transactions that cannot be submitted, explorers that cannot confirm ledger validity, and apps that cannot process payments.
That operational cost falls on operators who deprioritized the upgrade, and it is worth tracking, particularly for any major exchange or custodian still running pre-3.1.3 nodes at activation.
Sustained infrastructure lag across enough providers would create real user-facing friction even as the canonical ledger continues under the new rules.
In the bull case, fixCleanup3_1_3 activates on schedule with the validator supermajority intact, infrastructure operators update without major incident, and the episode becomes a routine amendment activation.
The fixes to NFTs, Permissioned Domains, Vaults, and the Lending Protocol take effect, and the network moves on. The governance debate the upgrade surfaces survives either outcome, because Schwartz’s explanation of what a real split would require applies to any future amendment.
Sustaining old rules requires a dissenting group running old software, recruiting validators around a competing UNL, and convincing wallets, exchanges, and market makers to recognize their ledger as the canonical XRP Ledger, against a default configuration pointing everyone else to the upgraded chain.
Every blockchain has a governance layer
Schwartz drew a comparison to Stellar, whose Protocol 24 upgrade is itself a stability fix for a state-archival bug in Stellar Core, which was a maintenance event requiring the same kind of coordinated validator adoption.
Bitcoin’s equivalent legitimacy layer runs through miners, economic nodes, client implementations, and exchange listings. Ethereum’s runs through validators, staking infrastructure, client diversity, core developers, and app-layer adoption.
What XRPL makes explicit through UNLs, other networks embed in mining power distribution, staking economics, or the social consensus around which client software developers trust.
The mechanisms differ across Bitcoin, Ethereum, and XRPL, while the dependence on coordinated human decisions to make rule changes permanent runs through all three.
The May 27 activation illustrates how XRPL’s governance layer converts validator agreement into ledger permanence, with UNL configuration determining which agreements count.
An operator who disagrees with fixCleanup3_1_3 has the technical freedom to run old software and configure a rival UNL.
Whether any exchange lists the resulting token, any wallet supports it, or any market maker provides liquidity is a question the protocol cannot answer for them.
That coordination disconnect is why protocol upgrades on well-adopted networks rarely produce durable forks: the economics of following the canonical chain almost always outweigh the economics of building a parallel chain from scratch, and the canonical chain is whichever the market decides is real.