Non-block ledger

XRP Ledger ticker XRP

No public-data lookups yet
6 reviewed developments
39 cited sources

Summary

Validator agreement without mining or staking. Every few seconds, validators propose the set of candidate transactions they have seen and revise their proposals toward those of the validators they trust, over several rounds, until a supermajority agrees on one set. Each server applies the agreed set to the previous ledger version and publishes a signed validation; a ledger version becomes validated, and never changes, once a server sees matching validations from at least 80% of its trusted list (its Unique Node List, or UNL). No one earns a block reward: transaction fees are destroyed. Protocol changes (amendments) take effect after more than 80% of trusted validators support them for two weeks. 1 2 3 4 5 6 7 8

Design

System: Non-block ledgerClassified as a non-block distributed ledger, and the call is contested. The XRP Ledger's own documentation calls its ledger versions blocks and the network a blockchain: each ledger version is hashed and ordered by index. It is grouped apart from classic blockchains because no one mines or stakes to produce ledgers, there is no open weight-based fork choice, and each server decides which validators count through its own trusted list rather than through an on-chain validator set.
Settlement family: Its own design
Scarce resource: Reputation
State model: Accounts
Finality: Other
Who makes blocks: Every validator proposes a transaction set in each round; there is no single leader or block producer. Which validators a server listens to is its own configuration: by default it downloads signed lists from two publishers, the XRP Ledger Foundation and Ripple, and both lists fetched on 2026-09-27 named the same 35 validators. Anyone may run a validator, but it only affects outcomes for servers that choose to trust it.
Fork choice: There is no open weight-based fork choice. A ledger version counts as validated when at least 80% of a server's trusted validators sign it; during outages the Negative UNL can lower that requirement, but never below 60% of the full list. If more than about 20% of trusted validators are unreachable or misbehaving, the network stops validating new ledgers instead of forking. The documentation says that in the worst case about 90% overlap between servers' trusted lists is needed to rule out divergence.

Qualifications

System class · Contested. xrpl.org describes the XRP Ledger as a blockchain whose ledger versions are blocks. This profile groups it with non-block ledgers because there is no mining or staking, no open fork choice and no on-chain validator set; a reviewer following the project's self-description could class it as a base-layer blockchain instead.
Block production · Not applicable. No miner or staker produces ledgers and there is no block reward or proposer payment: validators jointly agree on each ledger version and transaction fees are destroyed.
Block interval · Partial. Ledger versions close every few seconds (the exchange documentation says a new ledger closes about every three to five seconds, the introduction says consensus takes four to six seconds, and the capacity guide assumes about 25,000 ledger versions a day). This is a consensus round, not a mined block time.
Scarce resource · Contested. Consensus weight comes from being trusted by other servers' lists, not from work, stake or storage: the documentation says an attacker's validators have no say unless other participants choose to trust them. It is recorded as reputation, the class for designs in which each node picks whom to trust. Because that trust is set per server by configuration rather than earned or measured on the ledger, some readers would file it as another kind of resource.
Validator decentralization · Contested. Anyone may run a validator and each server chooses whom to trust, but by default servers follow signed lists from two publishers, the XRP Ledger Foundation and Ripple, which named the same 35 validators on 27 September 2026, and operators are warned that lists which differ too much risk a fork. xrpl.org describes the ledger as decentralized; readers may weigh the two publishers' influence over the default list differently. The operators' independence was not reviewed. Not scored here.
Staking and slashing · Not applicable. Holding XRP gives no consensus weight, validators post no bond and there is no slashing; misbehaving validators can only be removed from trusted lists.
Finality · Applies. A transaction is final once it is in a validated ledger version, which never changes. The assumption behind this is that servers' trusted lists overlap heavily; if too many trusted validators are unavailable, validation stops rather than producing competing histories.
Tps · Unknown. The only throughput figure found is an unexplained capacity figure on xrpl.org, recorded with caveats; no measured rate over a stated window was reviewed.
Settlement family · Partial. Recorded as other: the XRP Ledger settles on its own ledger versions, which validators agree on through its Consensus Protocol and which servers running xrpld accept once validated; nothing settles to another chain. None of the named settlement families describes this.

Tradeoffs

This view follows one way of thinking about design priorities, often called the blockchain trilemma. The design-priorities lesson sets out the counter-view. Read the design-priorities lesson.

Emphasizes

Security and Scalability Contested

Gives up

