What we built.
What we proved. What we haven't yet.
Privacy infrastructure earns trust by being honest about its boundaries. This page is that disclosure: what protects you today, and what we still owe.
Four pillars that hold the rest up.
Multi-party trusted setup
Phase 1 uses the Hermez Network Powers of Tau ceremony (54 Ethereum-community participants). Phase 2 is run circuit-by-circuit with multiple contributors. As long as one contributor is honest and discards their entropy, the setup is sound.
Ceremony documentation →Mainnet verifiers, deployed
Groth16 verifiers live on three production chains. The verification key is on-chain and immutable; nobody — including us — can swap it without producing a new contract that the world can see.
See verifier addresses below →Published trust model
Every circuit is classified as Production, Self-Asserted, or Experimental. Integrators see exactly what each proof guarantees and what it does not. No hand-waving.
Read the trust model →Open source under MIT
Circuits, SDK, hosted verifier, and the on-chain programs are open source. Any engineer can audit the code, self-host the verifier, and reproduce the proofs.
Source on GitHub →Verifier contracts on mainnet.
The verification key for every supported circuit is anchored on three production chains. You can verify the same proof on any of them.
Security controls in production.
The hosted verifier and the public web app run under the controls below. Self-hosted deployments inherit the same code path; the policies are yours to configure.
Content Security Policy
Nonce-based, strict-dynamic. No unsafe-inline scripts. Per-request nonces forwarded via the x-nonce header.
Rate limiting
100 req/min per IP at the edge. Tighter caps on RPC proxy (30/min), AI endpoints (5–10/min), and ceremony admin routes. IP resolution prefers x-real-ip / cf-connecting-ip over spoofable headers.
Input validation
Zod schemas with explicit length and shape bounds on every public API. Proof fields, public signals, and verification keys are typed and bounded.
Replay protection
Wallet-signed actions bind action + wallet + canonical fields + timestamp. Timestamps must be fresh (≤ 5 min) and not future-dated. Verified signatures are recorded; replays are rejected.
No raw PII retained
Proofs are generated client-side. The hosted verifier sees the proof and public signals only — never the private witness. Private inputs never leave the user's device.
On-chain integrity
Verification keys are on-chain on Base, Solana, and Sui. The vKey loaded by the hosted verifier is the same one anchored on mainnet.
What we have not proven yet.
Diligence checklists ask about these. We'd rather you read the answers here than guess.
Third-party security audit
Engagement targeted for Q3–Q4 2026. No external audit reports yet. See the certification roadmap below.
SOC 2 / ISO 27001 / HITRUST
Not yet certified. Phased roadmap below: SOC 2 Type I targeted 2027 H1, ISO 27001 targeted 2027 H2, SOC 2 Type II targeted 2028 H1. HITRUST gated on healthcare deal demand.
Formal verification of circuits
Circuits are reviewed by the team and tested against snarkjs reference implementations. Formal verification (e.g. Coq, Halo2 proof-checking) has not been performed.
Self-asserted circuits remain self-asserted
Several circuits (age-verification, range-proof, credential-proof, anonymous-reputation) classify as self-asserted. The math is sound; the underlying claim is only as trustworthy as the user. Attested upgrades are on the roadmap.
How we close the trust gaps above.
Targets, not promises. Each milestone is gated on the previous, on customer demand, and on the open-source commons remaining the primary deliverable. We publish dates so buyers and auditors can hold us accountable — not to anchor expectations we cannot meet.
Target
Q3–Q4 2026
EngagedMilestone
Third-party security audit
Cryptographic audit of the 14 production circuits, WASM prover, and on-chain verifiers by a recognised ZK-auditing firm (Zellic, ZKSecurity, or Veridise class). Full report published open-access.
Why it matters for buyers
The floor. Every enterprise security questionnaire begins here, and supervisor-facing pages (`/enterprise`, `/enterprise/dora`) cite the engagement date.
Target
2027 H1
PlannedMilestone
SOC 2 Type I
Point-in-time attestation against the AICPA Trust Services Criteria (security, availability, confidentiality, processing integrity).
Why it matters for buyers
US enterprise procurement treats SOC 2 as effectively non-negotiable. Type I is the gateway to Type II.
Target
2027 H2
PlannedMilestone
ISO/IEC 27001 certification
ISMS certification scoped to the hosted verifier, SDK supply chain, and ceremony operations.
Why it matters for buyers
EU enterprise procurement expectation; cited explicitly in DORA Art. 28 supplier risk obligations and in member-state EUDI Wallet vendor selection.
Target
2028 H1
PlannedMilestone
SOC 2 Type II
Twelve-month operating-effectiveness observation building on Type I controls.
Why it matters for buyers
Banks, insurers, healthcare networks procure against Type II — not Type I.
Target
2028 (gated)
Demand-gatedMilestone
HITRUST CSF
Healthcare-specific certification mapping HIPAA Security Rule plus dozens of adjacent frameworks (NIST CSF, PCI DSS, GDPR).
Why it matters for buyers
Pursued if and when healthcare deal demand materialises. Not a sunk cost otherwise — listed here for honesty, not to over-promise.
Honest framing — The open-source commons remains the primary deliverable. Every milestone above is gated on the previous one, on real enterprise demand, and on funding (grant, paid pilot, or acquirer support). We will not chase certifications without the buyers that need them.
Need a deeper review for a security questionnaire?
We're happy to walk through the trust model, ceremony transcripts, and our audit timeline with your team.