security policy
liveThreat model, what we hold, what we don't, anchor posture, disclosure process. Updated whenever the surface changes.
open →§ trust
The page your compliance team is going to ask for.
Security policy, public charter, operational status, SOC 2 progress, GDPR posture, sub-processor list — aggregated. Most enterprise security questionnaires can be answered from links on this page. If yours can't, the form below routes to the security inbox directly.
public charter
liveEight load-bearing commitments — no token, no custody, protocol stays open, audit verifies without us. Versioned in git.
open →operational status
liveReal-time managed-infrastructure state. Component-level. Honest about pre-production with design partners.
open →soc 2 type 1
in progressTargeted before general-availability launch. Enterprise tier customers receive the report and continuous-compliance attestation.
soc 2 type 2
plannedFollows Type 1 by approximately 12 months of observation. Plumbing for evidence collection lands in v1.2.
gdpr posture
liveEU operators sign a DPA on Pro / Enterprise. Personal data is minimal (operator email, billing address); audit-bundle contents are content-addressed hashes by default.
sub-processors
liveStripe (USD billing) · BTCPay Server self-hosted (Lightning) · Resend (contact form) · Vercel (hosting) · public Nostr relays + OpenTimestamps calendars (envelope publication / anchoring — see security policy).
§ data residency
us-iad-1 today · region pin available on enterprise.
Console is deployed to Vercel iad1 (US-East). Enterprise customers can pin to an EU region or a self-hosted deployment. The audit-bundle export is region-agnostic — it's content-addressed and verifies offline against Bitcoin headers.
§ retention
audit forever · operational logs 90 days.
Audit envelopes are durable on Nostr + Bitcoin and never expire — the protocol is the storage. Console-side operational logs (rate-limit data, abuse signals, billing events) retain 90 days. Enterprise customers can request shorter or longer retention windows.
§ cross-site auth posture
One session across the whole family.
The auth host is ochk.io. It issues an Ed25519-signed oc_session JWT cookie with Domain=.ochk.io, HttpOnly, SameSite=Lax. Every consumer subsite (console.ochk.io, attest.ochk.io, lock.ochk.io, vote.ochk.io, stamp.ochk.io, agent.ochk.io, pledge.ochk.io, docs.ochk.io) sees the same cookie automatically and verifies it locally against the public JWK published at ochk.io/.well-known/jwks.json.
What this means: sign in once (BIP-322 wallet signature on ochk.io) and you're signed in everywhere. The session principal is the Bitcoin address — not an email, not a service account.
What this does not require: a database on any consumer site, an API call back to the auth host on every page load, or sticky session affinity in our load balancer. The cookie carries a signed JWT; verification is a pure function of (cookie, published JWK).
Hybrid auth. The current method is BIP-322 (single signer). v1.2 adds federation/Fedimint quorum signing as an additional method (see /federation). Future methods (email magic-link, OIDC corporate SSO with BIP-322 binding) plug into the auth host without breaking any consumer site's integration — the contract is “return a signed JWT naming a Bitcoin-address principal.” New methods improve the sign-in UX; the cryptographic binding to the on-chain address stays the source of truth.
§ security questionnaire
Send the questionnaire to the right inbox.
Most fields are answerable from this page, /security, /charter, and /status. If yours has fields ours doesn't cover yet, ship them to security@ochk.io — we triage same-business-day and update this page when patterns recur.