The XRP Ledger team published a technical report on the July 30, 2026 incident in which a flood of manifest messages overwhelmed manifest-handling logic in xrpld and caused widespread peer disconnects. Many nodes rapidly lost a large share of their peers, including some UNL nodes. The underlying ledger did not halt or fork, remaining validators maintained consensus, and the developers reported no loss of funds, private-key compromise or ledger data-integrity failure.
The root cause involved protocol behavior that relayed received manifests regardless of trust status. A node whose cache accumulated large volumes of junk manifests could rebroadcast them whenever connections were re-established, allowing ordinary connection churn to amplify the flood. The report also describes tens of thousands of synthetic revocation-only manifests and large numbers of verified active manifests with unique keys observed during the event.
Developers accelerated a set of limits that had already been under testing, bounding individual manifest size, the number of entries in a message and the amount of untrusted manifest data retained in cache. Those protections were pulled into the emergency 3.2.1 release on July 31, with operators instructed to perform a graceful restart after upgrading to flush previously cached untrusted entries. The initial limits later proved too restrictive for normal gossip while the flood was still active, so version 3.3.0 adjusted the caps.
The report also lays out a broader security roadmap: stronger filtering of incoming traffic, limits and pagination for outgoing traffic, more general backpressure mechanisms, and better logging, metrics, tracing and monitoring. The incident is characterized as an availability and resource-exhaustion problem affecting peer connectivity and downstream services, not a consensus compromise or theft of assets.