Skip to main content

Sentry Node Architecture

Sentry nodes act as a protective shield between your validator and the public network. This guide covers why they matter, how to deploy them, and how to configure everything correctly.

Why Sentries​

Validators are high-value targets. They hold staked tokens, sign blocks, and can be slashed for downtime. If a validator's IP address is known to the public network, it can be targeted with DDoS attacks. A sustained attack causes the validator to miss blocks, which leads to jailing and slashing penalties.

Sentry nodes solve this by acting as intermediaries:

  • Sentry nodes connect to the public P2P network and relay blocks and transactions
  • The validator connects only to its own sentry nodes over a private network
  • The validator's IP address is never exposed to the public network

If a sentry is attacked, the other sentries continue relaying. If all sentries go down simultaneously, the validator loses its peers and stops signing -- but it is not tombstoned, and it can resume once connectivity is restored.

Validators Without Sentries

Running a validator directly on the public network exposes it to targeted attacks. Any peer in the network can see the validator's IP via the P2P address book. For production validators, sentry architecture is strongly recommended.

Architecture Overview​

                    ┌──────────────┐
                    │    Public    │
                    │   Network   │
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
       ┌────▼─────┐  ┌────▼─────┐  ┌─────▼────┐
       │ Sentry 1 │  │ Sentry 2 │  │ Sentry 3 │
       │ (Public) │  │ (Public) │  │ (Public)  │
       │ Region A │  │ Region B │  │ Region C  │
       └────┬─────┘  └────┬─────┘  └─────┬────┘
            │              │              │
            └──────────────┼──────────────┘
                           │
                    Private Network
                    (VPN / VLAN / VPC)
                           │
                    ┌──────▼───────┐
                    │  Validator   │
                    │  (Hidden)    │
                    │  No public   │
                    │  connectivity│
                    └──────────────┘

Key points:

  • Sentries are full nodes that participate in the public P2P network normally
  • The validator communicates only with its sentries via a private network link
  • Sentries know the validator's node ID but mark it as a private peer, so they never gossip its address to other nodes
  • The validator has PEX (peer exchange) disabled -- it does not discover or connect to any peers on its own

Deployment Steps​

Step 1: Deploy Sentry Nodes​

Provision 2-3 sentry nodes in different providers or regions for redundancy. Each sentry is a standard full node.

# On each sentry server
# Install monod and monarch (see Installation guide)
monarch join --network Testnet --home /home/monod/.mono

# Start and let it sync fully before proceeding
monarch start
monarch status
# Wait until catching_up = false

Record each sentry's node ID and IP address:

# Get the sentry's node ID
monod tendermint show-node-id --home /home/monod/.mono
# Example output: a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

Step 2: Configure Sentry Nodes​

Edit ~/.mono/config/config.toml on each sentry:

# Enable peer exchange -- sentries participate in public P2P
pex = true

# Connect to the validator over the private network
persistent_peers = "<validator-node-id>@<validator-private-ip>:26656"

# CRITICAL: Never gossip the validator's address to other peers
private_peer_ids = "<validator-node-id>"
SettingValuePurpose
pextrueSentries discover and connect to public peers normally
persistent_peersValidator's private addressMaintains a permanent connection to the validator
private_peer_idsValidator's node IDPrevents the sentry from sharing the validator's address with any other peer

Step 3: Configure the Validator​

Edit ~/.mono/config/config.toml on the validator:

# Disable peer exchange -- validator must NOT discover public peers
pex = false

# Connect ONLY to your own sentry nodes
persistent_peers = "<sentry1-id>@<sentry1-private-ip>:26656,<sentry2-id>@<sentry2-private-ip>:26656,<sentry3-id>@<sentry3-private-ip>:26656"

# Required when pex=false to allow private network addresses
addr_book_strict = false
SettingValuePurpose
pexfalseValidator does not discover or connect to any peers on its own
persistent_peersSentry private addressesThe validator's only connections are its sentries
addr_book_strictfalseAllows connections to private/LAN IP addresses (required for private network links)
PEX Must Be Disabled on the Validator

If pex = true on the validator, it will discover and connect to public peers, defeating the entire purpose of the sentry architecture. The validator's connections must be limited exclusively to its sentry nodes.

Step 4: Firewall Rules for Sentries​

Sentries face the public internet and must accept P2P connections from any peer:

# On each sentry server
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH (restrict to admin IPs in production)'
sudo ufw allow 26656/tcp comment 'P2P - public'
# Do NOT expose RPC (26657), REST (1317), or EVM (8545) unless serving public queries
sudo ufw enable

For tighter SSH access, restrict to your admin IP:

sudo ufw delete allow 22/tcp
sudo ufw allow from <your-admin-ip> to any port 22 proto tcp comment 'SSH - admin only'

Step 5: Firewall Rules for the Validator​

The validator must only accept connections from its sentry nodes:

# On the validator server
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH from admin IP only
sudo ufw allow from <your-admin-ip> to any port 22 proto tcp comment 'SSH - admin only'

