zkzkHeliosDocs

Architecture

How a statement becomes an on-chain attestation, end to end.

zkHelios splits responsibilities across three layers: the client (proving), the verifier program (on-chain verification), and the indexer/API (read access).

The Commit → Prove → Verify flow

text
Client (browser)            Solana                         Indexer / API
─────────────────           ──────                         ─────────────
1. Commit inputs
2. snarkjs.fullProve  ──▶    (nothing on-chain yet)
3. format → [u8;32]
4. verify_proof tx    ──▶    Anchor program
                            · alt_bn128 pairing check
                            · writes ProofAccount PDA  ──▶  ProofRecord
                            · emits ProofVerified           (queryable)

Layers

  • Client — circuit artifacts (wasm + zkey) run in a Web Worker; private inputs never leave the device.
  • Verifier program — an Anchor program performs the Groth16 pairing check using Solana's native alt_bn128 syscalls.
  • Indexer — subscribes to program logs (Helius webhooks or RPC polling) and exposes proofs/transactions via REST + WebSocket.

Trust model

Verification is trustless: the pairing check runs on-chain and anyone can re-verify a proof in the browser. The indexer is a convenience layer for reads — it never gates verification.

PreviousQuickstartNextProof system