XRPL Upgrade Gaining Ground: Validators Adopt v3.2, Security Amendment Lags

The XRP Ledger's latest software release is leading among the network's validators by stake weight — but by raw node count it trails the older v3.1.3. And the security amendment bundled with the upgrade is running through a separate, slower vote that requires 80% of the trusted validator list before it can activate.

Two Separate Things Moving at Different Speeds

The XRPL upgrade process works in two phases that are easy to conflate. First, validators update their node software to a new version — that's a decision each operator makes independently. Second, new protocol features packaged as amendments require a supermajority vote across the trusted validator list before they actually change network behavior.

The new release leads on stake weight, meaning the validators controlling the largest share of ledger influence have already upgraded. That's the group that matters most for consensus. However, it trails on raw node count — there are still more nodes running v3.1.3 than the newer release. Smaller operators tend to upgrade more slowly.

The security amendment bundled with the new version is where the slower picture emerges. Even validators running the new software don't automatically vote yes on every included amendment. The security amendment requires 80% of the trusted validator list — a high bar that takes weeks to accumulate when operators are cautious about protocol-level changes.

Why Node Count vs. Stake Weight Tells Different Stories

The XRPL trusted validator list (UNL) is not a simple head count. Each validator carries different weight based on its participation history and operator identity. Ripple, XRPL Labs, Coil, and major exchanges operate validators with significant trust weight. When those operators upgrade quickly, the stake-weighted picture improves faster than the raw node picture — which includes many smaller or hobbyist validators that upgrade on a longer cycle.

Neither metric is a complete picture on its own. Stake weight matters for what gets proposed and agreed in consensus. Node count matters for network decentralization and redundancy. A gap between the two is normal during upgrade cycles and is not a sign of network instability.

What the Security Amendment Actually Does

The details of the specific security amendment are technical, but the process is designed to be deliberate. XRPL amendments that affect security or consensus mechanics are intentionally given a longer voting window and a higher threshold precisely because a bug or unintended behavior at that level would affect the entire ledger. The 80% threshold and the separate voting track from software adoption are features of the governance model, not bugs.

For users, token holders, and developers building on XRPL, the practical impact of this particular upgrade is minimal until the amendment activates. The ledger continues to operate normally on existing consensus rules until the supermajority vote completes.

What to Watch

The vote percentage for the security amendment is trackable on-chain. When it crosses 80% and holds there for a sustained period, the amendment locks in for activation. That timeline will depend on how quickly the remaining validators — particularly smaller operators — upgrade their node software and cast a yes vote on the amendment. Based on typical XRPL governance cycles, that process takes several weeks from the point where stake-weight leaders have already adopted the upgrade.