Open, weight-based participation in consensus. Anyone may run a validator, but in practice agreement rests on a default list of 35 validators chosen by two publishers, and operators are warned that lists which differ too much risk a fork. The design also stops, rather than forks, when more than about a fifth of trusted validators are offline, and the publisher's production server specification assumes data-centre networking.Security here means safety through validator independence rather than through a mining or staking cost: confirming an invalid transaction would take collusion by more than 80% of trusted validators. xrpl.org calls the ledger permissionless and decentralized; because agreement in practice rests on two publishers' default list and the independence of the listed operators was not reviewed, that reading is contested. The scalability emphasis refers to settlement in seconds and low fees; no measured throughput is used.

Full node at home

Demanding 12 13The server documentation recommends, for production, an 8-core 3 GHz or faster CPU, 64 GB RAM, NVMe storage sustaining 10,000 IOPS and a gigabit interface on an enterprise data-centre network; its 16 GB minimum is for testing and is described as not enough to stay reliably in sync with mainnet. Normal traffic is about 2 Mbps each way, with peaks above 100 Mbps upload. Storage is bounded by online deletion; full history was estimated at about 26 TB in July 2023.

Throughput claims

Unclassified: 1,500 tx/s 15Unclassified; do not compare.xrpl.org lists this figure under the heading Scalable with no measurement window, method, hardware or workload, so it is not known whether it is a peak, a benchmark or an observed rate. Not comparable with other chains' figures or with observed load. Ignores propagation, state growth and spam load; the ledger's fee escalation raises costs as volume grows. Whether a server meeting the published production specification sustains this rate was not reviewed.

Headline figures are not comparable across chains. A theoretical peak is never a like-for-like number.

Scaling layers

XRP payment channels (built into the ledger) · Payment channels, mainnet 17
One-way channels built into the XRP Ledger: the payer locks XRP in a channel and sends signed claims off-ledger, which the payee checks and can redeem on the ledger at any time. Only XRP can be used. The payee's risk is limited to claims it has not redeemed before the channel expires; a close request by the payer while XRP remains sets an expiry, so the payee must watch the ledger and redeem in time. Each channel links one payer to one payee; there is no routed network. (as of Sep 27, 2026)
XRPL EVM Sidechain · Sidechain, mainnet 24 25 26 27 28 29
A separate network built with the Cosmos SDK that runs Ethereum-compatible contracts and uses XRP as its gas token. Its validators run under a proof-of-authority model and are admitted by a vote of existing validators. XRP and XRP Ledger tokens reach it through Axelar, so users rely on the sidechain's validators and on Axelar's validator set, not on XRP Ledger consensus. It is not a rollup: the XRP Ledger does not verify its state. (as of Sep 27, 2026)

Capabilities

