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 20241, 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.
