TLDR:xrpld 3.2.1 limits oversized validator manifests before decoding, reducing memory and processing strain.The hotfix caps untrusted manifest batches, peer greetings, cache growth, and disk persistence across nodes.XRP Ledger consensus continued closing ledgers normally despite pressure on peer-to-peer infrastructure.Node operators must upgrade, verify Ripple’s signing key, and complete a second restart after installation.The XRP Ledger has released xrpld 3.2.1 after a validator-manifest flood strained parts of its peer-to-peer infrastructure on July 31. Despite the disruption, the blockchain continued closing ledgers normally, showing that consensus remained active while individual servers faced abnormal data pressure.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, 2026Consequently, XRP Ledger Operations instructed node administrators to install the hotfix immediately and perform a second restart shortly after installation. The latest production build adds limits designed to prevent unknown validator data from consuming excessive memory, bandwidth, storage, and processing capacity.How the Manifest Flood Strained XRPL Peer InfrastructureValidator manifests connect a validator’s permanent master identity to the temporary signing key used during consensus. This structure allows operators to rotate working keys while keeping master credentials offline and preserving the validator’s established identity.However, earlier xrpld versions could accept, store, and rebroadcast unlimited manifests linked to unknown validator keys. As a result, excessive untrusted data could spread across connected peers and accumulate inside local caches.The incident affected peer-layer message propagation rather than balances, transactions, or ledger rules. Although XRPL continued processing transactions and closing ledgers, strained peer connections could still weaken connectivity and slow information distribution.To address that exposure, version 3.2.1 introduces six commits affecting 13 files. Together, the changes apply controls at four points where oversized or repeated manifest traffic could burden a node.First, xrpld rejects individual manifests that exceed the expected encoded size before decoding begins. Therefore, oversized inputs cannot trigger unnecessary processing.Second, nodes discard incoming batches containing excessive numbers of untrusted manifests. Nevertheless, the software avoids automatically disconnecting older peers that send oversized batches, reducing fragmentation risks during the upgrade period.Third, the hotfix limits the bulk manifest greeting exchanged when nodes establish new peer connections. Trusted records remain available, while untrusted gossip is restricted across both sending and receiving paths.Finally, each node can store only 100 manifests associated with unknown validator keys. Once that threshold is reached, additional entries are rejected, and untrusted manifests are no longer written to disk.Four Safeguards and the Required Second RestartAfter installing the update, administrators were instructed to wait one or two minutes and confirm that xrpld remained operational. They do not need to wait for the node to become fully synchronized before completing the next step.Once the updated service is confirmed as running, operators must restart xrpld again. The operations team described this second restart as an important final part of the upgrade process.Meanwhile, administrators using packaged installations should verify Ripple’s current software-signing key. Ripple rotated the GPG key used to sign xrpld packages in February 2026. Therefore, systems that have not trusted the replacement key may fail to receive automatic upgrades.Overall, the XRP Ledger hotfix introduces no network amendment and does not change transaction-processing rules. Instead, it establishes firm limits on untrusted peer data before that information reaches decoding, rebroadcasting, caching, or permanent storage.By restricting manifest size, batch volume, connection greetings, and unknown-key storage, XRPL has closed four paths used during the July 31 flood. Although the network continued producing ledgers, the incident showed that peer-layer abuse can still strain individual servers while consensus remains operational.The post XRP Ledger Releases 3.2.1 Hotfix to Stop Validator Manifest Flooding appeared first on Blockonomi.