Capabilities of XRP Ledger: how each one is provided, or its research status
Capability	How it is provided	Notes and sources
Account abstraction	Structured assessment pending	Not yet assessed for any chain.
Atomic swaps	Built into the protocolLimited scope	Limited to exchanges on the XRP Ledger itself. The ledger's built-in decentralized exchange settles order-book trades and cross-currency payments in a single transaction, so both assets move together under the ledger's own rules. Conditional escrows lock XRP or opted-in tokens behind a SHA-256 preimage condition, with an expiry (optional for XRP, required for tokens) after which the escrow can be cancelled and the funds returned to the sender; that hash-locked, time-locked building block can support cross-chain swaps, but no such tooling was verified. 16 20
Authenticated data publication	Unknown	Not yet assessed under the current definitions; the reviewed documentation describes small records that originate elsewhere, such as price oracle entries, decentralized identifiers and credentials, but these are ledger entries held in chain state, which the current definition does not count as publication. The earlier review did not verify that no other publication feature exists. 23
Light clients	Unknown	Not yet assessed under the current definitions; the reviewed server documentation describes full, validator, API, hub and stand-alone modes but no light client or proof-based verification mode, and a server answers only from history it holds. No specified light-verification method was found, and absence was not exhaustively verified. 14
Native staking or delegation	Structured assessment pending	Not yet assessed for any chain.
On-chain governance	Structured assessment pending	Not yet assessed for any chain.
Parallel execution	Structured assessment pending	Not yet assessed for any chain.
Payment or state channels	Native (protocol or core-team software) Earlier definition	XRP payment channels are a built-in ledger feature: payers fund a channel and send signed claims off-ledger that payees redeem later. They are one-way and XRP-only, and do not form a routed network. 17
Programmable spending	Partial (layer not stated) Earlier definition	Spending rules come from built-in transaction types rather than user-written code: time and hash conditions on escrows, weighted multi-signing with up to 32 signers, and similar account settings. General smart contracts are not live on the XRP Ledger; Smart Escrows, which would add WebAssembly functions to escrows, are listed as in development. Hooks run on Xahau, a separate network, and EVM smart contracts run on the XRPL EVM sidechain. 9 16 18 25 39
Protocol-verified messaging	Structured assessment pending	Not yet assessed for any chain.
Reversible transfers or recovery	Built into the protocolLimited scope	Part (a) through built-in escrows: a sender can lock XRP or opted-in tokens in an escrow with an expiry, after which an unfinished escrow can be cancelled and the funds returned to the sender. No sender reclaim of an ordinary completed payment was found. Part (b) is not met by the protocol: multi-signing or a replaceable regular key let an account rotate or recover keys, which is rotation or a plain multisig threshold. Token issuers can claw back trust-line tokens or Multi-Purpose Tokens only if they enabled clawback before issuing: issuer control over holders; XRP cannot be clawed back. 16 18 19
Rollups	Unknown	Absence was not verified, so the rule that absence needs a source makes this unknown rather than not present. The earlier review found no rollup settling to the XRP Ledger: the XRPL EVM network is a sidechain with its own validators, and the ledger's built-in cross-chain bridge amendment (XChainBridge) is not enabled on mainnet. 10 24
Shielded transfers	Structured assessment pending	Not yet assessed for any chain.
Signed partial offers	Unknown	Not yet assessed under this row's current definition.

Reading these values

How this feature is provided: Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
Structured assessment pending: The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
Unknown: The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
Earlier definition: Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
Reading across rows: The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.

Definitions, schema version and review history

Ecosystem & custody

Ecosystem products for XRP Ledger
Product type	Status	Notes and sources
Automated market makers	Native to the protocolXRP Ledger AMM pools (built in), XRP Ledger order-book exchange (built in)	The ledger has run an order-book exchange since its 2012 launch and added built-in constant-product AMM pools in March 2024 (one pool per asset pair, trading fee 0 to 1% set by liquidity-provider vote). Payments use whichever of pools and order books gives the better rate. Permissioned order books for credential holders, enabled in February 2026, do not use AMM pools. Liquidity depth was not measured. 10 20 21 22 As of Sep 27, 2026.
Issuer-native stablecoins	Established in the ecosystemRipple USD (RLUSD), USDC (Circle)	Both are issued directly on the XRP Ledger by their issuers, not bridged: Ripple says RLUSD is natively issued on the XRP Ledger, Ethereum and other blockchains through a limited-purpose trust chartered by New York's financial regulator, and Circle's address list gives a USDC issuer account on the XRP Ledger. Holders rely on each issuer and its reserves. Tether's supported-protocols page and Circle's cross-chain transfer list do not include the XRP Ledger. 30 31 32 33 As of Sep 27, 2026.
Algorithmic stablecoins	Unknown	No algorithmic or hybrid stablecoin with material usage on the XRP Ledger was reviewed. xrpl.org mentions algorithmic stablecoins only as a possible sidechain use. 24 As of Sep 27, 2026.
Bridges	Established in the ecosystemAxelar (through the Squid bridge interface)	The XRPL EVM documentation routes XRP, XRP Ledger tokens and ERC-20 tokens between the XRP Ledger, the XRPL EVM sidechain and other chains through Axelar. The ledger's own witness-based bridge amendment (XChainBridge) is not enabled on mainnet: on 2026-09-27 explorer data showed 6 supporting validators against a threshold of 27. Risk: Bridged assets depend on Axelar's proof-of-stake validators, which co-sign cross-chain requests, and on the gateway accounts they control, not on XRP Ledger consensus; a fault or compromise there can strand or inflate bridged assets. Axelar's XRP Ledger-specific setup was not reviewed from Axelar's own documentation. 10 24 28 29 As of Sep 27, 2026.
Block explorers	Established in the ecosystemXRPL Explorer (livenet.xrpl.org), Bithomp, XRPScan, XRPLWin, RWA.xyz	xrpl.org lists these five explorers. The XRPL Explorer is open-source software maintained by Ripple. Listing is not a quality check, and explorer data is provider-indexed rather than independently validated. 34 35 36 As of Sep 27, 2026.
Hardware wallets	Established in the ecosystemLedger, Trezor	See custody rows: both vendors' own pages list XRP support in their own wallet apps. Support for XRP Ledger tokens on those devices was not verified. 37 38 As of Sep 27, 2026.

