Definition and scope
Full-History, Reporting, and Shard Servers Compared addresses a distinct part of validators and network governance. Compare infrastructure roles for current processing, historical queries, and scalable data access.
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
Stock servers prioritize current ledgers, full-history servers retain the complete chain, Clio reporting servers serve scalable historical queries from separate storage, and shards partition validated history for local retention.
- full history: verify this field, object, or component against the cited protocol documentation.
- Clio: verify this field, object, or component against the cited protocol documentation.
- reporting mode: verify this field, object, or component against the cited protocol documentation.
- shards: verify this field, object, or component against the cited protocol documentation.
- ledger history: verify this field, object, or component against the cited protocol documentation.
Comparison at a glance
Use these dimensions to choose between the concepts without treating their names as interchangeable.
| Role | Primary use | History model | Operational note |
|---|---|---|---|
| Stock xrpld | Current state and submission | Configured recent history | General-purpose network server |
| Full-history xrpld | Complete historical access | All validated ledgers | High storage requirement |
| Clio | Scalable read queries | Separate reporting database | Pairs with validated network data |
| Shards | Selected local history | Partitioned ledger ranges | Does not imply complete history |
Practical example and checks
An application routes submission and current state to trusted xrpld infrastructure while directing large historical analytics to Clio or a verified full-history source.
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
Historical depth does not make a server authoritative if it is stale or untrusted. Each role has different storage, synchronization, and operational costs.
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.