David Schwartz, known online as “JoelKatz,” said his XRP Ledger hub has fully recovered from the problems that followed a network-wide attack on July 30. He wrote that all issues affecting his hub had been fixed and that it had been “rock solid” for the past two weeks, adding that two blank sections on recent charts were caused by monitoring problems rather than downtime at the hub itself.

His update offers a clearer picture of how XRPL infrastructure has behaved since the incident. The attack disrupted peer connectivity across the network by flooding nodes with fake or unverified validator manifests, but the ledger continued operating and did not halt or fork.

Recent hub data points to more stable operations

Metrics shared from Schwartz’s hub show 406 current peer connections, compared with an average of 401.12 from Aug. 25 to Sept. 8. During that span, peer counts ranged between 352 and 423, with 135 inbound connections and 271 outbound peers.

Other indicators also suggest conditions have stabilized. Median latency was 167.80 milliseconds and the 90th percentile measured 310.67 milliseconds, although latency did spike as high as 1.49 seconds during the period. Peer disconnections were running at 73 per five minutes, below the average of 84.6, while abuse-related disconnects stayed low at roughly 0.67 per five minutes.

How the July 30 attack disrupted XRPL

The incident targeted XRPL’s peer-to-peer communication layer rather than its consensus engine. Attackers sent large volumes of fake or unverified validator manifests, and the xrpld software did not have strong enough resource limits to deal with that amount of untrusted manifest processing.

As nodes tried to protect themselves from resource exhaustion, they began dropping peer connections. That degraded network connectivity for major hubs, including Ripple-operated infrastructure and XRPSCAN, even as the ledger itself continued closing blocks.

Why the ledger stayed online

According to the account in the source material, the attack weakened connectivity without stopping the consensus process. XRPL validators use trusted participants listed on their Unique Node Lists, and enough communication remained between validators for consensus proposals to keep moving through the network.

Redundancy also helped contain the disruption. Nodes keep multiple peer links, which meant traffic could still pass through alternative routes when some connections failed. Core validators were also able to rely on prioritized or reserved peer relationships to preserve communication.

Emergency fixes and remaining limits

Developers responded with emergency software changes on July 31, including version 3.3.0-rc6 and a 3.2.1 hotfix designed to restrict processing of untrusted manifests. Schwartz’s latest update suggests those measures, combined with operator response, helped restore more normal performance at his hub.

Even so, the available figures cover only one part of XRPL infrastructure. Schwartz’s hub data does not prove the network is immune to future attacks, and the July episode showed that peer connectivity can still be degraded at scale. The next confirmed takeaway is narrower: XRPL remained online during this attack, but future resilience will still depend on software defenses, validator connectivity, peer diversity, and continued operator response.

Source: Coin Edition