DEV Community: David Fuelling

Ripple’s Recommendation: Withdraw the XChainBridge Amendment (XLS-38)

David Fuelling — Thu, 27 Aug 2026 15:00:00 +0000

When we set out to bring cross-chain bridging natively to the XRP Ledger, the XChainBridge amendment (XLS-38) was our proposed solution. Today, we're recommending that the XRPL community withdraw XChainBridge along with the related fixXChainRewardRounding amendment.

What XLS-38 Set Out to Do

XLS-38 defined a protocol for native cross-chain bridges on the XRPL to enable custom sidechains. Rather than delegating to third-party bridge operators, it proposed a model where a decentralized network of "witness servers" would observe and attest to transactions across chains, enabling assets to move between XRPL mainnet and any connected sidechain.

The original vision was compelling: give developers the building blocks to create custom sidechains: private chains, permissioned networks, or experimental environments for features not yet available on mainnet. XLS-38 was also intended to bridge the XRPL EVM Sidechain to mainnet, with XRP as the native gas token.

Why We Chose Axelar for the EVM Sidechain

As we prepared to launch the XRPL EVM Sidechain (a collaboration between Peersyst, Ripple, and the broader XRPL community), we conducted a thorough evaluation of bridging options, weighing security, user experience, decentralization, and long-term operational sustainability.

The XLS-38 witness server model presents inherent trade-offs between security and decentralization that become harder to manage as the value locked in a bridge grows. The architecture places significant trust in a set of witness server operators: the larger and more decentralized that set, the better the security; but also the greater the coordination overhead, the harder the governance, and the more diffuse the accountability. For a bridge securing a public chain's native gas token, these tensions don't have easy resolutions, and Ripple concluded that it wasn't an area where we had the operational expertise to do it well at scale. Building and managing bridges between public blockchains is genuinely specialized work.

Axelar, on the other hand, is purpose-built for exactly this problem. Its 75+ validators, threshold signature scheme, and key-rotation discipline reflect the kind of operational maturity that takes years to develop, backed by experience bridging across 55+ blockchains. That expertise isn't easy to replicate, and Ripple's team didn't see a need to when a capable partner already existed.

In June 2024¹, we announced the decision to use the Axelar network alongside the XRPL EVM Sidechain launch. At that time, we committed to leaving the XLS-38 amendment available for a vote while Ripple's UNL validator would continue voting No, and pledged to give the community 12–15 months to demonstrate interest in XLS-38 as a foundation for private sidechain use cases.

What We Observed

That window has now passed. During this time, we actively engaged with developers, monitored community forums, and looked for concrete projects or proposals that would benefit from an activated XLS-38 bridge on mainnet. We didn't find the level of adoption or developer interest that would justify keeping the amendment moving toward activation.

A few observations drove our current thinking:

The EVM Sidechain bridge is well-served by Axelar. The primary use case that motivated XLS-38's development is fully addressed, and we believe better addressed, by the Axelar integration.

Lack of Demand. No significant private sidechain demand materialized for private sidechains that would use XLS-38 specifically. We wanted to see real developer projects that specifically required a native XLS-38 bridge, but that hasn't emerged at the level we hoped.

Maintaining inactive code carries real costs. Keeping the XChainBridge code in xrpld creates an ongoing maintenance burden and a source of confusion for new contributors, with no corresponding benefit to the network today. We estimate that withdrawing this amendment would let us remove more than 10,000 lines of code from xrpld, reducing the surface area we maintain and review.

That said, we want to be clear: this is a recommendation, not a unilateral decision. If there are developers or organizations actively building on XLS-38, or who have concrete plans to do so, we want to hear from you. Ripple controls one vote among many on the XRPL, and we're open to revisiting this assessment if the community presents a strong case.

Different Problems, Different Tools

The Axelar decision was specific to the EVM Sidechain, which is a public chain bridging XRP to a permissionless EVM environment. XLS-38, by contrast, was meant to support a wider range of use cases: private chains, permissioned networks, experimental environments for features not yet on mainnet. The reality for that wider set is that no single mechanism fits every use case.

Axelar and Wormhole represent one class of solution (trust-minimized bridging between mature public chains), but the broader space includes ZK-based approaches, L2-style architectures, and early research directions like consensus-within-consensus. Active work is happening across all of these, and the right tool depends on the problem.

None of these is a drop-in replacement for XLS-38, and none is the right answer for every problem. They're a portfolio. Part of our reason for proposing to withdraw XLS-38 is that, as a single mechanism trying to serve all of these use cases, it was solving too many problems at once.

How the Withdrawal Process Would Work

If the community aligns with this direction, the next steps are deliberate and consensus-driven, which is exactly how it should be. Here's how it would unfold:

Step 1: Mark the amendment as Obsolete. Ripple's intended first step is to open a pull request to the xrpld repository that sets VoteBehavior::Obsolete for the XChainBridge feature. Once this change is merged, xrpld servers running that version will automatically vote against the amendment and will never vote in favor of it, regardless of operator configuration.

Step 2: Network consensus. As validators update their xrpld software to versions that include this change, the amendment will gradually lose support across the network. Once all active validators consider the amendment Obsolete, it can be removed from the codebase entirely.

Step 3: Code removal. A subsequent update will fully remove the XChainBridge and fixXChainRewardRounding code from xrpld.

What This Means for You

If you're building on the XRPL EVM Sidechain: Nothing changes. The Axelar bridge is your path to and from XRPL mainnet, and it will continue to be supported and improved.

