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. Track progress on the roadmap.
SOC 2 / ISO 27001
Not pursued. zkRune is currently a small open-source team; formal certifications are not yet a realistic spend. Enterprise contracts can include a custom data-handling DPA.
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.
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.