ZK Threat Extension

This note extends the main threat model for the additive PrivateDAO zk stack.

The deployed governance program is unchanged. These threats apply to the off-chain Circom, Groth16, registry, and reviewer-verification layer that now accompanies the live protocol.

Scope

Covered zk surfaces:

• zk/circuits/private_dao_vote_overlay.circom
• zk/circuits/private_dao_delegation_overlay.circom
• zk/circuits/private_dao_tally_overlay.circom
• setup artifacts under zk/setup/
• proof and public-signal artifacts under zk/proofs/
• zk registry under docs/zk-registry.generated.json

Additional Threat Classes

Circuit / verifier drift

Risk:

• a proof verifies, but the reviewer is looking at stale or mismatched circuit artifacts

Mitigation:

• docs/zk-registry.generated.json binds each layer to its source, sample input, proof, public signals, proving key, and verification key
• npm run verify:zk-registry rejects missing or mismatched registry paths and signal counts

Public-signal tampering

Risk:

• a proof package is presented with altered public outputs to misrepresent what was actually proven

Mitigation:

• npm run verify:zk-negative mutates public outputs and confirms verification rejection
• npm run verify:zk-consistency recomputes the sample public signals through SDK helpers and checks they match the stored outputs

Proof-object tampering

Risk:

• a proof object is modified while the surrounding review package stays intact

Mitigation:

• npm run verify:zk-negative also mutates proof coordinates and requires rejection
• the cryptographic manifest makes proof drift tamper-evident at the repository level

Registry / document drift

Risk:

• zk docs, generated registry, and reviewer artifacts drift apart over time

Mitigation:

• npm run build:zk-registry
• npm run verify:zk-registry
• npm run verify:generated-artifacts
• npm run verify:review-surface

Setup artifact substitution

Risk:

• the wrong verification key or proving key is paired with a circuit or proof package

Mitigation:

• the registry records the exact setup paths per circuit
• the cryptographic manifest fingerprints the verification keys
• zk verification commands use the exported verification keys directly from the tracked artifact tree

Sample witness misrepresentation

Risk:

• reviewers are shown proofs without a clear mapping back to witness assumptions

Mitigation:

• each circuit has a committed sample input under zk/inputs/
• npm run zk:all rebuilds the full proving path from those sample inputs
• docs/zk-evidence.md and docs/zk-stack.md map each layer to its witness and public signals

Residual ZK Risks

The current zk stack remains intentionally bounded:

• it is off-chain today and not yet an on-chain verifier integration
• Groth16 trusted setup assumptions apply
• the tally layer currently proves a bounded reveal sample, not a full hidden on-chain tally replacement
• zk does not make treasury execution private
• zk does not remove metadata leakage from transaction timing or wallet activity

Reviewer Verification Path

The minimum zk review path is:

npm run build:zk-registry
npm run verify:zk-registry
npm run verify:zk-consistency
npm run verify:zk-negative
npm run zk:all

This is intended to make the zk surface reviewer-verifiable instead of claim-based.