XRPL Urges Immediate Node Upgrade After Manifest Flood

On July 31, XRPL developers detected a surge of validator manifests that strained node resources. In response, the project published xrpld 3.2.1 — a hotfix that implements four protections to limit manifest propagation, cache growth and message batching. Ledgers continued closing during the event, and there is no confirmed evidence of lost funds or altered transactions. Operators running XRPL infrastructure should upgrade to 3.2.1 and follow a two-step restart process to ensure persisted unknown manifests are cleared.

Why the xrpld 3.2.1 hotfix matters

Validator manifests are signed records mapping a validator’s long-term master key to short-lived keys used for daily validation. Proper manifest handling is essential for secure key rotation and validator identity verification. Prior to this patch, nodes would accept, cache and rebroadcast correctly formed manifests even when the manifest referenced validator keys unknown to that node. That behavior could be abused by an attacker creating many ephemeral identities, forcing peers to expend memory, CPU, storage and bandwidth processing and sharing the unsolicited manifests — essentially a resource-exhaustion attack on XRPL nodes.

The xrpld 3.2.1 release — published July 31 and signed as the latest release on Aug. 1 — addresses this propagation vector by introducing limits on how untrusted manifests are received, cached and forwarded. The update includes six commits across 13 files, with four commits specifically restricting handling of untrusted manifests and unknown validator keys.

Four safeguards that curb resource exhaustion

1) Reject oversized manifests early

The first protection blocks manifest objects that exceed an expected size before the node fully decodes them. By dropping excessively large manifests up front, the node avoids unnecessary CPU and memory work that could otherwise be triggered by a single malicious object.

2) Limit batch sizes for untrusted manifests

The second safeguard caps the number of untrusted manifests that can be carried in a single P2P message. This cap applies both when receiving messages and when preparing manifest bundles to send to peers. Oversized batches are dropped, but the node does not automatically disconnect the peer that sent them — a design choice that helps patched and unpatched nodes remain connected during the upgrade rollout.

3) Cap unknown-key cache growth

The manifest cache now limits the number of unknown validator identities it will hold. The hard limit is set at 100 unknown keys. Once that threshold is reached, newly received manifests associated with unlisted keys are rejected, while manifests from known or trusted validators continue to be processed normally.

4) Adjust retention and propagation of untrusted data

The patch changes how untrusted manifest information is stored and shared. It targets unlisted peer gossip rather than manifests from configured or approved validators, ensuring legitimate validator key rotations remain functional. In short: trusted validator data remains available; unchecked gossip from unknown identities is constrained.

Operational guidance for node operators

Operators should update xrpld to version 3.2.1 immediately and follow a two-step restart procedure:

• Perform a normal software upgrade and start xrpld.
• Wait one to two minutes to confirm xrpld is running, then restart the service again.

The second restart is important because nodes could have retained unknown manifests in memory or on disk prior to the update. While the new code changes future processing, restarting ensures previously persisted or cached untrusted manifests are cleared and do not continue to affect the node’s operation.

Operators should also verify package-signing trust: Ripple rotated the GPG key used to sign xrpld packages on Feb. 18. Systems that have not trusted the replacement key may not receive automatic upgrades correctly, so confirm GPG trust and signature verification to avoid missed updates.

Who needs to act — and who doesn’t

This hotfix targets infrastructure providers rather than ordinary XRP holders. Users do not need to move funds, change wallet keys or create new accounts because of this manifest propagation issue. Exchanges, custodians, wallet back ends, data providers and any business running their own XRPL nodes should confirm they’re on xrpld 3.2.1 and have completed the restart process.

Network impact and the pending post-mortem

XRP Ledger Operations reported that ledgers continued closing normally during the manifest flooding incident. Based on available evidence, the event appears to have stressed node resources and peer-to-peer communication channels rather than causing ledger consensus failure, transaction alteration or confirmed financial loss. Developers have not issued a CVE or published an estimate of monetary impact related to the flooding.

A technical post-mortem is expected to follow. That report should clarify:

• When developers first detected the flood
• The identity, scale and origin of the manifests transmitted
• Which nodes — if any — became unavailable during the event
• How rapidly operators adopted the 3.2.1 hotfix

Even though the shared ledger remained operational, slow adoption of the patch could leave individual servers vulnerable to renewed flooding. The post-mortem and adoption metrics will be important to measure the incident’s scope and the community’s response.

Context: recent XRPL releases and adoption

The 3.2.1 hotfix follows the broader 3.2.0 rollout that began June 15. Version 3.2.0 renamed the reference server from rippled to xrpld and introduced infrastructure changes requiring operators to update service configurations. As with earlier upgrades, validators tended to adopt 3.2.0 faster than the wider node network; the manifest flood underscores another critical reason for remaining operators to update promptly.

Notable infrastructure figures have already moved to the new naming and server features. For example, developer David Schwartz migrated his XRPL infrastructure to 3.2.0 as the community prepared for the new server name and protocol changes. Earlier deadlines, such as the 3.1.3 amendment activation, similarly drove adoption across the network.

What’s next

Until the XRPL post-mortem and adoption statistics are published, the confirmed mitigations are limited to the xrpld 3.2.1 release, its four manifest controls, and the operators’ upgrade-and-restart guidance. Node operators should prioritize installing the hotfix, confirming package signature trust, and completing the two-step restart to minimize exposure.