Ripple CTO David Schwartz has confirmed that serious internal discussions are underway regarding a potential modular refactor of the XRP Ledger (XRPL), with Rust emerging as a favored programming language for future implementations. The shift, if undertaken, could mark the most substantial architectural evolution in XRPL’s history—though Schwartz emphasized that nothing would change for users or the state of on-chain data.
XRP Ledger Rewrite In Rust Under Review
The remarks came during an internal technical discussion, later shared by Crypto Eri via X on August 2, where Schwartz outlined multiple proposals currently being evaluated by Ripple. “You mentioned that if you had to restart from scratch, you would do it in Rust,” an interlocutor prompted. Schwartz responded, “There’s definitely talk about doing that. And there’s also been talk about modularizing the transaction engine so that the transaction engine could execute in a VM.”
At the heart of the discussion is the XRPL’s monolithic codebase, written in C++, which combines the consensus engine, transaction processing, client query interface, and overlay protocols into a tightly coupled architecture. Schwartz acknowledged the technical debt inherent in this design, noting that “we would like to have the code be more modular.” He cited the difficulty of implementing alternate transaction engines due to inconsistent specifications, particularly in the payment engine, which uses imprecise floating-point arithmetic that can produce divergent results depending on calculation order.
“You could actually specify, yeah, actually you have to do like Z minus Q plus T minus R,” he said. “That would be annoying. We would probably want to re-specify and have an amendment where at one time we switch over to a more organized, clear, coherent version of that code.”
The proposed changes would not impact XRP holders or the functionality of the ledger itself. As RippleX senior software developer Mayukha Vadari explained in response to public speculation: “If rippled was rewritten in Rust, or there was a second client in Rust, it wouldn’t do anything to the on-chain data. Nothing would happen to your XRP. Everything about using and building on the XRPL would stay the same, just a change in what language the core protocol is written in.
Rather than a full rewrite, Schwartz suggested a phased and modular strategy. The approach would begin with a formal specification of existing components like the payment engine and transaction logic, followed by compartmentalization of those components into virtual machines. “Even if we can’t do that [specify perfectly], we could isolate the pieces of code that have those annoying quirks… and maybe modularize them into a VM,” he said.
Some of the proposals under review were reportedly submitted by third-party companies, indicating external involvement in shaping the future structure of XRPL. “We’re making decisions now about what we think is worth doing and what the order of doing things would be,” Schwartz revealed.
The move also sparked community conversations around development standards and naming conventions within XRPL’s codebase. Developers like @xrp_hodl_r noted the inconsistency of naming conventions in API outputs and suggested standardization could reduce long-term maintenance costs. Vadari responded by emphasizing the importance of preserving backward compatibility and clarity for developers, explaining that canonical on-chain fields use different formats from synthetic ones for important technical reasons. “API versioning is already the mechanism we have for that, we really don’t need anything else,” she said.
While no decisions have been finalized, Schwartz made one thing clear: the conversation is no longer hypothetical. “It’s just not easy at all,” he said, “but it would be a win all around.”
At press time, XRP traded at $3.00.