Zero-Knowledge Layer

PrivateDAO's current deployed protocol remains the same commit-reveal governance system described in the core specification.

The zk layer is now a layered additive companion stack, not a silent protocol rewrite.

Current Live Flow

Create Proposal
-> Commit Vote
-> Reveal Vote
-> Finalize Proposal
-> Timelocked Execute

Current privacy property:

• vote choice stays hidden during the commit phase
• reveal later discloses the committed vote preimage

Current limitation:

• commit-reveal protects live tally privacy
• reveal still discloses witness information directly

What The ZK Layer Adds

The zk layer introduces real Circom and Groth16 proof systems that validate private governance data without changing the deployed contracts or current frontend lifecycle.

Phase A now also adds a parallel on-chain verification receipt path for proposal-bound proof bundles. This means the repository no longer stops at on-chain proof anchoring alone; it can now bind a proposal-scoped verification receipt on-chain without replacing the existing commit-reveal lifecycle.

Current live stack:

• `private_dao_vote_overlay`
• vote form validity
• threshold eligibility
• proposal-scoped commitment binding
• proposal-scoped nullifier binding
• `private_dao_delegation_overlay`
• delegation activation
• delegatee binding
• delegated weight commitment
• proposal-scoped delegation nullifier binding
• `private_dao_tally_overlay`
• deterministic weighted tally proof
• commitment-consistent reveal sample
• nullifier accumulator over the revealed sample

Current Commit-Reveal vs ZK-Augmented Governance

Current commit-reveal

• commitment format is `sha256(vote || salt || proposal_pubkey || voter_pubkey)`
• reveal checks the exact preimage
• no zk verifier is required
• privacy is strongest before reveal

ZK-augmented governance

• proof systems validate richer private witnesses across vote, delegation, and tally layers
• eligibility, delegation, and deterministic tally logic can be proven with less direct witness disclosure
• proposal-bound proof anchors can be written on-chain
• proposal-bound parallel verification receipts can now be written on-chain in Phase A
• future `zk_enforced` governance becomes possible without redesigning the current governance product

What The ZK Layer Does Not Claim Yet

• it does not replace the deployed commit-reveal enforcement path yet
• it does not change current instruction interfaces
• it does not make treasury execution private
• it does not remove all metadata leakage
• it does not claim anonymous final execution

Current boundary:

• off-chain witness generation and proving
• on-chain proof anchoring
• on-chain parallel verification receipts
• proposal-level `zk_enforced` mode is now available in parallel
• canonical lifecycle enforcement still handled by the current governance program path
• `zk_enforced` is not yet promoted as the dominant production path; see `docs/phase-c-hardening.md`

New Trust Assumptions

The zk layer introduces additional assumptions that must be stated clearly:

• circuit correctness
• witness generation correctness
• verification key correctness
• Groth16 trusted setup integrity
• proof verification correctness

Verification Entry Point

npm run zk:all

This command:

• compiles every live zk circuit
• generates or refreshes setup artifacts
• builds witnesses from circuit-specific sample inputs
• generates real proofs
• verifies all proofs against their exported verification keys

That is why the zk layer is evidence-backed rather than aspirational.

Per-layer commands:

npm run zk:prove:vote
npm run zk:prove:delegation
npm run zk:prove:tally