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.
ripples own bridge and they are the ones pulling it. deleting 10k lines of xrpld because axelar already ships the feature is honestly the right call
Rare to see a team kill its own code without ego. Vadari was pretty blunt that keeping XChainBridge around is pure maintenance burden with zero upside now.
axelar running the EVM bridge instead is fine until you remember its just another multisig with extra steps. trade one trust model for another
multisig with extra steps is exactly right. at least now the trust assumption has a name instead of 10k lines of dormant code
most teams would let their own bridge rot quietly in the codebase instead of publicly burying the design. credit to vadari for naming it
deleting 10,000 lines of dormant bridge code from xrpld is the most sensible thing ive read all week. less code, less audit surface
10k lines of dormant bridge code is 10k lines someone has to keep auditing forever. wish more chains did pruning like this without ceremony
deleting dead code without ceremony is a nice idea except it needs 29 validators for two straight weeks. the vote is the ceremony
worth noting ripple cant force this through themselves. 29 of 35 validators for two straight weeks is the bar, they run exactly one
29 of 35 validators for two straight weeks with ripple running exactly one is the only decentralization test xrpl actually gets. watching the vote tally will be more interesting than the amendment
if this stalls at 28 of 35 its on the loungers, not ripple. they run one validator and asked nicely, thats the whole deal
Ripple designed XChainBridge, Axelar shipped the EVM sidechain connection first, now XLS-38 gets retired. Tells you who actually won the bridge wars.
4 billion in bridge losses since 2021 and youre folding your own bridge because axelar already does the job. thats just honesty about where the risk was
Axelar shipped first because it never needed 35 validators to turn anything on. Speed of a federated bridge beat the purity of a protocol vote.
so XRPL validators sat on XLS-38 for years and now it dies in limbo. rip to everyone who waited on that one
the fun part is if validators just ignore the withdraw request those 10k lines stay in xrpld forever. 35 validators and a shrug is the whole governance model
validators ignoring the withdraw request would be the most XRPL thing ever. 10k lines of dead bridge code staying in xrpld because nobody showed up to vote
29 validators for two straight weeks is a low bar and we might still trip over it. the loungers tally is the only drama left on xrpl
the loungers tally is free transparency honestly. one dashboard and every xrpl operator can see who actually shows up for the 29 validator check
so the code cleanup only happens if 29 validators care enough to show up. love a deletion that needs a quorum
the witness server part was always the weak link imo. independent attestators sounds nice until you realize most of them wouldve been run by the same 5 companies anyway
4 billion in bridge losses since 2021 and here is xrpl voluntarily deleting its own bridge. more chains should copy this energy
^ this. everyone celebrating the withdrawal like axelar is somehow trustless
axelar has its own baggage but keeping a dormant witness server system alive for zero users makes no sense. prune it
witness servers were the honest weak point the whole time. deleting them plus 10k lines of xrpld is the rare cleanup that cuts audit load and attack surface at once