The Rabbit Kick Club

XRP Ledger Validator

The Rabbit Kick Club runs a validating node for the XRP Ledger. Our node is included in Ripple's recommended list (UNL). Our public validation key is:

nHUcNC5ni7XjVYfCMe38Rm3KQaq27jw7wJpcUYdo4miWwpNePRTw

Check the status of our validator at:

• bithomp.com/validators
• xrplstats.com/validators
• peerisland.com/validators
• minivalist.cinn.app/validators
• xrpscan.com/validators
• xrpcharts.ripple.com/#/validators

About our validator:

• Our validator is included in the default UNL that ships with rippled.
• We are not affiliated with Ripple.
• We have a strong track record of reliability, availability, and agreement.
• We are trusted by major entities, including Ripple and Coil.
• We provide clear contact points, and we publicly respond to questions regarding our validating node.
• Security and availability are top priorities. Over the last several months, our nodes have only been offline briefly following scheduled updates and intermittently when our data center experienced intermittent network issues for a few days.
• We never use our validator to test different configurations, and we announce updates and scheduled outages via Twitter.
• We use custom scripts to monitor our nodes, including monitoring our validating node for state changes. Our monitoring scripts notify us via mobile messages and email when a node goes offline or changes state or if our validator misses a ledger.
• Our validator runs on a dedicated server in a data center near Strasbourg France (We are located in the United States).
• Our validating node only allows outgoing connections (all ports are firewalled) and it has the peer protocol disabled.
• Our validating node only connects to a stock node that we operate and to a small number of highly trusted nodes and hubs. This provides DoS protection for our validating node by restricting public access to the validator, while ensuring the validator won't lose connectivity when stock nodes are updated or experience outages.
• We use multiple intrusion prevention and detection measures including firewalls with granular ingress/egress rules, selinux, and file monitoring. We take extra steps to harden SSH and other software running on our nodes, and we use keys instead of passwords whenever possible. We limit the software that runs on our rippled nodes to the bare minimum that is required for the nodes to function. We never host other services (web server, email server, etc.) on our rippled nodes.
• SSH and rippled websocket connections to our nodes are tunneled through an encrypted VPN that uses key based authentication. Our rippled servers connect to our VPN server via an outgoing connection, which allows us to block all incoming connections on public IP addresses.
• We regularly install rippled, software, and operating system/kernel updates, and we only run unmodified versions of the rippled software.
• We take credit for and provide information about our validator via our xrp-ledger.toml and ripple.txt files as well as a '_xrpl' DNS TXT record.

What XRP Ledger Validating Nodes Do We Trust?

Right now we only trust validating nodes on Ripple's recommended UNL.

Trust between validating nodes is integral to the XRP Ledger. In some ways, trust is what distinguishes running validating vs non-validating nodes. However, trust is subjectively defined. We consider the following criteria when determining the extent to which a validator is 'trustworthy'.

• High availability and uptime (strive for 100%).
  • All nodes must be monitored with alerts being sent to operators in the event of a disruption. Node operators must have a plan to remedy a disruption in less than one hour.
• High agreement with other validating nodes, which requires sufficient memory (32 GB DDR 4 or better) as well as a SSD/NVMe disk drive with high IOPS.
  • Refrain from using production validators to test configuration changes, as this requires restarting rippled (i.e., it causes downtime).
• Validating nodes must be clustered behind at least two stock (non-validating) nodes. Any node to which a validator connects should be controlled by the validator operator or by a highly trusted third party with whom the validator operator has a direct relationship.
• Validators should have 'peer_private' enabled (set to "1").
• Validators must be hosted in a data center with redundant infrastructure and strong physical security.
• Validating nodes must run on bare metal or dedicated servers. Colocated servers are preferred to leased bare metal/dedicated.
• Basic security including hardware and/or software firewalls, SELinux (OS dependent), and restricted physical access. Additional advanced security practices must be implemented to secure the validation public key.
  • There is no reason/need for validators to enable the peer protocol, and validators should not allow incoming connections on 51235 (or any port, for that matter).
• rippled nodes must not be used to host other service.
  • Do not run httpd, Nginx, Apache, or other web servers on validating nodes.
  • There is no need to install a valid SSL/TLS certificate on a rippled node. Use a webserver on a separate machine for Ripple's domain verficiation.
  • If you require a valid SSL/TLS certificate (i.e., you allow public websocket connections, consider using Nginx (or similar) as a websocket proxy, so you do not need to install or update valid SSL/TLS certs on the rippled server.
• All nodes should be evaluated for security threats and vulnerabilities.
• All nodes must install operating system and software updates within 30 days of them becoming publicly available.
  • The only exception to the above update clause is in the event that a suspicious or malicious version is released.
• Node operator(s) must have a backup plan for their rippled.cfg, rippled.txt, and wallets.db files. Backups must be encrypted and stored at diverse geographic locations, with some copies being easily accessible in an emergency.
• Nodes should be operated by parties who are unlikely to collude with one another and who are in diverse geographic locations and legal jurisdictions.