Validator Trust and UNL Selection, in Practice
How XRP Ledger participants actually decide which validators to trust, and why this trust model is different from proof-of-work or proof-of-stake security.
Running a Validator or rippled Node covers the operational side of running validation software. This page covers the governance question underneath it: how does anyone decide which validators to actually trust?
The Unique Node List (UNL)
Each participant on the XRP Ledger network — not just validators, but any rippled server — maintains a Unique Node List: the set of validators it trusts not to collude. Consensus is reached by comparing proposals from an operator's own UNL, not from every validator on the network indiscriminately (see Consensus Protocol for the mechanics of how agreement is actually reached).
Critically, the UNL is a matter of configuration choice, not protocol enforcement. Nothing in the XRPL's code forces any particular UNL composition.
The default UNL (dUNL)
In practice, the overwhelming majority of network participants don't hand-curate their own UNL from scratch. They use the "default UNL" — a recommended, published list, historically maintained and periodically updated by Ripple and now also published by the XRPL Foundation, of validators judged to meet uptime, reliability, and independence criteria. This is discussed as part of the ongoing decentralization conversation — see The Centralization Debate.
How validators earn inclusion
Publishers of recommended UNLs generally evaluate candidate validators against criteria such as:
- Sustained uptime and reliable ledger validation over a meaningful track record.
- Operator diversity — not being controlled by an entity that already operates other listed validators, to avoid concentrating effective trust.
- Transparent operator identity or a credible reputation, reducing the risk of a silently malicious or compromised node being added.
This is a soft, reputational gatekeeping process rather than a cryptoeconomic one (compare this to how XRPL governance stacks up against Bitcoin and Ethereum — neither uses anything like a UNL, since proof-of-work and proof-of-stake secure the network through cost-of-attack rather than curated trust lists).
Why this model instead of stake-weighted voting
The XRP Ledger deliberately does not weight consensus influence by token holdings (no "more XRP, more voting power," unlike delegated proof-of-stake systems). The rationale is to avoid wealth concentration translating directly into network control. The tradeoff, raised consistently by critics, is that curated trust lists introduce a different kind of centralization risk — who publishes the recommended list, and how independently that list is actually assembled — discussed further in The Centralization Debate.
What changing your UNL actually does
Any operator can add or remove validators from their own trusted list at any time — this changes nothing about the protocol, only which proposals that specific operator's server weighs when computing consensus locally. For the network as a whole to reach agreement, there needs to be substantial overlap between different operators' UNLs; this is why most participants converge on the same published recommended list rather than maintaining wildly divergent ones.