Node operators running the XRP Ledger are being told to move fast. Ripple’s Director of Engineering, Vijay Khanna, urged infrastructure providers on Aug. 2 to complete an XRP Ledger node upgrade to xrpld version 3.2.1 after developers spotted a validator manifest flood hitting the network on July 31. The ledger kept producing blocks throughout the incident, but the episode exposed a resource-exhaustion weakness that Ripple has now moved to close with a targeted hotfix.
Summary
Key takeaways
- A validator manifest flood on July 31 pushed Ripple to release xrpld 3.2.1 as an emergency hotfix published Aug. 1.
- The XRP Ledger kept closing ledgers normally throughout the event, with no confirmed loss of funds, altered transactions, or consensus failure.
- Four new safeguards now cap manifest size, message batch sizes, cache growth for unknown validator keys, and outbound sharing of untrusted data.
- Operators must upgrade, confirm xrpld is running, then restart a second time to clear any manifests that persisted before the patch.
- Ripple rotated its package-signing GPG key on Feb. 18, so operators must trust the new key for the update to install correctly.
What triggered the XRP Ledger node upgrade
The flood centered on validator manifests, the cryptographically signed records that link a validator’s permanent master identity to the temporary key it uses for day-to-day validation traffic. When a validator rotates that temporary key, it broadcasts a new manifest signed by its master key so peers across the network can verify the change is legitimate.
Before the fix, nodes would accept, cache, and rebroadcast manifests tied to validator keys they had never seen before, as long as the data was structurally valid. That created an opening: someone could generate large numbers of unknown identities and force every connected node to burn memory, storage, bandwidth, and processing power just handling the noise. The public code record tied to the incident describes it as a manifest propagation flaw rather than a breach of any account or key.
Despite the pressure on node resources, XRP Ledger Operations reported that the network kept closing ledgers normally the entire time. That distinction matters: the flood strained infrastructure, but it never reached the point of disrupting consensus or corrupting transaction history.
Inside the xrpld 3.2.1 hotfix
Ripple’s response, dated July 31 and published as a signed release early on Aug. 1, packs six commits across 13 changed files, four of which directly restrict how nodes handle manifests from unrecognized validators. Together they form four safeguards designed to prevent the same kind of flood from draining node resources again.
The first rejects an oversized manifest before a node even finishes decoding it, cutting off the processing cost of abnormally large objects at the door. The second caps how many untrusted manifests can travel inside a single network message, whether a node is receiving data or preparing it for peers; oversized batches get dropped without automatically severing the connection, which lets patched and unpatched nodes keep talking to each other during the rollout.
A third change limits how many unknown validator identities a node’s manifest cache can hold, with the final code setting that ceiling at 100. Once the cache fills, new unlisted keys get turned away while trusted and previously recognized validators continue operating without interruption. The fourth adjustment changes how untrusted manifest data spreads across the network, tightening outbound sharing of unlisted peer gossip while leaving data tied to configured or approved validators untouched. That balance is intentional: normal validator key rotation still works, but unchecked cache growth from strangers does not.
What node operators need to do now
Khanna’s guidance is straightforward but has to be followed in order. Operators should install the standard update, wait one to two minutes, confirm that xrpld is actually running, and then restart the service a second time.
That second restart is not a formality. Any manifests an operator’s node absorbed and stored before the patch could still be sitting in memory or on disk. Installing 3.2.1 changes how the software handles new manifests going forward, but only a fresh restart clears out data the node picked up while it was still vulnerable. Skipping that step risks leaving stale, untrusted manifests in place even after the code itself has been fixed.
There’s a second wrinkle worth flagging: package trust. Ripple rotated the GPG key it uses to sign xrpld packages back on Feb. 18, and installations that haven’t already trusted that replacement key may not pull the update automatically. Anyone managing XRPL infrastructure should check their signing-key configuration before assuming the upgrade will apply cleanly.
Importantly, this XRP Ledger node upgrade is aimed squarely at infrastructure, not individual holders. Exchanges, custodians, wallet back-ends, data providers, and any business running its own XRPL servers need to confirm their node version and restart status. Ordinary XRP holders don’t need to move funds, change wallet keys, or open new accounts because of this issue — the fix lives entirely at the server layer.
Why the lack of damage still matters
No CVE identifier or financial-loss estimate has been published in connection with the flood, and the available evidence points to strained node resources and peer-to-peer traffic rather than any confirmed theft, altered transaction, or consensus breakdown. That’s a genuinely reassuring outcome for a network that settles billions in value, but it doesn’t mean the incident was cost-free. Resource-exhaustion attacks that don’t touch funds can still degrade service, slow down infrastructure providers, and create openings for follow-up attempts if patching lags.
That’s the piece still missing from the public record. XRP Ledger Operations has said a technical post-mortem will follow, but as of Aug. 2 that report hadn’t been published. Until it lands, the identity of whoever sent the flood, the actual volume of manifests involved, and how quickly node operators across the network adopted 3.2.1 all remain open questions. The report is also expected to clarify when developers first detected the unusual traffic and whether any individual nodes became unreachable, even though the shared ledger itself never stopped producing blocks.
This isn’t the network’s first forced software transition this year. The 3.2.1 hotfix follows the larger 3.2.0 rollout on June 15, which renamed the reference server from rippled to xrpld and required its own round of configuration updates — the same release that pushed XRPL infrastructure operator David Schwartz to migrate his setup ahead of the new naming and protocol changes. Node operators also had to meet an earlier 3.1.3 deadline tied to an amendment activation. Taken together, the pattern suggests XRPL’s infrastructure layer is being asked to keep pace with a tightening update cycle, and operators who fall behind on any single release risk carrying forward vulnerabilities the network has already fixed elsewhere.
FAQ
What caused the need for the XRP Ledger node upgrade?
A validator manifest flood occurred on July 31, causing resource exhaustion on nodes, which required the xrpld 3.2.1 hotfix to mitigate the problem.
Did the manifest flood cause any lost funds or consensus failures on the XRP Ledger?
No confirmed financial losses, altered transactions, or ledger consensus failures were observed during the flood, according to XRP Ledger Operations.
What are the main safeguards introduced in xrpld 3.2.1?
The update limits manifest size, message batch sizes, unknown-key cache growth (capped at 100 entries), and outbound sharing of untrusted manifests.
Who needs to upgrade to xrpld 3.2.1 and what are the operational steps?
Infrastructure providers running XRPL nodes — including exchanges, custodians, and wallet operators — must upgrade, verify the software is running, and then perform a second restart to clear any persisted manifests.
Article produced with the assistance of artificial intelligence and reviewed by the editorial team.
