Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
XRP XRPL network returns to stability: CTO Emeritus David Schwartz confirms that Hub metrics have returned to normal
David Schwartz, former chief technology officer (CTO) of Ripple and one of the original architects of XRP Ledger ($XRP), said that the XRPL Hub he manages has remained stable for two consecutive weeks. The phenomenon was seen as the clearest sign that the network has recovered from the devastating Manifest flood attack it suffered in July.
Hub indicators return to normal levels
Schwartz reported that his Hub currently has 406 active connections, which is basically consistent with the recent average of 401. The Hub typically reliably maintains approximately 400 concurrent connections, peaking at 423. During monitoring, the latency dropped to 165 milliseconds.
Intermediate node latency has also remained near recent averages, and node disconnection has decreased. The number of "disconnections due to abuse", a key indicator of residual attack activity, remains limited. The telemetry data covers the time period from August 25 to September 8, and the Hub is one of the key relay nodes of XRPL through which other network nodes communicate.
The only exception that occurred was a one-time delay surge on September 6, but the algorithm successfully contained it without affecting the consensus mechanism.
Review of July Events
On the evening of July 30, 2026, a large number of Manifest messages spread in XRP Ledger's point-to-point network, crushing the Manifest processing logic in xrpld and causing large-scale node disconnection. Many nodes lost most of their peers within minutes, including two UNL (Trusted List) nodes operated by Ripple and XRPSCAN.
The attacker injected a large number of fake or unverified verifiers Manifest into the network. These cryptographic certificates allow the verifier to announce changes to its master key or temporary signing key. However, because xrpld lacks sufficient resource constraints when handling a large number of untrusted Manifest, pressure on CPU and memory resources increases sharply as nodes try to verify, track, and store incoming data.
Despite the attack, the underlying ledger never stopped running or forked, and the remaining UNL validators remained a consensus throughout the flood attack. There were no financial losses, private keys leaked or ledger data integrity issues.
Community developers responded quickly, diagnosed the root cause, and pushed emergency mitigation measures to multiple nodes within hours. Subsequently, a separate public hot fix (xrpld version 3.2.1) was released on the evening of July 31.
The 3.2.1 update introduces four safeguards:
- rejects excessively large validators Manifest until fully decoded;
- limits the number of incoming Manifest batches that nodes process simultaneously;
- limits the amount of Manifest data shared with newly connected peers;
- Prevent nodes from storing Manifest from more than 100 unknown verifier keys.
Schwartz's latest Hub data shows that these fixes are still effective under actual operating conditions, providing the XRP community with confirmation of data support and proving that the Peer layer of the network has achieved stability.
