ZK Provenance

The PrivateDAO zk stack is intended to be reviewable as a concrete artifact chain, not as a loose collection of circuit files.

Provenance Scope

The provenance surface covers:

• Circom circuit sources
• sample inputs
• witness artifacts
• Groth16 proving keys
• Groth16 verification keys
• generated proofs
• generated public signals
• the shared ptau artifact used by the current setup flow

Why Provenance Matters

The security question is not only whether a proof verifies.

Reviewers also need to know:

• which setup artifacts were used
• which proof files correspond to which circuit layer
• whether tracked hashes match the current repository contents
• whether replay commands and review artifacts remain aligned over time

That is why the zk package now includes:

• `docs/zk-registry.generated.json`
• `docs/zk-transcript.generated.md`
• `docs/zk-attestation.generated.json`

Current Provenance Model

The current stack is built around:

• proving system: `Groth16`
• shared setup artifact: `zk/setup/pot12_final.ptau`
• per-layer proving and verification keys
• deterministic reviewer commands per layer

Replay Path

npm run build:zk-registry
npm run build:zk-transcript
npm run build:zk-attestation
npm run verify:zk-registry
npm run verify:zk-transcript
npm run verify:zk-attestation
npm run verify:zk-docs
npm run verify:zk-consistency
npm run verify:zk-negative
npm run zk:all

Reviewer Conclusion

If the registry, transcript, and verification commands all pass, reviewers can conclude that the tracked zk stack is not only present, but provenance-linked across source, setup, proof, and documentation layers.

Honest Boundary

This provenance layer improves artifact traceability and reviewer trust.

It does not by itself mean:

• trusted setup concerns disappear
• on-chain verification is already deployed
• the current Solana program has been rewritten around zk proofs