Schwartz’s XRPL Hub Hits 500 Peers With No Cause

David Schwartz said on September 17 that his private XRP Ledger hub is holding more than 500 peers again, and that he still cannot explain the calm. Charts in that post showed 501 active connections, near a 509 high across a window that began around September 3.

Operators were told the same day to install xrpld 3.4.0 for peer protocol hardening. That build cannot account for two weeks of fewer disconnects, and Schwartz did not credit it.

Schwartz’s Hub Is Holding 500 Peers Again

Ripple’s CTO emeritus posted the reading at 17:40 GMT on September 17, with four monitor graphs attached. “Over the past two weeks my hub has mysteriously gotten more stable and reliable with fewer peer disconnects. I’m not sure of the cause, but I’ll take it. I’m back over 500 peers,” he wrote. He added that a tiny gap around September 15 and 16 was a monitoring issue only.

Over the past two weeks my hub has mysteriously gotten more stable and reliable with fewer peer disconnects. I'm not sure of the cause, but I'll take it. I'm back over 500 peers!

The tiny gap/glitch around Sep 15/16 is a monitoring issue only. pic.twitter.com/PJUHQWmKLK

— David 'JoelKatz' Schwartz (@JoelKatz) September 17, 2026

The machine is a public hub, a well-connected relay for other servers, not a trusted validator on the Unique Node List. When it holds hundreds of live peers, other nodes can pull ledger data and gossip through it. When those peers drop, the relay looks sick even if consensus is still closing ledgers.

On September 8 he had already claimed a cleaner stretch. “All issues with my hub have been fixed and it has been rock solid for the past two weeks,” he wrote, with the two blank spots on those charts blamed on the monitor, not the hub. Two days later he walked that perfection back: two events had cut the peer count and pushed some latencies up, which he tied to minor network disruptions rather than an XRPL-specific fault. Median round-trip time rose by less than 20% at the worst moments, and about 80% of peer connections were unaffected.

By September 17 the same public graphs sat back over 500. Early September readings on those charts were about 400 peers. The lift is the easy part to see. The cause is not.

He Has One Data Point and Two Theories

Two hours after the 500-peer post, Schwartz wrote that he had one data point and two theories, one good and one bad. The data point was simple: the number of stable inbound connections had gone up.

The good theory is that the number of peers running software with the manifest problem has decreased, making for more stable peer-to-peer connections. The bad theory is that someone is just making meaningless inbound connections to my hub for some reason, maybe to try to consume connection slots. I have plenty to spare, so this isn’t doing anything to my hub. But maybe it’s some attack on other XRPL nodes. I haven’t investigated this in detail and it’s basically just a wild guess.

David Schwartz, CTO Emeritus at Ripple, on X

A later note turned the bad theory into a joke. Someone, he said, might be making meaningless inbound stable connections to make him feel good, and if so they could stop. The line is funny because it names a real measurement problem. A hub’s peer counter goes up when lasting links arrive. It also goes up when idle clients sit on inbound slots and do no useful gossip.

Fewer disconnects are the cleaner signal, because a padded inbound list does not, by itself, stop healthy peers from falling off. Schwartz still would not say which of those two stories matched the graphs. He also did not point at 3.4.0.

The Two-Week Window Started Before 3.4.0

Version 3.4.0 of xrpld, the reference server, was published on September 16. XRP Ledger Operations posted the public rollout at 20:47 GMT on September 17, more than three hours after Schwartz’s hub thread, and listed “peer protocol hardening” among the stability items. The release notes tell operators to upgrade to version 3.4.0 as soon as possible.

That timing is fatal to the tidy version of the story. Schwartz’s two-week window runs from about September 3 through September 17. A binary that landed on September 16 cannot be the reason disconnects had already been falling for a fortnight. At most it can help whatever comes next, once enough hubs actually run it.

WHICH BUILD CAN EXPLAIN THE CALM

Schwartz’s good theory lines up with the middle row. If fewer peers still run the code that mishandled manifests, handshakes stop dying, and a hub’s live set can climb without anyone shipping a new miracle. That is a slow cleanup story, and it is much less exciting than pinning the 501 reading on a build that was a day old.

July 30 Left the Hubs on Single-Digit Peers

The “manifest problem” Schwartz still cites is not folklore. On the evening of July 30, 2026, Pacific time, a flood of synthetic validator-manifest messages moved across the overlay and produced mass peer disconnects on July 30. The ledger did not halt or fork. Peer connectivity did.

THE JULY 30 OVERLAY CLOCK

1. July 30, 7:45 p.m. PT: Earliest sign of trouble, found later in logs: at least one Ripple hub stops producing normal logs.
2. July 30, 8:05 p.m. PT: Peer-disconnect alerts fire at once across 23 mainnet hosts, covering hubs, validator-hubs, and Clio instances in several regions.
3. July 30, 8:51 p.m. PT: An incident call starts after XRPSCAN’s validator page shows both its own validator and Ripple’s marked offline.
4. July 30, 9:05 p.m. PT: Hubs fall to single-digit peer counts, against a normal of several hundred. Ripple’s UNL validator is down to 1 peer because it depends on the hub cluster for peering.
5. July 30, 10:26 p.m. PT: The in-flight 3.3.0-rc6 build, which already held most of the cache caps, is deployed to the hubs.
6. July 31, 7:15 p.m. PT: Version 3.2.1 is tagged and released, with a required graceful restart to flush cached junk.

