Definition and scope
Running a Stock Server vs. a Validator addresses a distinct part of validators and network governance. Compare transaction-processing infrastructure with servers that also publish signed validation messages.
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 stock xrpld server relays transactions, follows consensus, validates ledgers locally, and serves APIs. A validator adds signed proposal and validation publication using a configured validator identity.
- stock server: verify this field, object, or component against the cited protocol documentation.
- validator mode: verify this field, object, or component against the cited protocol documentation.
- validator token: verify this field, object, or component against the cited protocol documentation.
- peer network: 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.
| Dimension | Stock server | Validator |
|---|---|---|
| Serves API data | Yes | Can, but exposure should be minimized |
| Follows consensus | Yes | Yes |
| Publishes validations | No | Yes |
| Validator key required | No | Yes |
Practical example and checks
An application backend can run a stock server for trusted API access without voting, while a separately hardened host runs validator duties with minimal exposed services.
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
Running a validator is not required to use XRPL or verify ledgers. Adding validator mode creates key-management and uptime responsibilities without fee revenue.
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.