Definition and scope
Unique Node Lists Explained addresses a distinct part of validators and network governance. Understand how each server chooses the validators it trusts not to collude.
XRPL governance is distributed across deterministic software rules, server operators, validator choices, amendment voting, and the consensus process. These topics clarify what validators can do, what they cannot do, and how protocol changes become active. No single validator or list publisher controls the ledger. Consensus claims must distinguish local trust configuration from network-wide results.
How it works
A Unique Node List is the set of validators a server trusts not to collude. Servers can use published recommended lists or custom choices, and consensus safety depends on sufficient overlap among honest participants.
- UNL: verify this field, object, or component against the cited protocol documentation.
- validator list: verify this field, object, or component against the cited protocol documentation.
- list publisher: verify this field, object, or component against the cited protocol documentation.
- quorum: verify this field, object, or component against the cited protocol documentation.
- overlap: verify this field, object, or component against the cited protocol documentation.
Practical example and checks
An operator reviews publisher identity, validator performance, list expiration, and overlap before configuring validator list sites, then monitors whether the server reaches full validation agreement.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
UNL does not mean every listed validator is owned by one party, nor is there one protocol-mandated list. Poorly chosen trust sets can impair liveness or safety.
No single validator or list publisher controls the ledger. Consensus claims must distinguish local trust configuration from network-wide results.
Current network status
Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.