Ripple Wants to Kill Its Own Cross-Chain Bridge: Inside the Withdrawal of XRPL Amendment XLS-38

Ripple Wants to Kill Its Own Cross-Chain Bridge: Inside the Withdrawal of XRPL Amendment XLS-38

Ripple has formally recommended withdrawing the XRP Ledger’s long-pending XChainBridge amendment, concluding that the native cross-chain bridge it designed is no longer needed because Axelar already performs the job — and that keeping the code around is a maintenance burden the ecosystem should not carry.

The recommendation, announced on August 27 by Mayukha Vadari, a senior software engineer at RippleX, targets XChainBridge, also known as proposal XLS-38. The amendment has sat in the XRPL validator voting process without activating on mainnet. If withdrawn, Ripple estimates developers could delete more than 10,000 lines of code from xrpld, the server software that powers the XRP Ledger.

What XChainBridge was built to do

XLS-38 was designed to provide a protocol-level framework for moving XRP and issued assets between the XRP Ledger and connected networks. Its intended users included public sidechains, private ledgers, permissioned networks, and experimental chains. The system relies on independent witness servers that monitor events on each connected ledger, submitting attestations that assets were locked or destroyed on one side before corresponding assets become available on the destination network.

One of the proposal’s flagship use cases was connecting XRPL mainnet with its Ethereum Virtual Machine-compatible sidechain. That plan changed when Ripple selected Axelar to provide the connection instead. The XRPL EVM Sidechain launched with Axelar as its mainnet bridge in June 2025, and Axelar’s validator network now verifies cross-chain messages connecting the sidechain with XRPL and other supported blockchains. Ripple says the EVM sidechain connection is now “better addressed” through Axelar — a technical assessment by the company rather than the result of an independent security comparison.

Why withdraw instead of leaving it dormant

Ripple initially kept XLS-38 alive because developers could theoretically use it for private sidechains and specialized networks that Axelar was not designed to support. But the company said it found little evidence of active projects requiring the native bridge, and no production deployment has publicly identified XLS-38 as essential to its operations.

Maintaining an inactive protocol implementation is not free. Every time developers update xrpld, the dormant XChainBridge code still requires reviews, tests, and compatibility work. Ripple’s argument is straightforward: the code creates an ongoing maintenance burden without delivering any corresponding mainnet benefit. Deleting it simplifies the codebase, reduces audit surface, and lets engineering effort flow to features people actually use.

The recommendation does not signal that the XRPL ecosystem is abandoning interoperability. Ripple pointed to Axelar, Wormhole, zero-knowledge systems, and layer-2 designs as alternative approaches suited to different security and privacy requirements. Cross-chain systems also carry distinct risks — bridge exploits have caused more than 4 billion USD in reported losses since 2021, making verification design and operational security central considerations for any connection between networks.

Ripple cannot do this alone

Despite initiating the withdrawal, Ripple cannot remove XChainBridge by itself. The official XRPL registry lists the amendment as pending with a default “no” vote, and Ripple operates only one validator among the network’s independent participants. An XRPL amendment normally requires support from more than 80 percent of trusted validators for two continuous weeks before activation. With 35 validators in the current default configuration, at least 29 affirmative votes would be needed to cross that threshold — a deliberately high bar designed to prevent any single party, including Ripple, from forcing protocol changes on the network.

The withdrawal procedure itself involves community coordination. Developers with active XLS-38 projects have been invited to present evidence before the community completes the formal withdrawal process, a window intended to ensure no team is left stranded by the amendment’s removal.

A housekeeping milestone with larger implications

On the surface, the XLS-38 withdrawal is technical housekeeping — removing unused code from a server codebase. But it carries weight beyond the XRP Ledger. First, it is a rare example of a major blockchain organization voluntarily pruning its own roadmap rather than letting half-built infrastructure linger indefinitely. Most networks accumulate dormant proposals for years; few are ever formally retired.

Second, it is an acknowledgment that general-purpose interoperability layers — Axelar, Wormhole, and their competitors — have effectively won the bridge wars for now. When a network’s founders decide an in-house bridge is redundant because a third-party protocol does the job, it signals consolidation in the cross-chain sector that few would have predicted during the bespoke-bridge boom of earlier cycles.

Third, it reflects the security calculus that has reshaped the industry since the multibillion-dollar bridge hacks of recent years. Native bridges concentrate enormous value in bespoke witness architectures; relying on battle-tested external networks spreads that risk across systems with broader operational scrutiny.

For XRPL validators and developers, the next steps are procedural: weigh any last-minute evidence from XLS-38 dependents, complete the withdrawal, and begin the code cleanup that follows. For the wider crypto industry, the episode is a quiet case study in knowing when to fold a feature — and a reminder that in post-hack DeFi, less bridge code can mean less risk.

No code has been removed from xrpld yet, and no timeline for the full withdrawal has been published. Ripple said the community will complete the withdrawal procedures after affected developers have had the opportunity to respond.