A holder can recognize XRP in a wallet and still be using a different ledger. XRPL EVM is a standalone EVM network connected to the XRP Ledger through bridging infrastructure. Its contracts execute in that environment, rather than turning every XRP Ledger account into an Ethereum account. The bridge documentation treats Axelar, IBC and Wormhole as distinct connections. That separation matters when following balances: a completed XRP Ledger transaction, an accepted cross-chain message and a usable balance on the destination are different stages.

None can be inferred merely from the token's familiar name.

Axelar's June 30, 2025 announcement placed the public launch at EthCC and described wrapped XRP as the native gas asset. It named Squid as the transfer interface and listed intended application partners. This is evidence of launch arrangements, not evidence that every partner subsequently achieved sustained usage. There is no separate sidechain coin implied by using XRP for fees. The account here therefore concerns the network and its controls; the original XRP market asset retains its own history and cannot stand in for an audit of this chain.

Mayukha Vadari's October 2022 announcement described a first devnet phase, not a production service holding ordinary XRP. Developers could test Solidity contracts and transfers of devnet XRP through a bridge. Later phases were supposed to widen participation before a mainnet release. Those dates and promises belong to the project's original plan, rather than a record that every step happened on schedule. The attraction was practical: an existing Ethereum developer could bring familiar tools to an XRP-related environment without waiting for the XRP Ledger itself to adopt that execution model.

The June 2023 devnet introduced a new iteration with proof of authority, CometBFT and an experimental bridge based on XLS-38. Vadari described a witness-server design and warned that the older devnet would be retired. The announcement also associated a future mainnet bridge with amendment approval. That dependency later changed. Reading the 2023 instructions as current onboarding would confuse an experimental chain, obsolete identifiers and a superseded bridge design with the public network.

The useful history is the engineering choice being tested, not a timeless promise that the original architecture eventually shipped unchanged.

David Fuelling's later withdrawal recommendation explains Ripple's change of direction. The team judged that running a public bridge at scale required specialized operational experience and selected Axelar. Fuelling also said the anticipated demand for private chains using XLS-38 had not materialized strongly enough to justify continued maintenance. This is Ripple's stated assessment, not proof that nobody wanted the amendment. The article explicitly invited contrary use cases and described withdrawal as a recommendation subject to the wider XRP Ledger process.

Removing unused amendment code is a different act from shutting down the operating EVM sidechain.

The cross-chain transaction guide shows why a bridge is more than a convenient button. Its Axelar examples involve observation, verification, routing and relaying before the destination action completes. A contract can combine a source-chain action with a destination-chain service, but the developer must account for these intermediate stages. The guide's application examples are teaching patterns rather than an inventory of deployed products.

They help explain why a user may see one transaction succeed while still waiting for the corresponding application result elsewhere, and why troubleshooting must follow the message across the whole route.

The validator onboarding guide describes an admission process rather than permissionless entry through a token purchase. An applicant introduces its organization or community role, supplies operator information and seeks approval from existing validators. The documented ordinary process includes a seven-day vote. This creates a legible accountability structure, but it also places entry decisions with the incumbent set. Users should separate the ability to deploy a contract from the authority to validate the chain.

Open application development and restricted block production can coexist, and describing both simply as decentralization conceals the distinction that matters.

The public governance interface preserves decisions about validator additions, removals, fees and software changes. It also records failed proposals, including a proposed upgrade path that did not pass before a later attempt succeeded. That makes the proposal history more informative than a list of organizations on a landing page. Votes reveal what the participating validators authorized at a particular time. They do not by themselves prove that every node installed the resulting binary or that a proposed recovery transaction completed.

For those questions, proposal records must be paired with execution evidence or a later operational report.

The network resource table distinguishes the mainnet identifier from testnet and devnet identifiers and records earlier genesis and upgrade milestones. It is useful for tracing how an environment changed. It should not be treated as the sole source of the latest software version: the same review found newer incident and hardening reports than the table's listed release. A mainnet genesis date can also precede a public launch announcement.

Keeping those events separate avoids inventing an early public opening from a configuration artifact that was initially relevant to operators and preparation.

Proposal 33 records the July 2026 approval of a v10.1.0 software change, including the intended upgrade height and vote result. Proposal records make a roadmap testable: a reader can inspect an actual decision instead of relying on a future-tense announcement. They also narrow the claim. An approved height is an instruction to operators, not a performance benchmark or an assurance that no deployment complication occurred. This distinction is especially important for a young network whose public documentation, node releases and governance records are updated on different schedules.

