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:
Check the status of our validator at:
About our validator:
- Our validator is included in the default UNL that ships with
- We are not affiliated with Ripple.
- We have a strong track record of reliability, availability, and
- We are trusted by major entities, including Ripple and Coil.
- We provide clear contact
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
- 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
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
updates, and we only run unmodified versions of the rippled
- 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
- 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
- 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
- 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
- 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.