XRP Ledger activates fix, blocks nodes below 3.2.0

XRP Ledger has activated its fixCleanup3_2_0 amendment, making version 3.2.0 the minimum software release required for nodes to remain compatible with the mainnet.

• The amendment received 85.71% validator support, with 30 votes in favor and five against.
• Nodes running version 3.1.0 or earlier are now amendment-blocked until operators upgrade.
• The update fixes issues affecting vaults, lending, permissioned trading and Multi-Purpose Tokens.
• Version 3.2.0 also renames the core server software from rippled to xrpld.

XRPScan data shows that fixCleanup3_2_0 is now active after securing support from 30 of the 35 trusted validators that participated in the vote. Five validators opposed the amendment.

XRPL amendments that change transaction processing must maintain at least 80% support among trusted validators for two consecutive weeks before activation. The latest proposal cleared that requirement with 85.71% consensus.

Activation immediately affects infrastructure operators running older software. Nodes on version 3.1.0 or below are now "amendment blocked," meaning they cannot follow the updated rules governing validated ledgers.

The warning applies to exchanges, wallet providers, payment services, developers and other businesses that operate their own XRPL infrastructure. Users holding XRP in self-custody wallets do not need to change their tokens or move funds because of the amendment.

The amendment introduces a package of protocol corrections included in the XRP Ledger 3.2.0 release. It does not add a new user-facing product or alter XRP's supply.

Among the changes are precision and rounding fixes for Single Asset Vaults and the Lending Protocol. The package also corrects an invariant affecting valid offer deletions on the Permissioned DEX.

Other changes validate non-canonical Multi-Purpose Token amounts, add a zero DomainID check for permissioned domains, and introduce an invariant that checks whether deleted accounts leave directly accessible ledger objects behind.

XRPL data cited after activation showed that 105 validators, or 70% of the network total, were running version 3.2.0. Another 35 validators, representing 23.33%, remained on version 3.1.3.

Among other nodes, 582, or 68.88%, had adopted version 3.2.0, while 228 nodes, or 26.98%, were still using version 3.1.3. Operators on 3.1.3 are above the version range identified in XRPScan's amendment-block warning, although XRPL developers have urged all operators to complete the 3.2.0 migration.

Released in mid-June, version 3.2.0 also changed the name of XRPL's reference server implementation from "rippled" to "xrpld." The rename follows XLS-0095, a proposal designed to link the software's identity more directly to the XRP Ledger.

The change extends beyond the server executable. Operators upgrading from version 3.1.3 must rename the configuration file from rippled.cfg to xrpld.cfg and revise related database paths, packages, scripts, deployment settings, service definitions, and metadata.

XRPL's migration documentation provides steps intended to preserve existing node data while replacing the former naming conventions.

Developers describe version 3.2.0 primarily as a cleanup and maintenance release. It retires amendments that had remained active for more than two years and continues dividing the libxrpl codebase into smaller modules to support future maintenance.

The activation comes as the ledger handles a growing amount of tokenized real-world assets. As crypto.news reported on July 26, XRPL added about $2.6 billion in RWA value over six months, excluding stablecoins.

That ranked the network second for net RWA inflows during the period, behind BNB Chain's roughly $3 billion. Stellar followed with about $2.1 billion.

XRPL's combined distributed and represented RWA value reached approximately $4.38 billion, while stablecoins added another $995.12 million. The wider total exceeded $5.37 billion.

For US businesses using XRPL for tokenized assets, payments, or exchange infrastructure, the amendment creates an operational requirement rather than a new regulatory rule. Operators must keep their server software compatible to avoid service interruptions as activity on the network expands.