Wormhole's integration documentation identifies its own chain number separately from the EVM chain identifier. It describes Guardian attestations and distinguishes messaging, wrapped transfers and native-token transfer tooling. These are not interchangeable names for the Axelar route. The same page says Wormhole is live on XRPL EVM while the non-EVM XRP Ledger route is still rolling out, directing current XRPL-to-sidechain transfers to Axelar. An integration headline therefore needs a route-specific reading.

Support for the destination EVM chain does not automatically establish support for the original XRP Ledger or every token advertised across an ecosystem.

The node command-line guide exposes governance, proof-of-authority, staking-related and upgrade queries alongside ordinary account operations. These interfaces give operators and technically capable readers ways to inspect configuration rather than taking a graphic as evidence. They do not turn a reader into a validator, bypass the admission process or remove the risks of signing a transaction. A useful distinction runs through the guide: querying a state is observation, while submitting a transaction asks the network to change it.

Published instructions should preserve that distinction when helping a newcomer investigate the system.

The September incident report describes an August 23 precautionary halt after disclosure of a Cosmos EVM vulnerability affecting other networks. It reports a pause of fourteen hours and seventeen minutes and a patched release on the same day. The team said it found no exploitation or lost user funds on XRPL EVM and explained why the configuration differed from affected deployments. Those are attributed findings from the operator's response, not an independent guarantee.

The halt nevertheless demonstrates an important operational reality: coordinated intervention can stop normal activity while maintainers assess a vulnerability in shared software.

The July v11 design article proposed tighter outbound limits, a longer unbonding interval, restrictions on interchain accounts and a mechanism to recover XRP stranded through an Elys channel. It is valuable as an explanation of the problems the developers intended to address. A publication about an upgrade does not establish that every listed protection was already active that day.

Its treatment of stranded assets also distinguishes recovery from ordinary bridging: exceptional intervention needs explicit authorization and a defined destination, rather than the assumption that another bridge button can reverse any failed cross-chain sequence.

Proposal 38 records approval of the v11.2.0 upgrade in September, including interchain-account restrictions and recovery work. It follows earlier recovery and parameter proposals in the governance history. The record provides a dated authorization boundary for claims about these changes. A reader interested in a specific protected feature should inspect the exact proposal and subsequent operational statements, rather than treating the shared version prefix as a complete description.

Governance records are particularly useful here because they preserve when validators agreed to a change even when an explanatory blog post was written earlier.

Adria Carrera's September 24 hardening account reports accepted findings and merged fixes across the node. Examples include a bypassed outbound IBC rate-limit path, interchain-account restrictions and a validator-creation guard whose previous condition was unsatisfiable for ordinary users. The article distinguishes exploitable configuration concerns from defensive improvements and test coverage. That specificity should survive retelling. A patched guard does not prove that an attacker previously created validators; a merged test does not certify every bridge.

The report also says the hardened version was running, providing later operational context that the older network table lacks.

The original launch discussion did not produce a single community verdict. DannyHodler expressed enthusiasm about what Ripple might build, Spartan3123 focused on bridge attacks, and MaeronTargaryen interpreted EVM adoption as evidence of Ethereum's influence. These were different theses, not measurements of adoption. Their disagreement is useful because it identifies three questions the project still has to answer separately: whether applications attract users, whether the cross-chain route protects assets, and which network captures the benefit of a common software standard.

A price conclusion cannot be read directly from any one of those premises.

The June 2023 r/XRP devnet discussion shows a more basic educational problem. piping_piper asked whether the system was linked to Ethereum or simply brought Solidity to an XRP-related chain; lj26ft answered by separating EVM compatibility from Ethereum itself. The record captures genuine effort to understand the architecture, but a comment is not the specification. Clear network names, accurate chain identifiers and explicit bridge descriptions do more for that confusion than another broad claim that the ecosystem has gained smart contracts.

In January 2024, liberom asked whether the anticipated sidechain already existed. pac-man_dan-dan initially interpreted the situation differently, then acknowledged the testnet while expressing opposition to the project; other participants supplied documentation. This small exchange preserves uncertainty and dissent that a launch chronology alone would miss. It does not establish a vote by the XRP community. It shows why an encyclopedia needs to label the difference between a development environment, an announced plan and a public network that people can actually use.

A separate January 2024 issue by GoulvenFrs concerned an Expo React Native application whose third-party chain configuration still used an older devnet identifier. The author provided the attempted replacement configuration and the resulting provider error. This is concrete evidence of an integration obstacle, not proof that the sidechain itself had stopped. It also supplies a grounded definition of developer adoption: a working contract platform needs maintained wallet and library metadata as well as consensus software.

The issue was closed, but the visible report alone does not justify inventing which fix resolved the application.