> For the complete documentation index, see [llms.txt](https://docs.dotone.online/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dotone.online/secure-validator-or-dotone-smart-chain-docs.md).

# Secure Validator | Dotone Smart Chain Docs

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

{% stepper %}
{% step %}

### 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.

{% hint style="warning" %}
Never expose your validator's RPC endpoints to the public network under any circumstances.
{% endhint %}
{% endstep %}

{% step %}

### 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:

```bash
admin.nodeInfo.enode
```

This returns an enode URL in the following format:

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

{% hint style="info" %}
`[::]` 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.
{% endhint %}

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.
{% endstep %}

{% step %}

### Step 3 — Confirm Connections

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

```bash
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.
{% endstep %}
{% endstepper %}

## 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:

| Port  | Protocol  | Purpose                    | Recommended Action                                |
| ----- | --------- | -------------------------- | ------------------------------------------------- |
| 30303 | TCP + UDP | P2P listener and discovery | **Open** — required for network participation     |
| 8545  | TCP       | JSON-RPC API               | **Block externally** — never expose to the public |
| 8546  | TCP       | WebSocket API              | **Block 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dotone.online/secure-validator-or-dotone-smart-chain-docs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.