Terp Docs
GuidesNetwork opsValidators

Sentry array (oline)

Protect a Terp validator with a sentry node array — topology, config.toml knobs, and oline-style multi-sentry ops

Sentry array (oline)

Sentries are full nodes that shield the validator’s P2P identity. The rest of the network peers with sentries; the validator only talks to those sentries. This is the standard pattern for DoS resistance — including multi-region oline deployments (Akash / multi-provider arrays).

  Network peers  ←→  Sentry A  ──┐
  Network peers  ←→  Sentry B  ──┼──  Validator (pex=false, private)
  Network peers  ←→  Sentry C  ──┘

Why sentries

Risk without sentriesMitigation
Validator IP public on P2POnly sentry IPs are advertised
DoS on validator hostAttack hits disposable sentries; redeploy quickly
Jail from downtimeRedundant sentries across DCs keep the signer fed

Minimum: two sentries. Prefer different datacenters / providers. One sentry may share a private network with the validator for low latency.

oline

“Oline sentry array” here means the same topology operated as a managed multi-node layout (snapshot nodes, sentries, signer) — configs below apply whether you provision by hand, Docker, or oline/Akash SDLs.

Prerequisites

1. Bootstrap each sentry like a full node

On every sentry (example mainnet morocco-1; use 90u-4 for testnet):

terpd init "sentry-a" --chain-id morocco-1
# genesis
curl -Ls https://s3.terp.network/snapshots/mainnet/morocco-1/genesis.json \
  > $HOME/.terpd/config/genesis.json
# or network repo genesis — verify checksum when possible

Sync with state sync or bootstrap. Sentries do not run create-validator.

systemd (each sentry):

sudo tee /etc/systemd/system/terpd.service > /dev/null <<EOF
[Unit]
Description=terpd sentry
After=network-online.target
[Service]
User=$USER
ExecStart=$(which terpd) start
Restart=always
RestartSec=3
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now terpd

2. Sentry config.toml knobs

On each sentry:

SettingValue
persistent_peersPublic seeds/peers plus other sentries
private_peer_idsValidator node ID (never gossip it)
unconditional_peer_idsValidator ID (+ peer sentry IDs recommended)
# Validator node id (run on validator host)
terpd tendermint show-node-id
# sentry config.toml (illustrative)
private_peer_ids = "<VALIDATOR_NODE_ID>"
unconditional_peer_ids = "<VALIDATOR_NODE_ID>,<OTHER_SENTRY_NODE_ID>"

Peers for public discovery — use current sources from public endpoints / operator peer lists (URLs change; verify before production).

3. Validator config.toml knobs

On the validator only:

SettingValue
persistent_peersOnly sentry node IDs (host:port)
pexfalse
addr_book_strictfalse if using private RFC1918 links to a co-located sentry
pex = false
persistent_peers = "<sentryA_id>@<sentryA_ip>:26656,<sentryB_id>@<sentryB_ip>:26656"

If the validator was previously public:

# node stopped
rm -f $HOME/.terpd/config/addrbook.json

Confirm only sentries remain:

curl -s localhost:26657/net_info | jq '.result.n_peers, [.result.peers[].node_info.id]'

4. Firewall

  • Validator P2P 26656: allow only sentry IPs (ufw / security group / provider ACL).
  • Sentries: P2P open to the network; RPC preferably private or firewalled.
  • Never expose validator RPC/gRPC publicly if avoidable.

5. oline / multi-provider notes

PracticeWhy
Snapshot or state-sync sentries firstValidator should not fall behind while wiring private peers
Separate providers for ≥1 sentryDC / network failure isolation
Automate binary + genesis via your deploy pathSame install + integrity checks
Monitor sentry lag + peer countMonitoring

Akash / deploy references: Deploy on Akash, resources ecosystem.

Checklist

  1. ≥2 sentries synced
  2. private_peer_ids + unconditional_peer_ids set on sentries
  3. Validator pex = false, peers = sentries only
  4. Firewall locks validator P2P to sentry IPs
  5. net_info shows expected peer count
  6. Prometheus/Grafana on validator (and ideally sentries)

On this page