This guide covers essential best practices for running a Shibarium PoS validator node, including wallet management, operating system security, networking, backup, migration, and monitoring. Following these practices will help you maintain a secure and reliable validator setup.

​
Owner and Signer Wallets

The signer wallet is used for signing Heimdall blocks, checkpoints, and other signing-related activities. Its private key is stored on the validator node for signing purposes. It cannot manage staking, rewards, or delegations.
  • Keep BONE tokens on Heimdall (via top-up transactions) to perform validator responsibilities.
  • Keep ETH on Ethereum to send checkpoints on Ethereum.
The owner wallet is used for staking, re-staking, changing the signer key, withdrawing rewards, and managing delegation parameters on Ethereum.
The private key for the owner wallet MUST be kept secure. All transactions through this key happen on the Ethereum chain.
Take all precautions to safely generate and store wallet keys. Do not expose key details to anyone who does not require them.

​
Wallet Setup and Maintenance

  • Use a secrets manager or password manager for key management.
  • Refer to OWASP’s key management cheat sheet.
  • Hardware wallets add security, but are not foolproof.
  • Rotate keys at least once a year, or immediately if compromised.
  • Research and choose the best method for your needs.

​
Operating System Security

  • Keep your system up to date using your OS package manager (e.g., yum, apt, brew, pacman).
  • NEVER run unnecessary software on your node. Limit services to only Bor, Heimdall, and RabbitMQ.
  • Run single-purpose nodes. Do not use your validator as a public RPC endpoint.
  • Limit access to your validator node to as few people as possible. Restrict SSH access.
  • Use individual accounts with sudo, disable root login, and use SSH keys (not passwords).
  • Add brute-force protection (e.g., Fail2Ban) and 2FA for SSH.

​
Networking

  • Do not expose any ports publicly for your validator node. Use a sentry/full node with port 30303 (Bor) and 26656 (Heimdall) available publicly.
  • Configure your validator as a static node in Bor’s config.toml and as a seed/persistent peer in Heimdall config.
  • Isolate your validator from the public internet; only allow connections from your sentry node.
  • Use cloud provider tools (VPC, Security Groups) to restrict access.
A validator node should never have any ports reachable by the public internet.
Be careful with UFW and Docker: Docker can bypass UFW rules by opening mapped ports. Review your firewall and container settings.

​
Validator Backup

A validator backup playbook is available from the node-ansible repo. This tool lets you back up your validator configuration for migration or recovery. 
ansible-playbook -i $inventory playbooks/validator-backup.yml -e "destination=$WHERE_YOU_WANT_TO_SAVE_LOCALLY bor_path=PATH_TO_YOUR_BOR_INSTALL heimdall_path=PATH_TO_YOUR_HEIMDALL_PATH"
  • Define destination, bor_path, and heimdall_path.
  • The playbook creates a tarball in your specified directory.

​
Host Migration

To migrate a host, create a snapshot of your Bor and Heimdall chain data: 
ansible-playbook -i $inventory playbooks/bor/snapshot-create -e "chaindata=$path target=$target_save_dir"
ansible-playbook -i $inventory playbooks/heimdall/snapshot-create -e "data=$path target=$target_save_dir"
  • Ensure enough disk space for the tarball.
  • Copy the tarball to your new host as needed.

​
Monitoring and Observability

Monitor your validator node for:
  • Bor and Heimdall service status
  • Chain sync status
  • Inbound traffic (RPC calls to sentry)
  • Disk, memory, and network usage
Use tools like Coralogix, Datadog, Splunk, or Nagios for monitoring and alerting. Fine-tune your alerts to balance signal and noise.