Senior Ripple Engineer Confirms Nothing Would Happen to Your XRP if XRPL is Rewritten in Rust

A senior Ripple engineer has cleared the air as talks around rewriting the XRP Ledger (XRPL) in Rust recently triggered unease among XRP holders.

Notably, these concerns picked up after Ripple’s Chief Technology Officer, David Schwartz, discussed the idea during a developer bootcamp. For context, the original XRPL architects, including Schwartz, wrote the network using C++, and pivoting to Rust could have immense benefits.

After community figure Eri highlighted this prospect in a recent post, certain members of the community questioned if such a change could impact their XRP holdings or disrupt the XRPL network.

- Advertisement -

Rewriting XRPL in Rust Has No Impact on Your XRP Tokens

In response, Mayukha Vadari, a senior engineer at RippleX, provided necessary clarification. Specifically, she explained that rewriting XRPL’s core software, “rippled” in Rust, or even creating a second version of it in Rust, would not change anything for users. 

I'm seeing a lot of FUD around this so PSA: 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… https://t.co/injtps6PdY

— Mayukha Vadari (@msvadari) August 2, 2025

According to her, the rewrite would only involve the language used to build the protocol, not the data stored on the blockchain or how the network operates. She stressed that users would still hold their XRP, and developers would continue building on XRPL the same way they always have.

Vadari explained that the process would start with defining how the system currently works and breaking rippled into separate modules. From there, developers could gradually rewrite each part in Rust, though the transaction engine would likely stay in C++.

Why Use Rust?

Notably, she addressed the issue after Schwartz’s remarks at the XRPL Core Dev bootcamp. Someone from XRPL Commons, a nonprofit that supports XRPL growth, asked Schwartz why Ripple hasn’t moved forward with rewriting XRPL in Rust now.

For the uninitiated, Rust is known for its speed and reliability. It gives developers low-level control over memory while preventing common bugs that plague older languages like C and C++. 

This makes Rust a strong fit for blockchain software. Notably, blockchains like Solana, Sui, and Polkadot run on Rust. Rewriting the core XRPL software in Rust would help improve security, speed, and make the infrastructure easier to maintain.

Ripple CTO Confirms Ripple Already Considering the Idea

In response to the question, Schwartz said Ripple has already been considering the shift. He confirmed his role in those discussions. Schwartz explained that Ripple wants to break down the XRPL’s architecture into smaller, more manageable parts, especially the transaction engine, so it can eventually run inside a VM. 

Notably, this setup would make it possible to rework parts of the system in other languages, such as Rust, without rewriting everything at once.

A Major Challenge in the Payment Engine

However, Schwartz pointed out that one major challenge is in the payment engine. He said some of its operations rely on math that doesn’t always produce the same results when performed in different orders, which makes exact replication in another language difficult. 

For example, floating-point calculations might lead to small differences depending on the order of addition and subtraction.

He explained that it is important to make the XRPL more modular and flexible. “You can imagine a situation where the transaction engine is sort of compartmentalized and runs in a VM… we would like to have the code be more modular.” 

Schwartz also revealed that Ripple has started reviewing proposals from outside companies interested in helping with this work. He said the team is now deciding what to tackle first and how to move forward. He added that they also want to write formal specifications for each part of the system to make it easier to build alternate versions that all behave the same.

Despite the complexity, Schwartz believes there would be some benefit from moving forward with this idea. “So, yeah, I definitely think that’d be a good thing. It’s just not easy at all.”