XRPL v3.2.0 Passes 66% of Nodes as a Fix Heads to a Vote

Two thirds of the XRP Ledger's trusted validators were running version 3.2.0 as of July 21, six weeks after the release shipped. The count stood at 99 validators, 66% of the trusted set, with 481 nodes, or 57.33% of the network, on the new software and 42 validators, 28% of the set, still on v3.1.3. A bug-fix amendment carrying the version's name, fixCleanup3_2_0, had meanwhile entered the last stage before it takes effect. Its support stood at 85.71%, with 30 validators voting for it and five against, and activation was scheduled for July 29 at 09:57 UTC provided that support held. The fix corrects accuracy and rounding errors in two of the ledger's newer features and addresses issues in two more.

Signal, hold, activate

Rules on the XRP Ledger do not change when a release ships. Each change arrives in the software as an amendment, a named feature that is present but switched off, and validators vote on it continuously by signalling support in the ledgers they help close. An amendment needs the backing of 80% of the trusted validator set, the list of validators a server counts when deciding what the ledger says, and that level has to hold across a two-week window, not merely be touched once. A dip below the threshold restarts the count. When the window completes, the amendment switches on for the whole network at a single point, and that is the reason an activation carries a precise timestamp. Operators still running older software risk falling out of step with the rest of the network once rules they cannot apply take effect, so the share of servers on the current release matters more as the date approaches.

99 validators, 481 nodes, 42 holdouts

The three figures count different populations. Validators are the servers whose votes decide the contents of each ledger, and 99 of them, 66% of the trusted set, had upgraded; nodes are the wider population of servers that follow and serve the chain, and 481 of those, 57.33%, had done the same. The 42 validators still on v3.1.3 are the ones that matter for an activation date, because they are the servers that would have to process the amended rules. Six weeks had passed since the June 15 release that renamed rippled to xrpld under XLS-0095, a rename that changed the name of the server software and nothing about how the ledger works. Upgrading and voting are separate acts. Running the release makes an amendment available to a validator, and the operator still has to signal for or against it.

Rounding errors in features that hold balances

fixCleanup3_2_0 addresses accuracy and rounding errors in Single Asset Vaults and the Lending Protocol, along with issues in Permissioned DEX and Permissioned Domains. Rounding is not a cosmetic matter in features that hold balances on behalf of many accounts. A fractional unit dropped in the wrong direction on each deposit, redemption or interest calculation accumulates across every later operation until the recorded totals no longer match what is owed. The "fix" prefix marks an amendment as a correction to behaviour already on the ledger rather than a new capability, but corrections go through the same 80% vote and the same two-week window as features do, because they change how transactions are processed and every server has to make the change at the same moment. The vote was not unanimous. Five validators signalled against it while 30 signalled in favour, leaving support comfortably above the threshold but not without dissent.

A date the holdouts cannot move

If support stayed above 80% through the end of the window, the fix would take effect at 09:57 UTC on July 29 and the four affected features would compute the same results on every server that had upgraded. The open item is the 28% of validators still on the previous release six weeks after it was superseded, a share the activation clock does not wait for. The ledger's development calendar has run on its own track this month, separate from the token's own month in the market, and adoption at 66% of validators and 57.33% of nodes measures how quickly the network follows a release, not the release itself.