XRPL validator lists, live

XRPL consensus depends on each validator trusting a Unique Node List (UNL). There are two canonical published lists — Ripple's and the XRPL Foundation's. This page shows the live status of both, the validator overlap between them, and why XRPL kept producing ledgers through a months-long Foundation UNL expiry.

current

Ripple UNL

Operated by Ripple
Validators 35
Manifest sequence 85
Expiration 2027-04-06T17:51:34Z
Time remaining 261 days
expired

Foundation UNL

Operated by XRPL Foundation
Validators 35
Manifest sequence 2025011701
Expiration 2026-01-18T00:00:00Z
Past expiry 183 days

Manifest sequence note: Ripple publishes a simple monotonic counter; the Foundation encodes the publish date as YYYYMMDDNN. Both are valid — XRPL accepts any strictly increasing integer per validator key.

Validator overlap

How many validators are published on both UNLs, and how many appear on only one. This overlap is the practical reason consensus held through the Foundation UNL expiry — operators carrying both lists still had a working quorum — the Ripple UNL alone was sufficient for consensus.

Ripple Foundation 4 Ripple-only 31 on both lists 4 Foundation-only
Ripple-only: 4 on both: 31 Foundation-only: 4 Jaccard: 79.5%

Recent UNL changes

Ripple UNL

No validator changes since 2026-07-18.

Foundation UNL

No validator changes since 2026-07-18.

What XRPL is being used for

Every validated transaction on the ledger belongs to one of a small number of built-in types. This section groups the raw types into plain-English buckets so a first-time visitor can see, at a glance, what the ledger is actually being asked to do.

This is a count of transactions, not dollar value. A single trust-line update and a 10-million-XRP payment each count once. The mix says what the ledger is being asked to do, not how much value is moving.
Window: 24h 7d 30d 7,782,673 transactions counted
Payments
Direct account-to-account transfers, including routed swaps that settle through the DEX or an AMM but arrive as a Payment.
2,394,698
30.8%
DEX order book
Adding and cancelling limit orders on XRPL's native order book.
4,586,273
58.9%
AMM activity
Automated market maker events — creating pools, adding or removing liquidity, voting, or bidding on auction slots.
7,629
0.1%
Trust-line changes
A holder adjusting the relationship with an issued-currency issuer (opening, closing, or updating a trust line). Trust-line count is a housekeeping metric, not a demand signal.
119,615
1.5%
NFT operations
Minting, burning, offering, or accepting XRPL native NFTs.
243,564
3.1%
Escrow / channels / checks
Time-locked or conditional payments — escrows, payment channels, and Checks.
7,867
0.1%
Account admin
Housekeeping on an existing account: flag changes, regular-key rotations, signer-list updates, ticket allocation, account deletion.
418,203
5.4%
Newer & experimental
Recently-enabled features — MPTs, DIDs, credentials, permissioned domains, and cross-chain bridges.
4,817
0.1%
Amendments & consensus
Protocol-level events emitted by validators themselves — amendment votes, fee-vote settlement, UNL modifications.
7
0.0%
Routed swaps count as Payments. XRPL lets a Payment transaction route through the order book or an AMM and settle in a different currency than it started in. It still shows up in the Payments row, not DEX or AMM — so those two rows undercount how often on-chain markets are being touched.
Trust-line changes are administrative. Opening, closing, or updating a trust line is housekeeping between a holder and an issuer. A high trust-line count says nothing about demand for the underlying token — it counts changes to the relationship, not activity within it.

How XRPL kept consensus when one UNL went stale

What a UNL is

A Unique Node List is the set of validators a single XRPL node chooses to trust. Consensus requires 80 percent agreement among the validators on the node's UNL — not across the whole network. Each operator configures their own UNL (or, more commonly, subscribes to one or more published lists).

Why two lists

Both Ripple and the XRPL Foundation publish signed UNLs to make it easy for operators to bootstrap a trustworthy validator set. The two lists overlap heavily but aren't identical — Ripple publishes a curated set, the Foundation publishes a partially-different curated set, and operators can subscribe to either or both.

Why the Foundation expiry didn't break the ledger

Each published UNL has its own expiration. When the Foundation UNL's signed manifest expired on 2026-01-18, operators relying on it stopped accepting it as authoritative — but the validators on the Ripple UNL kept signing every ledger as normal. Because most operators subscribe to both lists, and because of the overlap shown above, every node configured with the default Ripple UNL still had a working quorum. The Foundation UNL going stale is an operations event for the Foundation, not a consensus event for the ledger.

truth-first note This page reads only the two canonical published lists. Many operators run their own UNLs (or carry validators not on either published list); those custom configurations are invisible to us. The overlap number above describes the published-list relationship, not the full picture of who any specific operator trusts.

Cross-references

Manifests fetched directly from vl.ripple.com and vl.xrplf.org. Each blob is base64-decoded server-side and the sequence, validator count, and expiration are read straight from the signed payload — no off-ledger interpretation. Cached for up to 10 minutes.
Fetched 2026-07-19T08:15:35Z.