Schwartz had seen the same failure on his own box that morning. He was losing peers with onReadMessage: No message of desired type during negotiation, then losing the connection. An ordinary full-history node run by xrpl.to logged the same storm: 223,303 fake validator-manifest revocations landed in 10.28 seconds, and 141,404 disconnect events followed across 680 distinct peers in 3.4 hours of capture. Consensus on that node kept proposing.

FLOOD, IN FOUR FIGURES

• Junk keys: 223,303 never-seen validator identities, all secp256k1, none matching live validators sampled on that node.
• Handshake deaths: 141,404 no_message drops in the published window, with the storm still running when the log was posted.
• Hub damage: Several hundred peers down to single digits; one UNL validator left on a single remaining peer.
• Ledger: No halt, no fork, no lost funds; the hit was availability on the gossip layer.

The old design relayed every accepted manifest onward, so a poisoned cache rebroadcast the junk on every reconnect and fed itself. Version 3.2.1 put caps on entry size, per-message count, and untrusted cache size. Version 3.3.0 then loosened those caps after the first bounds starved legitimate untrusted gossip while the flood was still running. Weeks later, a celebrity hub sitting at 500 peers can still be the delayed aftertaste of that cleanup, which is exactly the good theory Schwartz offered and then refused to adopt as fact.

What Version 3.4.0 Changes for Peers

The 3.4.0 notes lead with lending, not overlay health. LendingProtocolV1_1 adds closed-ended vaults and cash-basis accounting, and fixCleanup3_4_0 bundles amendment-gated fixes; both still need validator votes before those rules are live. Peer work is listed lower, as bug fixes and refactors operators get when they install the binary.

XRP Ledger version 3.4.0 is now available ✅

New amendments for voting:

– Lending Protocol v1.1 – closed-ended vaults and cash-basis accounting.
– fix Cleanup – bundled fixes.

Performance and Stability:

– Online delete now pauses on ledger history gaps, so nodes stay closer… pic.twitter.com/hiW8XuL2AZ

— XRP Ledger Operations (@XRPLOperations) September 17, 2026

PEER CHANGES IN THE 3.4.0 BINARY

• Protobuf trim: Unknown fields are stripped when incoming peer protobuf messages are parsed, so odd extra bytes are less likely to poison a session.
• Get-ledger bound: An unbounded database seek through TMGetLedger is fixed, which stops one peer request from dragging the disk.
• Transaction list cap: The TMTransactions list is size-capped, and undeserializable transactions now draw a resource fee instead of a free retry loop.
• Protocol cut: Peer protocol 2.1 is removed, and TMLedgerNode moves to protocol 2.3 by carrying node depth instead of a node id.

Those are real hardening steps. They are also not a documented explanation for a two-week drop in disconnects that was already on Schwartz’s graphs before the packages moved to packages.xrplf.org. Operators still have a reason to install the build. They do not have a reason to treat 501 peers on one hub as proof that the new code already healed the overlay.

On June 16 he had taken the same hub down for about ten minutes to move it to 3.2.0, when the server binary’s name changed from rippled to xrpld. That short outage was planned. July’s collapse was not. The September reading sits on top of both, which is why a clean “the upgrade worked” headline does not survive the calendar.

Schwartz’s Hub Is Still One Relay

In May the XRP Ledger Foundation named Schwartz an honorary board member of the Foundation, citing him as one of the original architects. That seat adds weight to his public charts. It does not turn those charts into a network-wide dashboard. No second hub posted a matching 500-peer recovery in the same thread, and Schwartz did not claim one.

WHAT WE KNOW

• The reading: On September 17 his hub was back over 500 peers, with 501 shown and 509 as the two-week high on the attached charts.
• The window: He dated the calmer stretch across about two weeks, and he flagged September 15-16 as a monitor glitch rather than a real drop.
• The history: July 30 emptied hubs to single-digit peers; 3.2.1 and 3.3.0 were the overlay patches; 3.4.0 shipped on September 16.

WHAT IS UNCONFIRMED

• The cause: Schwartz has not tied the 500-peer hold to 3.4.0, to inbound junk, or to a finished drain of flood-era nodes.
• Other hubs: There is no public set of matching operator charts for the same fortnight.
• Lending: 3.4.0 puts LendingProtocolV1_1 up for votes; it does not, by itself, turn those vault rules on.

A hub that holds 500 healthy connections is easier to run than one that sheds them. It is still one server, and the man who built much of the software will not say why this one got quieter. Until someone else publishes the same curve, or Schwartz closes the guesswork, 501 peers is a local reading, not a verdict on 3.4.0.

Disclaimer: This article is news reporting on public software notes and operator posts about XRP Ledger servers. It is informational only and is not investment, trading, or legal advice, and it is not a recommendation to buy, sell, or hold XRP or any related product. Readers who are weighing tokens, funds, or node operations should consult a qualified financial adviser or a competent systems operator before acting. Peer counts, amendment votes, and software versions are taken from the dated posts and release notes cited above and can change as operators upgrade and as validators vote.