The XRP Ledger has issued xrpld version 3.2.1, a production hotfix aimed at stopping validator-manifest flooding that placed strain on portions of the network's peer-to-peer infrastructure on July 31, 2026. xrpld is the reference server software that participants run to operate nodes and validators on the XRPL. The blockchain continued closing ledgers without interruption, confirming that consensus remained fully operational even as individual nodes experienced abnormal data loads.

XRP Ledger Operations announced the release via its official X account:

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

Node administrators were directed to install the hotfix without delay and to perform a second restart shortly after the initial installation. The updated build introduces controls that prevent untrusted validator data from consuming disproportionate amounts of memory, bandwidth, storage, and processing capacity.

How the Manifest Flood Strained XRPL Peer Infrastructure

The XRPL relies on a set of validators that each operator designates as trusted through a Unique Node List (UNL). Only validators on a node's UNL participate directly in that node's consensus decision-making. Validator manifests link a validator's permanent master identity to the temporary signing key used during consensus rounds. This architecture enables operators to rotate working keys periodically while keeping master credentials offline and maintaining the validator's established network identity.

Earlier xrpld versions had no cap on the number of manifests associated with unknown validator keys that a node could accept, store, and rebroadcast. Because every node relays manifest data to its connected peers regardless of trust status, excessive untrusted data propagated across the network and accumulated in local caches.

The incident impacted peer-layer message propagation rather than account balances, individual transactions, or ledger validation rules. This distinction is meaningful for blockchain architecture generally: consensus-layer faults can halt a chain, while peer-layer faults degrade connectivity without compromising ledger integrity. Although the XRPL kept processing transactions and finalizing ledgers on schedule, the strain on peer connections degraded connectivity and slowed information distribution across the network.

Four Safeguards in Version 3.2.1

Version 3.2.1 introduces six commits spanning 13 files. The changes implement controls at four critical points where oversized or repeated manifest traffic could burden a node:

1. Pre-decode size rejection. xrpld now rejects individual manifests that exceed the expected encoded size before the decoding process begins, preventing oversized inputs from triggering unnecessary computational work.

2. Untrusted batch discarding. Nodes now discard incoming batches containing excessive numbers of untrusted manifests. Importantly, the software avoids automatically disconnecting older peers that transmit oversized batches, which reduces the risk of network fragmentation during the upgrade window.

3. Peer greeting limits. The hotfix restricts the bulk manifest greeting exchanged when two nodes establish a new peer connection. Trusted records remain fully available, while untrusted gossip is curtailed on both the sending and receiving paths.

4. Unknown-key storage cap. Each node can store a maximum of 100 manifests tied to unknown validator keys. Once that ceiling is reached, further entries are rejected, and untrusted manifests cease being persisted to disk.

Required Second Restart and Signing Key Verification

Following installation of the update, administrators were instructed to wait approximately one to two minutes and confirm that xrpld remained operational. Full synchronization is not required before proceeding to the next step.

Once the updated service is confirmed running, operators must restart xrpld a second time. The operations team characterized this second restart as an essential final step in the upgrade procedure.

Administrators running packaged installations should also verify Ripple's current software-signing key. Ripple rotated the GPG key used to sign xrpld packages in February 2026, meaning systems that have not yet trusted the replacement key may not receive automatic upgrades.

The hotfix introduces no network amendment and does not alter any transaction-processing rules. Instead, it establishes firm boundaries on untrusted peer data at every stage — before decoding, rebroadcasting, caching, or permanent storage. By restricting manifest size, batch volume, connection greetings, and unknown-key storage, the XRP Ledger has closed the four exploitation paths used during the July 31 flood. The incident demonstrated that peer-layer abuse can strain individual servers even while consensus continues to function normally, a class of vulnerability that other blockchain networks have also addressed through peer-protocol hardening.

A full post-mortem is expected to be shared with the community.