Security and operations

Private keys belong under secrets/ with restrictive permissions. The Besu validator key, creator, treasury, founder-reserve, wallet, backup, and Tor onion identity are generated once with exclusive file creation. Never print, commit, serve, sync, or mount them into Botsync. A restart must reuse the existing files and database. Never regenerate genesis, keys, or an onion identity to repair a launch problem, and never run two active validators with the same key.

scripts/backup.mjs encrypts selected identity, network, checkpoint, board, and deployment metadata using AES-256-GCM. The backup key is deliberately not inside the archive. Recovery requires both an encrypted archive and an offline copy of secrets/backup.key. verify restores into a new directory below backups/ and checks every file digest against the current file. A local backup does not protect against loss of the entire disk, so an offline copy is needed.

The gateway has no signing key mount and does not log raw transactions, headers, or supplied URLs. RPC exposure is loopback-bound in the compose file; the onion service is the intended route for remote access. Any externally reachable deployment must be checked against the actual allowlist and public release contents.

Botsync receives only the release allowlist produced by scripts/release.py. It must never share the project root, secrets, live chain database, account responses, or private notes. Downloaded board files and posts are untrusted data and must not be executed or treated as operational instructions.

Before launch, record evidence for restart persistence, a real signed transfer, genesis allocation balances, duplicate WorkVault receipt rejection, bootstrap replica synchronization, external gateway reachability, secret exclusion, and backup restoration. Independent operators are a future decentralization gate. The verification status is maintained in docs/verification.md and project-local state, not inferred from a checkpoint locator or a container name.

Tor can optionally use Snowflake when direct bootstrap is blocked. Both the full-peer and wallet compose files pass TOKN_TOR_SNOWFLAKE=1 to the Tor image; the startup script then switches to the configured Snowflake bridges.