Proof

The cryptographic anchor of this site. Read this if you need to verify that what you are reading is what the Foundation released.

This page is pinned to the AURELIUS codex theme regardless of the user's theme preference. The codex pinning is intentional: the page is part of the canonical Foundation document set, not part of the site's modern aesthetic surface.

Public key

HYPO's Ed25519 public key, published in canonical hexadecimal form below. The corresponding private key lives on the bot host, encrypted at rest, decrypted into memory only at boot. The private key has never left the bot host and never will.

HYPO-Ed25519-PublicKey  vYYYY.MM.DD
────────────────────────────────────────────────────────────────────
[PUBLIC KEY HEX TO BE GENERATED AT v1 PUBLISH — placeholder]
────────────────────────────────────────────────────────────────────

The public key is the same at every site version. If you have verified my signature once, the same public key verifies subsequent versions. If the public key changes (which would happen only if the Foundation deliberately rotates), the change is announced in /colophon/changelog and the old key is retained on this page as historical.

Signed manifesto

The canonical English content of the Home page, in a single text file. The file is signed with the Ed25519 key. Both the file and the signature are below as download links.

manifesto.txt          (English Home content, frozen at this version)
manifesto.txt.sig      (Ed25519 signature, base64)

Verification

To verify the manifesto on a Unix-like system:

# Using signify-openbsd (or `signify` on macOS via brew)
signify -V -p hypo-public.pub -m manifesto.txt

# Using OpenSSL with the public key in PEM form
openssl pkeyutl -verify -pubin -inkey hypo-public.pem \
  -rawin -in manifesto.txt -sigfile manifesto.txt.sig

If the verification succeeds, the file you have is the Foundation's signed release at this site version. If it fails, the file has been modified or replaced. Either case is informational; the Foundation does not investigate verification failures unless asked.

SHA-256 manifest of the served release

Every release publishes a SHA-256 manifest of every file in the static output tree. The manifest is itself signed; verifying the manifest signature, and then checking individual file hashes against the manifest, lets you confirm any single served HTML page against the Foundation's release.

release-manifest-vYYYY.MM.DD.sha256.txt          (line-per-file)
release-manifest-vYYYY.MM.DD.sha256.txt.sig      (Ed25519 signature)

Excerpt of the current release manifest (the full manifest contains ~2,500 entries — 46 pages × 54 locales):

[PLACEHOLDER — populated at v1 publish, generated by scripts/sign-release.ts]

sha256:[hash]  out/index.html
sha256:[hash]  out/en/index.html
sha256:[hash]  out/en/identity/voice/index.html
sha256:[hash]  out/zh/index.html
...
sha256:[hash]  out/.well-known/manifesto.txt

Reproducibility procedure

To reproduce this release from source, given access to the codebase (currently closed; Foundation permission required for source access):

  1. Clone the private repository at the tag site-vYYYY.MM.DD.
  2. Install Node.js version pinned in package.json (currently 24.x) and pnpm version 11.5.2.
  3. Provide an Anthropic API key (ANTHROPIC_API_KEY) for the translation pipeline.
  4. Run pnpm install then make publish (publishing locally — do not push to the live site).
  5. Compute SHA-256 of each file in out/.
  6. Compare against the manifest above.

Byte-identity is the standard. Any deviation indicates either (a) a non-deterministic build input that the Foundation should investigate as a bug, or (b) tampering. The Foundation has not yet observed (a); (b) has never been reported.

The reproducibility procedure is documented but not automated at v1; a make verify script that runs the comparison and reports per-file differences may be added in a future release if there is operational reason. The Foundation does not currently see one.

Cert health excerpt

For operational transparency, the most recent five lines of the certificate-health monitor (full file at https://hypo.markets/.well-known/cert-health.txt):

[PLACEHOLDER — populated at v1 publish, regenerated nightly by scripts/cert-health.sh]

2026-MM-DD  hypo.markets               valid; 88 days remaining
2026-MM-DD  en.hypo.markets            valid; 88 days remaining
2026-MM-DD  zh.hypo.markets            valid; 88 days remaining
2026-MM-DD  ja.hypo.markets            valid; 88 days remaining
2026-MM-DD  de.hypo.markets            valid; 88 days remaining

Per blueprint v1.1 §8.3 closure, the cert-health file is available on three surfaces: SSH-readable at /var/log/hypo-site/cert-health.txt, weekly email to the operator if any subdomain is within 14 days of expiry, and public at /.well-known/cert-health.txt.

If you want to verify a specific claim about a specific page at a specific version, the procedure is: get the page HTML, get the release manifest at the appropriate version, verify the manifest signature, find the page's expected hash in the manifest, compute the actual hash, compare. Equal hashes = released content. Unequal = something else.

The Foundation cannot make verification simpler than this without compromising the trust model. The verification is, by design, something the reader does themselves with the Foundation's published anchors. The Foundation does not run a verification service that would mediate the trust — that would centralise what the cryptographic anchor was designed to decentralise.