Hardware-wallet custody

Hardware-wallet custody for XRP Ledger
Device maker	Status	What users can and cannot do
Ledger	Native supportSame as native: Yes	Can: Receive XRP at addresses derived on the Ledger device Can: Send XRP from Ledger Wallet (formerly Ledger Live) after verifying the transaction on the device Can: Track XRP balances in Ledger WalletLedger's page reminds users that a new XRP account needs the 1 XRP base reserve. Handling of XRP Ledger tokens (trust lines, RLUSD, Multi-Purpose Tokens) in Ledger Wallet was not verified. 37 As of Sep 27, 2026.
Trezor	Native supportSame as native: Yes	Can: Send and receive XRP in the Trezor Suite app, which the page says supports XRP directly Can: Use XRP on the Trezor Safe 3, Safe 5 and Safe 7 listed on the pageThe page also lists the XRPL EVM network. Support on older Trezor models and for XRP Ledger tokens was not verified. 38 As of Sep 27, 2026.

Public data

iKnow Blockchain has no public-data lookups for XRP Ledger yet. This is a limit of the service, not a statement about the network.

Public-data lookups for XRP Ledger
Lookup	Status	What it covers and its limits
Address or account	Not available yet	Public-data lookups for this chain are not built yet.
Tokens and assets	Not available yet	Public-data lookups for this chain are not built yet.
NFTs	Not available yet	Public-data lookups for this chain are not built yet.
Transactions	Not available yet	Public-data lookups for this chain are not built yet.

A lookup covers one address or transaction from one provider. It is never a complete wallet, and an error or private value is reported as unknown, not zero. About public data · Connect your AI

Sourced developments

Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.

Publication date · newest first

Published Sep 25, 2026ProtocolVerified against sources

xrpld 3.4.1 emergency release adds fixBatchV1_2

An emergency release of the reference server fixed security-sensitive protocol issues and added the fixBatchV1_2 amendment, which rejects Batch inner transactions carried in the wrong wrapper. The release notes say the amendment already had supermajority support and was expected to take effect on 2026-10-09.
- Proposal:fixBatchV1_2 amendment with default Yes vote
- Implementation:implemented in xrpld 3.4.1
- Release:released 2026-09-25
- Activation:expected 2026-10-09 if support holds; not active as of this review
Date basis: Date shown on the xrpl.org blog. The 2026-10-09 activation is the release notes' expectation, not an observed event.

Sources: XRP Ledger blog (xrpl.org) — Introducing XRP Ledger version 3.4.1 (external site) · XRP Ledger documentation (xrpl.org) — Amendments (external site)
Published Sep 16, 2026ProtocolVerified against sources

xrpld 3.4.0 released with two new amendments that are not yet active

Version 3.4.0 of the reference server added two amendments. LendingProtocolV1_1 extends the Lending Protocol and Single Asset Vault features with closed-ended vaults and interest counted only when payments arrive. fixCleanup3_4_0 bundles fixes for trust lines, the permissioned DEX, AMM clawback rounding, Multi-Purpose Token checks, NFT offers and escrow reserves. The release also retired fixAMMOverflowOffer, told operators to upgrade as soon as possible, and moved Linux packages to packages.xrplf.org with XRPLF signing keys.
- Proposal:LendingProtocolV1_1 and fixCleanup3_4_0 amendments introduced; fixAMMOverflowOffer retired
- Implementation:implemented in xrpld 3.4.0
- Release:released; xrpl.org announcement dated 2026-09-16, GitHub release published 2026-09-17
- Activation:neither new amendment enabled on mainnet at review; explorer data showed 16 and 0 of the 28 validator votes needed
Date basis: Date shown on the xrpl.org announcement; the GitHub release page shows 17 September 2026. Vote counts are XRPScan explorer data read on 2026-09-27 at about 18:00 UTC.

Sources: XRP Ledger blog (xrpl.org) — Introducing XRP Ledger version 3.4.0 (external site) · XRPLF (GitHub releases) — Version 3.4.0 of xrpld (external site) · XRPScan — XRPScan amendments API (external site) · XRP Ledger documentation (xrpl.org) — Amendments (external site) · XRPLF (GitHub) — Release notes from rippled (external site)
Published Aug 18, 2026ProtocolVerified against sources