If you're a validator: When and if you upgrade to the xrpld version that includes the Obsolete vote behavior, your node will automatically stop voting for XChainBridge. No action required on your part beyond the normal upgrade cycle.

If you were exploring XLS-38 for a private sidechain: This is the most important group we want to hear from. Please reach out on the XRPL developer Discord or engage on GitHub to share your use case. Concrete plans and active projects are exactly the kind of signal that could change our recommendation.

If you're a contributor to xrpld: The PR to mark XChainBridge as Obsolete will go through normal open-source review. We welcome technical feedback and discussion.

Looking Ahead

This recommendation reflects something broader about how we'd like to think about the XRPL: lean, purposeful, and battle-tested. Carrying unused code paths through years of mainnet evolution has real costs, such as maintenance burden, attack surface, and onboarding complexity for new contributors. XLS-38 is unlikely to be the last withdrawal we propose for those reasons.

We're grateful to the developers who built witness server tooling, the community members who debated the design over the years, and the validators who weighed in. That work wasn't wasted, but instead sharpened our understanding of bridging trade-offs and shaped how we now think about cross-chain interoperability more generally.

We'll leave a comment period open before moving forward. If you have feedback, a use case to share, or a reason we should reconsider, please weigh in on GitHub or in the XRPL developer Discord.

[1] For more context, see our June 2024 post on XRPL EVM Sidechain: Enhancing Interoperability with Axelar Bridge.

CBDCs Shed Light on Challenges and Innovation for Developers

David Fuelling — Wed, 29 Sep 2021 05:07:27 +0000

Ripple recently announced its partnership with the Royal Monetary Authority of Bhutan to pilot that nation’s first central bank digital currency (CBDC) using the technology underlying the XRP Ledger. The technical requirements for this project, as for all CBDCs, are demanding — we’re pushing the limits of conventional blockchain technologies, and inventing new technologies along the way. Though we can’t talk about many details of Ripple’s CBDC solution, some general reflections around CBDC development can help illuminate the full potential of this area.

Some key considerations for CBDC Ledgers include:

Financial inclusion
Speed, throughput, transaction cost, sustainability
Interoperability & liquidity (e.g., via sidechains)
Smart contracts and programmability
Robust security (key management, threat models, and more)

CBDCs help close existing gaps in commercial financial systems in a variety of ways, but perhaps the most important benefit is their ability to provide convenient, affordable access to basic financial services — such as payments — to every citizen, regardless of their ability to access the banking system. Bhutan has excellent existing financial infrastructure, and the vast majority of its citizens have access to it, but having a digital currency that can support universal access for every citizen is still an important goal.

Performance is also critical for CBDCs. Because Ripple’s CBDC solution leverages the same software as the public, decentralized XRP Ledger, we’ll be able to deliver incredible features like low transaction commit times, high throughput, and ultra-low fees — all the while doing it in a sustainable manner using one of the most energy efficient consensus mechanisms in the world.

Capable of sustaining thousands of transactions per-second, our CBDC Ledger is orders of magnitude more performant than many industry leading blockchains, and also much more performant than most legacy payments systems. While this type of performance will undoubtedly suffice for most central banking scenarios, we will continue to expand the capabilities of our solution to accommodate even the largest of nationalities. For example, any system powering a retail CBDC in the United States would likely need to sustain upwards of 100,000 transactions per second during peak times — all while maintaining high security, resilience and correctness of operation.

In addition to performance, interoperability of CBDCs with other token types, including other CBDCs, will be a key attribute of any successful future financial system. This is because increased mobility of assets will lead to increased and more efficient token liquidity, streamlining both domestic and cross-border payments by shrinking FX and other operational costs. To facilitate this vision, developers could build CBDC sidechains to allow value to move between chains that provide differing operational characteristics. For example, a developer may want to use sidechain X because it’s very fast and cheap. Later, that same developer may wish to use sidechain Y, possibly because that chain is more innovative and provides more features (but maybe is a bit more expensive from a fee perspective). No matter what the use-case, we envision a future where central banks have a menu of interoperability choices when providing programmable money to their citizens while at the same time maintaining full control of the system to meet their own policy objectives.

Another appealing component of systems running on Ripple’s CBDC solution is our proposed vision for smart-contract technology. Ledger programmability could make the execution of fiscal and monetary policy both extensible and even automated because developers will have the opportunity to build custom functionality into their ledgers. For example, streamlined tax systems, instant stimulus check deposits, improved and streamlined insurance claim processes — the possibilities are endless.

Of course, despite all of the amazing capabilities these technologies can enable, one crucial element to underscore is the elevated security risk that accompanies any CBDC Ledger. The system must be able to handle potential nation-state attack vectors that could compromise the health of an entire economy, and even a nation’s political equilibrium. To mitigate these threats, we have a variety of tools in our toolkit, such as: robust cryptography, multi-signed transaction submission, state of the art key-management and recovery systems, robust auditing, and a variety of other security and transaction approval mechanisms to help ensure that any CBDC Ledger system is safe for operators, developers, and end-users alike.

To allow for further exploration, Ripple has created a CBDC Ledger sandbox, which provides an ideal test environment to explore new ideas and solutions to these and other challenges involved in CBDC deployment. The extreme requirements that come with CBDCs are proving again how solid the underlying XRPL technology is, and providing developers with new opportunities to tune and innovate for the unique needs of each country.

Let us know in the comments what you think of these insights. And, when it comes to scalability, let the community know your thoughts — which is a better path for the XRPL for maximum scalability: sidechains, or a potential Layer-2 solution?