Ripple CTO emeritus David Schwartz hints he remains involved with $XRP in a recent X conversation, despite stepping away from day-to-day duties at Ripple.
Schwartz revealed in late September 2025 that he will step down from his day-to-day activities as Ripple CTO at the end of the year. Ahead of the announcement, he spun up his own $XRP Ledger node to publish its output data while researching other use cases for $XRP.
Now, the Ripple CTO emeritus’s recent comments hint that his retirement does not imply abandoning $XRP. Schwartz responded to an X user who pointed to his recent observation about the $XRP Ledger network, derived from his hub, to suggest that he didn’t retire from $XRP.
“If you had any doubt about whether David was retiring from just Ripple or also from $XRP,” the X user wrote. Schwartz replied, saying, “It was fun spending a few hours working like I used to and having a Zoom call with the team again.”
It was fun spending a few hours working like I used to and having a Zoom call with the team again.
— David ‘JoelKatz’ Schwartz (@JoelKatz) July 31, 2026
Being an original architect of the $XRP Ledger, Schwartz’s comments have reassured many $XRP supporters who questioned whether his retirement marked a complete departure from the $XRP ecosystem.
Ripple CTO emeritus observation leads to XRPL fix
On Friday, Ripple CTO emeritus David Schwartz indicated that his hub was experiencing difficulties. The issue caused the hub to lose peers with “onReadMessage: No message of desired type” during negotiation, followed by a connection loss.
The same issue was confirmed by XRPL Analytics App, xrpl.to, which stated that the problem was network-wide.
Schwartz’s contribution to solving the issue may be inferred from his mention of having a Zoom call with the team and working for a couple of hours, which one might assume occurred in this context.
$XRP Ledger version 3.2.1 was released shortly after, fixing the manifest flood observed on Friday, July 31. Nodes had previously accepted, stored, and rebroadcast an unlimited number of manifests from unknown validator keys; version 3.2.1 adds four limits to fix the issue.