Report on the July 2026 peer-message flood: ledger kept validating

An incident report described a flood of junk validator manifest messages that began on the evening of 30 July 2026 and caused mass peer disconnects across the network, including at two default-list validators. The report says the ledger never halted or forked, no funds or keys were affected, and a 3.2.1 hotfix limiting manifest sizes and caches was released on 31 July, with limits adjusted in 3.3.0.
- Implementation:manifest size, per-message and cache limits added to the reference server
- Release:3.2.1 hotfix released 2026-07-31; limits loosened in 3.3.0 the following week
- Activation:server software change, effective as each operator upgrades; the report describes no amendment
Date basis: Publication date shown on the xrpl.org report. The incident began on 30 July 2026 (Pacific Time) and the hotfix was released on 31 July, per the report.

Source: XRP Ledger blog (xrpl.org) — Vulnerability Disclosure Report: XRPL Manifest Flood (external site)
Published Feb 26, 2026ProtocolVerified against sources

Batch amendment signature flaw disclosed before activation

A disclosure report described a loop error in the proposed Batch amendment's signature checks that would have let an attacker run inner transactions from other accounts without their keys. The amendment was still in voting and had not activated, so no funds were at risk. Server version 3.1.1 marked Batch as unsupported, and a corrected replacement amendment was prepared.
- Proposal:Batch amendment withdrawn; replacement BatchV1_1 in voting
- Implementation:fix and replacement implemented in later server releases
- Release:3.1.1 released 2026-02-23 marking Batch unsupported
- Activation:original Batch never activated; replacement not active as of this review
Date basis: Date shown on the xrpl.org blog index; the report says the flaw was reported on 19 February 2026.

Sources: XRP Ledger blog (xrpl.org) — Vulnerability Disclosure Report: XRPL Batch Amendment - Unauthorized Inner Transaction Execution (external site) · XRPScan — XRPScan amendments API (external site)
Published Feb 18, 2026ProtocolVerified against sources

Token escrow, permissioned domains and permissioned DEX enabled on mainnet

Three amendments took effect in February 2026: PermissionedDomains, TokenEscrow, which lets opted-in trust-line tokens and Multi-Purpose Tokens be held in escrow, and PermissionedDEX, which adds order books open only to accounts holding credentials accepted by a domain.
- Proposal:TokenEscrow and PermissionedDEX introduced in server version 2.5.0; PermissionedDomains in 2.4.0
- Implementation:implemented in the reference server
- Release:Released
- Activation:enabled on mainnet in February 2026 per explorer amendment data
Date basis: XRPScan amendment data retrieved 2026-09-27: PermissionedDomains 2026-02-04, TokenEscrow 2026-02-12, PermissionedDEX 2026-02-18. The date used is the last of the three.

Sources: XRPScan — XRPScan amendments API (external site) · XRP Ledger documentation (xrpl.org) — Escrow (external site) · XRP Ledger documentation (xrpl.org) — Permissioned DEXes (external site)
Published Oct 1, 2025ProtocolVerified against sources

Multi-Purpose Tokens enabled on XRP Ledger mainnet

The MPTokensV1 amendment took effect, adding Multi-Purpose Tokens: a second fungible token type with one issuance record per token, an optional maximum supply, issuer-set transfer fees and opt-in lock and clawback controls. They cannot yet be traded on the built-in exchange.
- Proposal:MPTokensV1 amendment, introduced in server version 2.3.0
- Implementation:implemented in the reference server
- Release:Released
- Activation:enabled on mainnet 2025-10-01 per explorer amendment data
Date basis: XRPScan amendment data retrieved 2026-09-27 gives an enabled time of 2025-10-01T13:13:10Z at ledger 99,226,369. The xrpl.org status table loads dynamically and could not be read.

Sources: XRPScan — XRPScan amendments API (external site) · XRP Ledger documentation (xrpl.org) — Multi-Purpose Tokens (external site) · XRP Ledger documentation (xrpl.org) — Known Amendments (external site)

Topics your AI can explain

Your AI can explain these topics for XRP Ledger through the connection, with sources.

