Ripple Recommends Withdrawing XRPL’s Unactivated XChainBridge Amendment

Direct answer: Ripple proposed a governed withdrawal, not a bridge shutdown

RippleX recommended on August 27, 2026, that the XRP Ledger community withdraw the still-unactivated XLS-38 XChainBridge amendment and its related rounding fix. Ripple says Axelar already serves the XRPL EVM Sidechain and broader demand did not emerge. The recommendation starts a review and validator-upgrade process, not an immediate code removal or network change. [1]

[Confirmed fact] The primary record is a recommendation from RippleX Developers, not a statement that the amendment has been enabled, disabled by a ledger vote, or deleted from xrpld. Ripple describes an intended process in which a pull request would set the amendment’s vote behavior to obsolete, validators would encounter it as obsolete after upgrading, and the related code could be removed in a later update. [1]

[Bounded inference] For XRP Ledger readers, the important distinction is between availability in the software, support in a particular server response, activation on the network, and a future source-code removal. Those are separate states. Collapsing them into a headline about a bridge being shut down would overstate the record. [1][2][3][5]

Section sources[1][3][5]

What XLS-38 was designed to do

XLS-0038 defines a native cross-chain bridge model for the XRP Ledger. Its design uses a Bridge object plus a set of witness servers that observe lock, claim, and settlement events across two connected chains. The bridge is intended to coordinate transfers of an asset between a locking chain and an issuing chain, with witness attestations acting as the operational link. [4]

[Confirmed fact] The specification was marked Final and dated February 22, 2023. It describes a general mechanism that could serve custom sidechains, private or permissioned environments, experimental networks, and other connected ledgers. That scope is broader than any single production bridge deployment, and the original specification should not be read as proof that a particular bridge is live today. [4]

[Bounded inference] That breadth explains why the proposed withdrawal is a software-governance decision rather than a statement that cross-chain development has no value. Removing one native implementation from the standard server can reduce maintenance surface while leaving other bridge architectures available. It can also reduce ambiguity for builders who might otherwise assume that an unactivated amendment is the preferred path. [1][4]

Section sources[4][1]

Why Ripple now points XRPL EVM Sidechain users to Axelar

RippleX says Ripple selected Axelar for the XRPL EVM Sidechain after evaluating bridge options, and that the EVM Sidechain’s route to and from XRPL Mainnet remains unchanged by the proposed XLS-38 withdrawal. The official XRPL EVM documentation lists Axelar alongside other bridge integrations, while Axelar’s own June 2025 account describes mainnet connectivity for the EVM Sidechain. [1][8][9]

[Confirmed fact] Axelar’s published implementation uses its own network and gateway model, so it is not the same mechanism as the XLS-38 witness-server design. The existence of that live integration does not establish that Axelar is safer for every asset, chain, or custody model. It establishes why Ripple can separate the EVM Sidechain path from a general-purpose amendment in xrpld. [1][8]

[Unresolved uncertainty] Ripple’s recommendation does not provide a public comparative security study, total value-at-risk analysis, or complete inventory of private-sidechain demand. It says the trade-offs of witness servers worsen as value locked grows and invites developers with a strong use case to respond. That is a rationale for a proposal, not an independently measured verdict on all bridge designs. [1]

Section sources[1][8][9]

The proposal combines a demand judgment with a maintenance judgment

RippleX says that in June 2024 Ripple committed to leave XLS-38 available for a vote while its UNL validators voted No, giving the community roughly 12 to 15 months to demonstrate meaningful interest. The August 27 recommendation says that period passed without significant private-sidechain demand. [1]

[Confirmed fact] The same post estimates that withdrawing the amendment could remove more than 10,000 lines from the xrpld codebase. That number is Ripple’s estimate, not a count independently reproduced in the supporting coverage. Crypto Times separately reported the recommendation, the lack of mainnet activation, and the staged removal process, but it did not turn Ripple’s estimate into an audited measurement. [1][7]

[Unresolved uncertainty] There is no public denominator in the recommendation for significant demand. The record does not show how many private-sidechain teams evaluated XLS-38, which use cases were declined, or whether future demand would change the recommendation. Readers should therefore treat the demand claim as Ripple’s current product-maintenance assessment, while treating the code-line figure as a sourced estimate. [1][7]

Section sources[1][7]

How a withdrawal would move through XRP Ledger governance

The XRP Ledger amendment system normally moves from source code into a stable server release and then through validator voting. An amendment needs at least 80 percent support for two weeks to become enabled. If support falls below that threshold before activation, the process restarts. Those rules describe activation, not the exact removal sequence RippleX is proposing for XLS-38. [2]

[Confirmed fact] RippleX says its intended first step is a pull request that sets XChainBridge’s VoteBehavior to Obsolete. Validators running that code would automatically vote against the amendment. As servers upgrade, support for the amendment would decline. Ripple says the code and fixXChainRewardRounding could be removed in a subsequent update after the network considers the amendment obsolete. [1]

[Bounded inference] This staged path gives operators and developers several observable checkpoints. A source diff can show whether the PR exists. A tagged release can show whether the obsolete behavior shipped. Validator software versions and feature responses can show what a queried server reports. None of those checkpoints alone proves that every active validator has upgraded, so a later removal claim needs release and network evidence together. [1][2][5][6]

