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:
- We are not affiliated with Ripple.
- We have a strong track record of reliability, availability, and
- We are trusted by major entities, including Ripple.
- 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. 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 whenever a node goes
offline or changes state.
- Our validator is hosted in a
secure commercial data center near Chicago, Illinois in the United States. Our
hosting provider offers a 100% uptime guarantee, contingent on network
- Our validating node runs on a bare metal server with 32GB of
memory and a solid state drive.
- We always have at least one stock nodes running on
a dedicated bare metal server, also with 32 GB of memory.
- Our validator is clustered with multiple non-validating (stock) nodes that we
control. This provides DoS protection for our
validating node by restricting public access to the validating
server while also allowing us to update the stock nodes without
disrupting the validating node. Similarly, if one of our stock nodes
experiences an unexpected outage, our validating node is not impacted.
- We use multiple intrusion prevention and detection measures
with granular ingress/egress rules 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 publicly routable IP addresses. The only permitted
incoming connections on any of our nodes are:
1. Incoming on our stock nodes from our validating node.
2. One stock node allows public incoming rippled peer protocol
- We regularly install rippled, software, and operating system
updates, and we only run unmodified versions of the rippled
- We take credit for and provide information about our validator
via our ripple.txt
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. The
following criteria are some that we consider in our definition of
- 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).
- Validating nodes must be clustered behind at least one stock
(non-validating) node. Validators clustered behind multiple stock
nodes are preferred.
- Nodes must be hosted in a data center with redundant infrastructure and
strong physical security.
- Validating nodes must run on bare metal servers. Colocated
servers are preferred to leased bare metal.
- 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.
- rippled nodes must not be used to host other web services.
- 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.