What the XRP Ledger is, and what XRP is
How XRP Ledger consensus works: trusted validator lists
Accounts and ledger entries: the XRP Ledger state model
XRP, drops, fees and reserves
When an XRP Ledger transaction is final
The built-in exchange: Offers, order books and AMM pools
Escrow, payment channels and sidechains: what sits beside the XRP Ledger

Known gaps

What this profile's review did not establish:

The operators, jurisdictions and independence of the 35 validators on the default lists were not reviewed.
The total number of validators and tracking servers on the network was not measured.
A full history of mainnet validation pauses or outages was not reviewed. One incident was read: the developers' report on a July 2026 flood of peer messages says many servers, including two default-list validators, lost most of their peers, while the ledger itself neither halted nor forked.
No light-client or proof-based verification protocol was found; the light-client row is unknown rather than not present.
Axelar's XRP Ledger-specific gateway and signer setup was not read from Axelar's own documentation; the bridge risk note rests on Axelar's general security page.
The XRPL EVM sidechain's launch date and validator count were not verified.
Xahau is listed by xrpl.org as a sidechain example, but how value moves between it and the XRP Ledger was not verified, so it has no scaling row.
Algorithmic or hybrid stablecoins on the XRP Ledger were not reviewed.
Freeze and clawback settings of the RLUSD and USDC issuances, and their supply on the XRP Ledger, were not reviewed.
Ledger Wallet and Trezor Suite support for XRP Ledger tokens (trust lines, RLUSD, Multi-Purpose Tokens) was not verified.
The only throughput figure is an unexplained capacity number on xrpl.org; no measured rate was classified.
Consensus round length varies across xrpl.org pages (three to five versus four to six seconds); no measured window was reviewed.
Full-history storage figures date from a July 2023 estimate.
Mainnet amendment status comes from XRPScan provider data because the xrpl.org status table loads dynamically and could not be read.

Sources

Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.

All 39 sources were checked in the last 30 days.

Consensus Protocol (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Consensus Structure (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Consensus Protections Against Attacks and Failure Modes (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Unique Node List (UNL) (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Negative UNL (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Default validator list (signed list, 35 validators when fetched) (external site)XRP Ledger Foundation · retrieved Sep 27, 2026
Recommended validator list (signed list, 35 validators when fetched) (external site)Ripple · retrieved Sep 27, 2026
Amendments (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Known Amendments (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
XRPScan amendments API (mainnet amendment status and votes) (external site)XRPScan · retrieved Sep 27, 2026
Transaction Cost (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
System Requirements (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Capacity Planning (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
xrpld Server Modes (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
XRP (external site)XRP Ledger (xrpl.org) · retrieved Sep 27, 2026
Escrow (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Payment Channels (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Multi-Signing (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Clawing Back Tokens (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Decentralized Exchange (DEX) (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Automated Market Makers (AMMs) (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Permissioned DEXes (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
Decentralized Storage (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
XRPL Sidechains (external site)XRP Ledger documentation (xrpl.org) · retrieved Sep 27, 2026
XRPL EVM Sidechain documentation (external site)XRPL EVM documentation (ripple/docs.xrplevm.org) · retrieved Sep 27, 2026
XRPL EVM networks (mainnet and testnet) (external site)XRPL EVM documentation · retrieved Sep 27, 2026
Join the XRPL EVM proof of authority (external site)XRPL EVM documentation · retrieved Sep 27, 2026
Transfer XRP with Axelar (external site)XRPL EVM documentation · retrieved Sep 27, 2026
Security Overview (external site)Axelar documentation · retrieved Sep 27, 2026
Ripple USD (RLUSD) stablecoin (external site)Ripple · retrieved Sep 27, 2026
USDC contract addresses (external site)Circle · retrieved Sep 27, 2026
CCTP supported chains and domains (external site)Circle · retrieved Sep 27, 2026
Supported protocols (external site)Tether · retrieved Sep 27, 2026
XRPL Explorers (external site)XRP Ledger (xrpl.org) · retrieved Sep 27, 2026
XRPL Explorer source repository (external site)Ripple · retrieved Sep 27, 2026
Bithomp XRP Explorer (external site)Bithomp · retrieved Sep 27, 2026
XRP wallet (external site)Ledger · retrieved Sep 27, 2026
XRP wallet (external site)Trezor · retrieved Sep 27, 2026
Xahau (external site)Xahau · retrieved Sep 27, 2026

Report an error

Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.

Report an error about XRP Ledger Corrections log

Funding disclosure

Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding