Schwartz Clarifies Ripple Position on XRP Ledger Smart Contracts Via EVM Sidechain Amid Concerns

Ripple’s plans to introduce smart contract functionality to the XRP Ledger (XRPL) have triggered discussions within the community. 

Interestingly, Ripple CTO David Schwartz has addressed some of the emerging concerns, essentially providing clarity on the company’s stance and future intentions.

Ripple’s Vision for XRPL Smart Contracts

Recall that yesterday, The Crypto Basic confirmed that Ripple announced plans to enhance the XRPL by adding smart contract functionality through two primary avenues. 

The first involves an EVM Sidechain currently in development in collaboration with Peersyst. Meanwhile, the second option will involve an XLS proposal to enable smart contracts directly on the XRPL Mainnet. Ripple confirmed it will seek community support on this.

However, the announcement made no mention of trying out Hooks, a protocol designed by XRPL Labs specifically for native smart contracts on the Mainnet. The XRPL Labs team has consistently pushed for Hooks in the past, but the Ripple CTO expressed security concerns.

The omission of Hooks from the possible options in the latest announcement triggered questions, particularly from Wietse Wind, who felt that Hooks deserved consideration, especially given its successful implementation on Xahau, a new chain.

Ripple CTO Responds

Amid the ensuing backlash, David Schwartz took to X to clarify Ripple’s position. He emphasized that Ripple neither intends nor has the authority to alter the XRPL unilaterally. 

Instead, the company’s recent announcement was meant to communicate Ripple’s recognition of the value of bringing programmability to the XRPL Mainnet. 

Schwartz stressed that Ripple commits to transparency and community involvement, and the announcement was an early step in a process that would include community feedback and design reviews.

Seems like there’s confusion over the programmability blog post we put out yesterday, so let me clear a few points up:

Ripple simply cannot (and absolutely doesn’t want to) unilaterally change the XRP Ledger. The blog post is Ripple saying that we see the value in bringing…

— David “JoelKatz” Schwartz (@JoelKatz) September 4, 2024

He explained that, until recently, he did not see a feasible way to implement smart contracts on the Mainnet without fundamentally changing the XRPL. 

However, after discussions with various community members, including those at Orchestra Finance, he realized that it might be possible to introduce programmability to the Mainnet while addressing key challenges such as ledger bloat, transaction speed reduction, and potential security vulnerabilities. 

He acknowledged that others in the community had reached this conclusion earlier and emphasized that Ripple intends to take a cautious, step-by-step approach to mitigate any risks associated with such changes.

The Role of the XRP Community

One of the important points Schwartz highlighted was the importance of the XRP community in the decision-making process. He reassured community members that Ripple’s goal is to collaborate with them rather than impose changes. 

The Ripple CTO also addressed the timing of the announcement, noting that it coincided with upcoming XRP community gatherings in Korea and Japan. Schwartz saw these in-person events as valuable opportunities for open discussions about the future of XRPL programmability.

Emerging Concerns About Decentralization

In response to Schwartz’s clarifications, some community members raised questions about the decentralization of the XRPL. 

A prominent community figure, MetaManX, questioned whether smart contracts could be added to the XRPL without Ripple’s approval, suggesting that bypassing Ripple should be possible if the blockchain is truly decentralized.

At the reporting time, Schwartz has not yet responded to this question. However, the Ripple CTO has persistently emphasized in the past that Ripple is merely just another builder on the XRPL. As such, it does not unilaterally impose or block changes to the network.