Section sources[1][2][3][6][5]

Status of XLS-38 at the August 28 public snapshot

The cleanest way to read the current record is to keep the specification, server support, network activation, recommendation, and future implementation work in separate columns. A public feature request to the s1.ripple.com Clio endpoint returned the same XChainBridge result from two public Ripple endpoints at 19:13 UTC on August 28, 2026: supported true, enabled false, validated ledger index 106606274. [5][6]

[Confirmed fact] That response is useful evidence about what those queried public servers reported for a validated ledger. It is not a validator census, not a price signal, and not proof that no operator has a private build. The XRPL known-amendments page separately describes XChainBridge as a feature that can be open for voting or enabled under the normal amendment rules. [3][5]

Section sources[5][6][3][4]

What changes for EVM Sidechain users and bridge developers

For an application using the XRPL EVM Sidechain’s documented bridge route, RippleX says there is no immediate change: Axelar remains the path to and from XRPL Mainnet. The XRPL EVM documentation also lists IBC and Wormhole integrations, showing that the sidechain’s bridge surface is not represented by XLS-38 alone. [1][9]

[Confirmed fact] For a team considering a private or experimental sidechain, the recommendation changes the default expectation around native XLS-38 support. The team would need to explain its use case during the comment period and account for the possibility that the amendment will become obsolete in future server releases. That is a planning implication, not a claim that every existing private deployment will stop. [1]

[Bounded inference] Bridge developers should compare the actual trust and failure model of the route they plan to use: witness quorum, validator set, key management, replay controls, recovery procedures, asset issuance, and operational monitoring. The presence of a named integration or a published specification does not substitute for a deployment-specific review. An independent XRPL ecosystem guide likewise presents multiple bridge paths and warns readers to examine the security model rather than treating one label as a guarantee. [8][10]

Section sources[1][9][8][10]

The security implication is narrower than a verdict on bridges

RippleX’s rationale is partly security-related: it argues that the trade-offs of running witness servers become less attractive as value locked grows and says Axelar was selected for the EVM Sidechain after evaluation. That establishes Ripple’s stated reasoning. It does not establish a universal ranking of Axelar, XLS-38, IBC, Wormhole, or any other bridge. [1][8]

[Confirmed fact] The proposed action is to retire an unactivated native amendment and reduce code that Ripple describes as inactive. It is not a security audit, incident report, exploit disclosure, or finding that the XRP Ledger itself is unsafe. The independent report from Crypto Times confirms the proposal and its staged nature, but it does not supply a separate technical audit of the competing systems. [1][7]

[Unresolved uncertainty] The public record reviewed here does not quantify the security benefit of removing the code, identify every affected downstream implementation, or state whether the community will request a revised bridge design later. Those questions belong in code review, validator discussion, and deployment-specific threat modeling. They should not be answered by inferring market, adoption, or safety outcomes from the withdrawal recommendation alone. [1][2][7]

Section sources[1][7][2]

Implications for validators, contributors, and XRP readers

Validators should treat the proposal as a software-lifecycle item that may eventually require an upgrade, not as an instruction to change votes outside the normal amendment process. Contributors should watch the RippleX repository and release notes for the proposed obsolete behavior, the related fixXChainRewardRounding handling, tests, and any migration notes. The exact source diff matters more than a headline summary. [1][2]

For XRP holders and market observers, the article supports no direct claim about XRP price, demand, volume, adoption, or investment value. RippleX’s post is about XRPL server code, bridge architecture, and the community’s amendment process. A bridge implementation decision can matter to developers and institutions, but its market effect is unresolved and should not be manufactured from this announcement. [1][5][7]

[Bounded inference] The most useful reader action is to identify which layer a claim refers to. If a report says XLS-38 is live, ask for an enabled feature response and amendment history. If it says the code is gone, ask for the exact merged commit and release. If it says EVM Sidechain bridging stopped, compare the claim with the current XRPL EVM documentation and the deployed route. This evidence discipline keeps operational facts ahead of narrative momentum. [3][5][9]

Section sources[1][2][5][9][7]

Evidence boundary: confirmed facts, bounded inference, and unresolved uncertainty

[Confirmed fact] RippleX published the withdrawal recommendation on August 27, 2026. XLS-38 remains an unactivated feature in the public feature responses checked for this report. The official specification defines the native bridge design, the XRPL amendment documentation defines the voting framework, and independent coverage confirms that the recommendation is current rather than an old proposal being revived. [1][2][4][5][7]

[Bounded inference] Taken together, the record suggests a maintenance decision: Ripple is trying to keep the standard server focused on code with an active, demonstrated use case while directing the XRPL EVM Sidechain to an existing Axelar route. That interpretation fits the primary post, but it remains an interpretation of the stated rationale rather than a separate measurement of engineering cost or ecosystem demand. [1][8][9]

[Unresolved uncertainty] The recommendation can still change after community feedback. This report does not claim that a withdrawal vote has completed, that all validators have adopted an obsolete setting, that the code has been removed, or that private-sidechain builders have no future need for a native bridge. Those outcomes require dated primary records and live network evidence when they occur. [1][2][3]

Section sources[1][2][3][4][5][7][9][8]