Security Policies

Validator security is the core of what POSTHUMAN does. This page documents the commitments and practices we apply across our infrastructure — the same ones we rely on to keep our delegators' stake intact and the networks we validate honest.

1. Slashing Protection

All POSTHUMAN validators run with strict double-sign protection:

• per-chain key isolation — no signing key is reused across networks;
• persistent slashing state stored on dedicated, replicated storage;
• active monitoring for malformed proposals before they're broadcast;
• fail-stop on key conflicts — the validator halts rather than risk a double-sign.

Our advertised 125% slashing refund applies to slashing events caused by validator-side faults (downtime above network thresholds, double-sign). Reimbursement is paid out from POSTHUMAN's operational treasury within a reasonable window after on-chain confirmation of the event.

2. Key Custody

Validator consensus keys are stored in hardware security modules (HSMs) or encrypted key-management systems with strict access controls. No single operator can extract a signing key. Cold storage is used for treasury and self-bond addresses; only operationally necessary balances are kept on hot keys.

3. Infrastructure

• Sentry / sentinel architecture — public RPC and peer endpoints run on separate machines from the consensus signer. Validators are not exposed to the public Internet directly.
• Geographic redundancy — primary and standby nodes operate in different data centres so a single regional outage does not bring a validator offline.
• Monitoring + paging — node health, peer count, missed-block counters, signing latency and resource pressure are watched 24/7. On-call pages are routed through redundant channels.
• Patching cadence — chain upgrades and security patches are applied within the timelines published by each chain's coordination channel. We maintain test-net deployments to validate changes before mainnet.

4. Site & Application Security

• Static-only hosting — posthuman.digital is served as static assets from Cloudflare Pages. There is no application server to compromise.
• Edge functions — the only dynamic surface is /api/subscribe, a Cloudflare Pages Function backed by a single D1 binding. Input is validated (email regex, length cap, source allowlist) and a honeypot field rejects automated submissions.
• HTTPS everywhere — TLS terminates at Cloudflare, with HTTP strictly redirecting to HTTPS. We do not host an unencrypted endpoint.
• No third-party scripts — no analytics, ads, or social-tracking embeds run on the Site.

5. Incident Response

For validator incidents (slashing, downtime, missed upgrade), our process is:

1. halt the affected validator and confirm the on-chain state;
2. communicate to delegators within hours via Telegram, Twitter and the newsletter;
3. publish a post-mortem on the blog within one week, covering root cause and remediation;
4. process slashing-refund claims (where applicable per the Terms).

For Site incidents (data breach, defacement, downtime affecting the newsletter or blog), we follow the same disclose-then-fix cadence.

6. Responsible Disclosure

If you believe you have found a vulnerability in any POSTHUMAN-operated infrastructure (this Site, the validator nodes, the explorer, public RPC endpoints, the claim app), please report it privately to validator@posthuman.digital before public disclosure.

We commit to:

• acknowledge your report within 72 hours;
• keep you informed during triage and remediation;
• credit you publicly (with your consent) once the issue is resolved;
• not pursue legal action against good-faith security researchers.

Out of scope: denial-of-service attacks, social engineering, attacks against third-party services we link to but do not operate.

7. Changes

We may revise these policies as our infrastructure or the threat landscape changes. The "Last updated" date at the top reflects the most recent revision.

8. Contact

Security enquiries: validator@posthuman.digital.