Ripple has recommended pulling back the XRP Ledger’s pending XChainBridge amendment (XLS-38), saying its flagship use case is now covered by Axelar and that broader developer demand never materialized. What Ripple said - Mayukha Vadari, a senior software engineer at RippleX, announced the recommendation on Aug. 27. XLS-38 remains a pending amendment in the XRPL validator voting process and has not activated on mainnet. - Ripple estimates withdrawing the proposal would let developers remove more than 10,000 lines of inactive code from xrpld — the server software that runs the network — though no code has been removed yet and Ripple cannot unilaterally complete the process. What XLS-38 was meant to do XChainBridge was conceived as a protocol-level bridge framework to move XRP and issued assets between the XRP Ledger and external ledgers: public and private sidechains, permissioned networks and experimental chains. The design relied on independent witness servers that attest to asset locks or destructions on one ledger before corresponding assets are minted or released on the destination chain. Why Ripple wants to withdraw it - One of XLS-38’s main target use cases was connecting the XRPL mainnet to an EVM-compatible sidechain. Ripple ultimately selected Axelar to handle that role. The XRPL EVM Sidechain launched in June 2025 using Axelar as its mainnet bridge; Axelar’s validator network now handles cross-chain message verification between the sidechain, XRPL and other blockchains. - Ripple says Axelar “better addresses” the EVM sidechain connection — a technical assessment rather than an independent security comparison — and that it found little evidence of production projects requiring a native XLS-38 bridge. No public deployment has identified XLS-38 as essential. - Maintaining the inactive XChainBridge implementation requires ongoing reviews, testing and compatibility work whenever xrpld is updated, creating a maintenance burden with little corresponding benefit to mainnet. Alternatives and risk considerations Ripple framed the recommendation as a practical step, not a retreat from interoperability. It pointed to Axelar, Wormhole, zero-knowledge systems and layer-2 designs as alternate approaches that meet different security and privacy needs. It also noted the broader context: cross-chain bridges carry distinct risks — bridge exploits have been responsible for more than $4 billion in reported losses since 2021 — making verification design and operational security key considerations. Governance mechanics — what happens next - XLS-38 is listed in the official XRPL registry as a pending amendment with a default “no” vote. Ripple controls one validator vote among the network’s independent participants. - An XRPL amendment needs support from more than 80% of trusted validators for two continuous weeks to activate. With the current default configuration of 35 validators, that threshold requires at least 29 affirmative votes. - Ripple’s recommendation does not immediately withdraw the amendment or force other validators to oppose it; validators decide independently. Planned withdrawal process Ripple proposed starting by submitting a pull request that marks XChainBridge as obsolete in the xrpld codebase. Servers that upgrade to that release would automatically vote “no” on activation. As validators install the updated software, support for the amendment should decline; once the amendment is widely recognized as obsolete, developers could remove the XChainBridge code and a related fixXChainRewardRounding change in a later release. Timing and potential reversal No deadline, software version or final removal date has been announced. The schedule will depend on community feedback, code review and validator upgrades. Ripple has invited developers or organizations building with XLS-38 to present concrete use cases; a credible active deployment could prompt Ripple to reconsider the recommendation before any staged withdrawal begins. Bottom line Ripple’s move signals a pragmatic consolidation around third-party bridging solutions for its EVM sidechain, while leaving room for community input and independent validator decisions. The next steps will hinge on XRPL developer response, validator upgrade rates and any production deployments that demonstrate a continued need for XLS-38. Read more AI-generated news on: undefined/news