> For the complete documentation index, see [llms.txt](https://bitnet-whitepaper.gitbook.io/developer-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitnet-whitepaper.gitbook.io/developer-docs/security-essentials/security.md).

# Security

### Validator Security Guidelines for BitNet

BitNet encourages validators to adopt robust, decentralized setups to strengthen the security and resilience of the network. This section outlines best practices to help validators safeguard their infrastructure and protect against operational risks.

***

#### Key Security Principles

Running a secure validator on BitNet requires attention to:

* **Private key protection**
* **High availability architecture**
* **Double-signing prevention**
* **DDoS mitigation**
* **Reliable backups**

A secure launch not only protects the validator’s rewards and stake but also ensures the integrity of the BitNet network.

***

#### Horcrux: Distributed Key Signing

**Horcrux** is a multi-party computation (MPC)-based signing solution for Tendermint-based networks like BitNet. It enables:

* **High Availability (HA)** through distributed signer nodes
* **Secure key splitting** using Ed25519 threshold signatures
* **Redundant block signing** without performance tradeoffs

Validators can adopt Horcrux to enhance their infrastructure and avoid single points of failure.

***

#### Hardware Security Modules (HSMs)

Validators should use **Hardware Security Modules (HSMs)** to protect private keys from compromise. Popular HSMs supporting Ed25519 include:

* **YubiHSM 2**
* **Ledger Nano S / BOLOS SGX**
* **Thales nShield**

{% hint style="danger" %}
While HSMs protect private keys from theft, they **do not guarantee double-sign protection** without additional safeguards.
{% endhint %}

***

#### Tendermint KMS

**Tendermint KMS** is a secure signing service that integrates with HSMs and supports remote validation. Recommended for:

* Multi-zone validators
* Defense-in-depth infrastructure
* Secure key signing across cloud or hybrid deployments

***

#### Sentry Node Architecture (DDoS Defense)

To prevent DDoS attacks:

* Use **private validator nodes**
* Connect only to **trusted sentry nodes** running in cloud or secure environments
* Keep **sentry node IPs public**, but **validator IPs private**

This architecture shifts exposure to public attack surfaces while maintaining network integrity.

***

#### Backups and Key Recovery

To prevent total loss during disaster recovery:

1. **Back up** the validator’s private key:

   ```bash
   ~/.bitnetd/config/priv_validator_key.json
   ```
2. Back up your **wallet seed** or exported key file.
3. Store backups **offline** and in **geographically separate** locations.

***

#### Environment Variables and Security

Environment variables like `BITNET_CHAIN_ID` can override config settings. Best practices:

* Lock down environments with minimal variable exposure
* Use explicit command-line flags instead of relying on dynamic vars
* Prevent unauthorized modification of server `.bashrc`, `.profile`, or systemd units