Have you ever watched a carefully planned feature sit unused for months until someone finally asks the obvious question: do we still need this? That moment arrived this week for the XRP Ledger community. A senior software engineer at RippleX publicly recommended pulling the long-pending XChainBridge amendment, better known as XLS-38, because its main job has already been handled elsewhere and broader interest never really took off.
I found the announcement striking not because it was dramatic, but because it felt practical. In a space that often chases every shiny interoperability idea, choosing to step back and clean house shows a certain maturity. The proposal would have added native asset bridges relying on independent witness servers. Instead, the team pointed to Axelar already covering the key EVM sidechain connection and admitted that specialized private or experimental chains simply have not lined up to use the native option.
Why Ripple Now Wants XChainBridge Gone
The core reasoning is straightforward once you sit with it. XChainBridge was built as a protocol-level way to move XRP and issued assets between the main ledger and other connected networks. Independent witness servers would watch events on each side, then submit attestations confirming that assets had been locked or destroyed before the matching assets appeared on the destination side. On paper it looked flexible enough for public sidechains, private ledgers, permissioned setups, and experimental chains.
One of the biggest intended use cases was linking the XRPL mainnet to its Ethereum Virtual Machine compatible sidechain. That connection later went to Axelar. The sidechain launched with Axelar serving as the mainnet bridge, and Axelar’s own validator network now verifies the cross-chain messages. From Ripple’s current technical view, that arrangement works better for the EVM sidechain needs than the original native design.
At the same time, the company looked around for other projects that still required the native bridge. Evidence of active development remained thin. No production system has publicly stated that XLS-38 is essential to its roadmap. Keeping the inactive code in the server software still means ongoing reviews, testing, and compatibility checks every time xrpld gets updated. That maintenance cost adds up without delivering clear mainnet value.
With Axelar successfully handling the EVM Sidechain and a lack of broader developer demand, dropping XLS-38 will remove over 10,000 lines of inactive code.
That estimate of more than ten thousand lines is not trivial. Cleaning them out would slim down the codebase and reduce the surface area that future contributors have to understand. In my view, this kind of deliberate pruning often matters more for long-term health than adding yet another optional feature that few people touch.
How the Amendment Actually Works Today
XChainBridge still sits in the validator voting process and has never activated on the mainnet. The official registry shows it as pending with a default no vote. Ripple itself controls only one validator among the independent set. An amendment normally needs support from more than eighty percent of trusted validators for two continuous weeks before it can activate. With the current default configuration around thirty-five validators, that threshold sits at roughly twenty-nine yes votes.
Because Ripple holds just a single vote, its recommendation cannot force the outcome. Other operators decide independently what their infrastructure will support. That separation has shown up before with other proposals. Support from one organization never automatically equals activation.
If the community moves forward with withdrawal, the process would begin with a pull request marking the amendment obsolete inside the xrpld codebase. Servers that upgrade to that release would automatically vote against activation. As more validators adopt the updated software, support would fall. Later releases could then strip out the XChainBridge implementation along with related code such as the fix for reward rounding. No hard deadline or specific version number has been set. Timing will depend on feedback, code review, and the pace of upgrades.
What Axelar Changed for the EVM Sidechain
The decision to use Axelar for the EVM sidechain connection altered the original plan. Axelar’s network verifies messages across chains and already links the sidechain to the XRPL mainnet plus other supported blockchains. Ripple now describes that path as better suited to the sidechain’s requirements. This remains an internal technical judgment rather than the result of a formal independent security bake-off, yet the practical outcome is clear: the native bridge is no longer needed for that particular job.
Interoperability itself has not been abandoned. Alternative approaches continue to receive attention, including systems based on zero-knowledge proofs, different layer-two designs, and other bridge models that trade off security assumptions and privacy features in distinct ways. The point is not to stop connecting networks. It is to stop carrying unused native code when external solutions already cover the main scenarios and specialized demand has stayed quiet.
The Real Cost of Keeping Dead Code
Every inactive feature still consumes attention. Developers must keep tests passing, review changes for compatibility, and understand the old logic when debugging unrelated issues. Over time those small costs compound. Removing more than ten thousand lines would free mental bandwidth and reduce the chance that future bugs hide inside rarely exercised paths.
I have watched similar cleanups in other open projects. The short-term discomfort of deciding to drop something usually pays off in clearer architecture and faster iteration later. The XRPL community has the same opportunity here. If no one steps forward with a concrete, active use case that truly requires the native witness-server design, the maintenance burden becomes hard to justify.
Cross-Chain Risks Remain Worth Remembering
Bridges have a difficult history. Reported losses from bridge exploits have exceeded four billion dollars since 2021. Verification design, operational security of witnesses or validators, and careful handling of locked assets all matter enormously. The fact that XChainBridge never reached mainnet means it never faced those real-world pressures, yet the broader lesson still applies. Any future native bridging effort would need to address the same hard problems that external solutions already confront every day.
Choosing a mature external network for the EVM sidechain therefore carries its own logic. Axelar already operates under those pressures and has an established validator set. That does not make it perfect, but it does mean the security and operational questions are being answered in production rather than in an unused code path.
Who Actually Decides the Outcome
Ripple’s public recommendation is influential, yet it is not decisive. Validators run independent infrastructure and choose their own amendment support. The process is designed that way on purpose. Even if Ripple’s single vote switches to no, the remaining operators must still reach the high threshold or allow the amendment to stay pending indefinitely.
Developers or organizations that have been building against XLS-38 have been invited to come forward with specific evidence of active work. A credible production-oriented project could still change the recommendation before the staged withdrawal advances. That invitation keeps the door open for genuine need while making clear that silence will be interpreted as lack of demand.
Possible Timeline and Practical Next Steps
The withdrawal path would unfold in stages rather than a sudden cut. First comes the pull request that marks the amendment obsolete. Upgrading servers then shifts their automatic votes. Once the active validator set treats the proposal as obsolete, later releases can delete the implementation and associated fixes. Because no fixed schedule has been announced, the community can still influence the pace through discussion and demonstrated use cases.
For operators the practical advice is simple. Watch the pull request once it appears, review the change, and decide when to upgrade. For builders the message is equally clear: if the native bridge is truly important to a live roadmap, now is the time to say so with concrete details. Otherwise the code will gradually leave the tree.
What This Signals About Protocol Priorities
Perhaps the most interesting aspect is the willingness to reverse course on a feature that once looked promising. Many projects struggle to admit when an idea has been overtaken by events. Here the team looked at the actual deployment of the EVM sidechain, measured real developer interest, and concluded that the native path no longer justified its cost. That kind of feedback loop is healthy.
It also reinforces a broader pattern. Interoperability remains important, yet the form it takes can evolve. External specialized networks, zero-knowledge techniques, and carefully designed layer-two systems each bring different strengths. Keeping every possible native option forever simply because it was once proposed is not a requirement. Pruning unused paths can make the core ledger stronger and easier to reason about.
In my experience watching protocol development, the teams that stay willing to drop ideas that no longer fit tend to move faster over multi-year horizons. The short-term conversation can feel uncomfortable, especially for anyone who invested time exploring the original design. The longer-term clarity usually rewards the decision.
Community Voice Still Matters
Because the amendment process is deliberately distributed, individual validators and the wider developer community retain real influence. Comments on the upcoming pull request, discussions in public channels, and any concrete project evidence will all shape the final path. Silence will likely be read as consent to withdrawal. Active engagement, especially from those who still see value in the native witness model, can still alter the recommendation.
That balance feels right to me. A single organization can surface a reasoned case for cleanup, yet the network as a whole decides whether the case holds. The high activation threshold already protects against hasty additions. The same distributed process can now protect against unnecessary retention of dead weight.
Looking Ahead for XRPL Interoperability
Removing XChainBridge does not close the door on future bridging work. It simply clears space. New proposals that address genuine, demonstrated needs can still appear. Those proposals will face the same high bar for activation and the same expectation that real usage will eventually justify ongoing maintenance.
In the meantime the EVM sidechain continues to operate with its chosen external connection. Other interoperability experiments can proceed through the channels that already exist. The ledger itself becomes a little lighter and a little easier to maintain. For a network that values reliability and long-term clarity, those are useful gains.
I keep coming back to the quiet practicality of the move. No grand claims, no sudden crisis, just a measured look at what the code is actually doing and whether the cost still makes sense. In a market that often rewards noise, that kind of restraint is worth noticing.
The coming weeks will show how the broader validator set responds. Some may upgrade quickly and shift their votes. Others may wait for more discussion. A few may even argue that the native option should stay available for edge cases that have not yet surfaced. All of those reactions are part of the process. The important part is that the conversation is happening in the open with a clear technical rationale on the table.
Whatever the final outcome, the episode offers a useful reminder. Protocol features are not permanent once proposed. They remain provisional until real usage and ongoing cost justify their presence. When those conditions change, the healthy response is to reassess rather than defend the original plan out of inertia. The XRP Ledger appears ready to do exactly that with XChainBridge.
For anyone building on the ledger or simply following its evolution, the practical takeaway is to stay alert to the pull request once it lands, to weigh the maintenance argument against any personal use cases, and to remember that the decision ultimately sits with the distributed set of validators. That structure has served the network well so far. It should serve it well again here.
The story is still unfolding. The recommendation is public, the reasoning is on record, and the next concrete step will be visible in the codebase. How the community answers will tell us a good deal about how the ledger balances ambition with operational realism in the years ahead.
One final observation feels worth adding. Cleaning up unused paths rarely makes headlines the way a new feature launch does. Yet over time those quiet decisions compound into a more maintainable and understandable system. If the withdrawal proceeds as recommended, future contributors will inherit a slightly smaller, clearer codebase. That is not a dramatic victory, but it is a solid one. In protocol development, solid often beats dramatic in the long run.
The invitation for evidence of active projects remains open. Anyone with a genuine need for the native witness-server model still has time to present it. If such evidence appears and proves compelling, the recommendation can be revisited. If it does not, the staged removal can continue. Either path keeps the process grounded in observed reality rather than original intention alone. That grounding is, ultimately, what makes the current discussion valuable.
