DotOne Docs

Secure Validator ​

Each DotOne validator is encouraged to run its operations independently. Diverse infrastructure setups across the validator set increase the overall resilience of the network. Given the capital and responsibility involved in operating a validator, protecting your node against DoS and DDoS attacks is not optional — it is a core operational requirement.

Sentry Node Architecture (DDoS Protection) ​

The most effective way to protect your validator from direct network attacks is to deploy a sentry node architecture. In this setup, your validator node is never exposed directly to the public internet. Instead, one or more sentry nodes — standard DotOne full nodes — act as intermediaries between your validator and the broader P2P network.

Key properties of this architecture:

  • Sentry nodes operate in private IP space, shielding the validator from direct exposure
  • Sentry nodes can be redeployed quickly and have their IP addresses rotated if targeted
  • Block proposals and votes from your validator reach the network reliably through the sentry layer
  • Your validator's identity and location remain hidden from public peers

Step 1 — Set Up Your Nodes ​

Establish a private network containing your validator node and one or more sentry nodes. Follow the full node setup guide to deploy each node.

Configure trusted connections exclusively between your validator and its sentry nodes.

⚠️ Never expose your validator's RPC endpoints to the public network under any circumstances.

Step 2 — Add Sentry Nodes as Static Peers ​

Connect to each sentry node's console and run the following command to retrieve its enode information:

js
admin.nodeInfo.enode

This returns an enode URL in the following format:

enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f1
6fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[::]:30306?discport=0

Note: [::] represents the localhost address 127.0.0.1. If your sentry nodes are within a local network, find the correct IP using ifconfig on each host. If your sentry nodes are on external servers, use their public IP address in the enode URL.

Replace [::] with the correct IP address, then add the enode entries to your validator node's config.toml:

toml
# Hide validator from public discovery
NoDiscovery = true

# Connect exclusively to sentry nodes
StaticNodes = [
  "enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306",
  "enode://{sentry-node-2-enode}@[10.1.1.2]:30306"
]

Setting NoDiscovery = true ensures your validator does not advertise itself to the public P2P network and only communicates through the explicitly defined sentry nodes.

Step 3 — Confirm Connections ​

Connect to your validator node's console and verify that the sentry node connections are active:

js
admin.peers

You should see the details of each configured sentry node in the output. If a sentry node does not appear, check the enode URL, IP address, and port configuration.

Firewall Configuration ​

Proper firewall rules are essential to prevent unauthorised access to your validator node. The DotOne geth client uses several ports for different functions:

PortProtocolPurposeRecommended Action
30303TCP + UDPP2P listener and discoveryOpen — required for network participation
8545TCPJSON-RPC APIBlock externally — never expose to the public
8546TCPWebSocket APIBlock externally — internal use only

Rules to enforce:

  • Allow inbound and outbound traffic on port 30303 for P2P connectivity
  • Block all external access to port 8545 and 8546 at the firewall level
  • If operating in sentry node mode, restrict P2P access on the validator to only the IP addresses of your sentry nodes
  • Disable the HTTP module entirely if it is not required for your setup

Security Checklist ​

Before going live on mainnet, verify the following:

  • The validator node is not directly reachable from the public internet
  • Sentry nodes are deployed and confirmed as active peers
  • NoDiscovery = true is set in the validator config.toml
  • RPC ports (8545, 8546) are blocked at the firewall level
  • Keystore files are backed up securely and offline
  • BLS and consensus key passwords are stored safely, not in plaintext on the server
  • Monitoring and alerting are active for uptime and slash count
  • A backup validator node is provisioned and ready

General Security Practices ​

Beyond the sentry architecture and firewall configuration, the following practices are strongly recommended:

Key Management Store your consensus and BLS private keys on encrypted volumes. Never transmit key files over unencrypted channels. Consider using hardware security modules (HSMs) for production deployments.

Access Control: Restrict SSH access to your validator and Sentry nodes using key-based authentication only. Disable password-based login. Limit access to a minimal set of trusted operators.

Software Hygiene: Keep your node binary, operating system, and dependencies up to date. Subscribe to DotOne release announcements and apply security patches promptly.

Incident Response: Have a documented process for responding to node failures, suspected key compromise, and unexpected slashing events. Know how to execute an emergency shutdown and unjail your validator when needed.