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.
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.
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.
No validator changes since 2026-06-02.
No validator changes since 2026-06-02.
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).
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.
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.
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-06-03T20:46:58Z.