# Allow P2P ONLY from sentry nodes
sudo ufw allow from <sentry1-ip> to any port 26656 proto tcp comment 'P2P - sentry 1'
sudo ufw allow from <sentry2-ip> to any port 26656 proto tcp comment 'P2P - sentry 2'
sudo ufw allow from <sentry3-ip> to any port 26656 proto tcp comment 'P2P - sentry 3'

# Deny everything else (default)
sudo ufw enable
Monarch Firewall Helper

monarch firewall generates appropriate UFW rules based on the node's role. It detects whether the node is a validator or sentry and outputs the correct rules.

Step 6: Restart All Nodes​

Apply the configuration changes:

# On the validator
monarch restart
# Or: sudo systemctl restart monod

# On each sentry
monarch restart

Verify connectivity:

# On the validator -- should show exactly 2-3 peers (your sentries)
monarch status
# Or: curl -s localhost:26657/net_info | jq '.result.n_peers'

# On each sentry -- should show many public peers plus the validator
monarch status

Monarch CLI Support​

Monarch provides commands to simplify sentry configuration:

# Configure a node as a sentry (sets pex=true, adds validator as private peer)
monarch join --sentry --validator-id <validator-node-id> --validator-addr <private-ip>:26656

# Generate firewall rules for the current node role
monarch firewall
# Output varies based on whether the node is a validator or sentry

Multi-Provider Setup​

Spreading sentries across multiple infrastructure providers protects against provider-level outages. If all your sentries are at a single provider and that provider has a network issue, your validator loses all peers.

Recommended distribution:

SentryProviderRegionPurpose
Sentry 1HetznerEU (Falkenstein)Primary
Sentry 2OVHEU (Gravelines)Redundancy
Sentry 3AWS / DigitalOceanUS EastGeographic diversity

Connectivity between sentries and the validator:

  • Use a VPN (WireGuard recommended) or private VLAN to connect sentries to the validator
  • WireGuard adds minimal latency (~1-2ms) and encrypts all traffic
  • If sentries and validator are at the same provider, use the provider's private networking (VPC)

Monitoring Sentries​

Sentry monitoring differs from validator monitoring. Sentries are expendable individually -- what matters is that at least one sentry maintains connectivity to both the validator and the public network.

What to Monitor​

MetricSentryValidatorWhy
Block heightYesYesDetect stalls on either side
Peer countYes (expect 10-50)Yes (expect 2-3, exactly your sentries)Validator peer count outside expected range means misconfiguration
Connectivity to validatorYes--If a sentry loses its validator peer, it is not relaying blocks to the validator
Missed blocks--YesDirect indicator of signing problems
CPU / Memory / DiskYesYesStandard resource monitoring
Network bandwidthYes (higher)Yes (lower)Sentries handle more traffic; unexpected spikes may indicate an attack

Health Check Commands​

# On a sentry: verify connection to validator
curl -s localhost:26657/net_info | jq '.result.peers[] | {node_id: .node_info.id, remote_ip: .remote_ip}'
# The validator's node ID should appear in the list

# On the validator: verify connections to sentries
curl -s localhost:26657/net_info | jq '.result.n_peers'
# Should equal the number of sentries (2-3)

Set up alerts for:

  • Sentry peer count dropping below 3 (indicates network isolation)
  • Validator peer count not matching sentry count (indicates broken sentry link)
  • Any sentry falling more than 10 blocks behind the network

FAQ​

How many sentries do I need?​

Minimum 2 for redundancy. 3 is recommended for production validators. If one sentry goes down for maintenance or is under attack, the other two maintain validator connectivity. Beyond 3, the operational overhead increases with diminishing returns.

Can sentries be pruned nodes?​

Yes. Sentries do not need full chain history. Running them as pruned nodes saves disk space and reduces sync time. Only the validator or dedicated archive nodes need to retain full history.

# In app.toml on sentries
pruning = "default"

What if all sentries go down?​

The validator loses its peers, stops receiving new blocks, and stops signing. After the downtime threshold (network-specific), the validator is jailed for downtime. It is not tombstoned -- you can unjail it once connectivity is restored.

# After restoring sentry connectivity
monarch unjail --from <your-key>

This is why geographic and provider diversity matters. The probability of all sentries failing simultaneously decreases with each independent provider you add.

Do sentries need the validator key?​

No. Sentries are standard full nodes. They do not have priv_validator_key.json and do not sign blocks. They only relay blocks and transactions between the public network and the validator.

Never Copy Validator Keys to Sentries

Placing priv_validator_key.json on a sentry node serves no purpose and creates a serious security risk. If the sentry is compromised, the attacker could use the key to double-sign.

Can I add or remove sentries without downtime?​

Yes. To add a new sentry, deploy it, sync it, configure its persistent_peers and private_peer_ids, then add its address to the validator's persistent_peers and restart the validator. To remove a sentry, remove its address from the validator's persistent_peers and restart. The validator will continue signing as long as at least one sentry is connected.

Should sentries expose RPC or API endpoints?​

Only if you need to serve public queries. If you do, expose them on the sentries, never on the validator. Use a reverse proxy with rate limiting for public-facing endpoints.