Running a validator

A validator is not a different program. It is the same xrpld server with one extra setting switched on. Once on, the server signs a statement about each ledger it builds and shares it with the network.

Switching it on is the easy part. It uses little extra computing power. The hard part is that nobody has to listen.

Other servers count a validator's statements only if their operators chose to trust it. A brand new validator is trusted by no one. It still does useful work. Its statements are public, and they give everyone another point of comparison for the trusted validators.

Earning trust looks like building a reputation.

• Show up. Stay online and in agreement with the network, month after month.
• Be known. Link the validator to a website you own, so people can see who runs it.
• Be independent. Run one validator, not five. Extra validators from the same operator add no protection.
• Be somewhere else. A different data center and country from the crowd is a plus.

A validator has keys of its own. The important one, the master key, should never sit on the server. You create it on another machine, store it offline, and give the server a token made from it. If the server is broken into, you issue a new token from the master key. The master key itself was never on the server.

Validators also carry two extra duties: voting on amendments and voting on fee settings.

No reward is paid for any of this.

Enable validation.

1. Generate master keys with the validator-keys tool: validator-keys create_keys. This writes validator-keys.json. Store it offline, not on the validator.
2. Create a token: validator-keys create_token --keyfile /PATH/TO/validator-keys.json.
3. Paste the [validator_token] stanza into xrpld.cfg and restart.
4. Check server_info. pubkey_validator should match the public_key in the key file, and server_state should be proposing.

From xrpld 3.3.0 the packages install the tool at /usr/bin/validator-keys. Without the key file a token can never be renewed or rotated. If the secret key is compromised, the tool can revoke the master key.

A server once configured with [validation_seed] should drop that stanza. Doing so changes the validator's public key.

Network placement. Options in the docs: discovered peers, proxies or public hubs. With proxies, [peer_private] set to 1 tells peers not to broadcast the validator's IP address, and the validator connects only to the peers in [ips_fixed].

Server types. An all-purpose server validates and serves other uses. A dedicated validator does nothing else, possibly in a cluster with other xrpld servers. Validators must not share a key pair.

Domain verification. Serve an xrp-ledger.toml file at a domain you own and complete the verification steps. The link is two-way:

• The domain claims ownership of the validator key.
• The validator key claims ownership of the domain.

The domain should not resolve to the validator's IP address.

Trust. Sending validations gives no say in consensus by itself. Only validators on a server's UNL count for that server. Publishers of recommended lists typically want a year of high uptime and agreement, domain verification, a distinct operator and a distinct location. xrpl.org names https://vl.ripple.com and https://vl.xrplf.org as publishers.

Votes a validator casts.

• Amendments: the admin feature method, per amendment.
• Fees: reference_fee, account_reserve and owner_reserve in the [voting] stanza.

Health check. The admin validators method lists the published and trusted validators the server uses. validator_list_expires should not be expired.

Related: Validators and the UNL, The two-week vote.