<!-- SPDX-License-Identifier: AGPL-3.0-or-later -->

ZK-Enforced Operator Flow

This is the exact operator path for moving a proposal from the normal commit-reveal lifecycle into the stronger `zk_enforced` path.

Current Boundary

PrivateDAO still keeps commit-reveal as the canonical governance boundary.

`zk_enforced` is already live, but it is promoted proposal by proposal only after the stronger receipt set exists on chain.

Exact Sequence

• Create the proposal normally.
• Record or upgrade the three DAO-authority receipts in `zk_enforced` mode:
• vote
• delegation
• tally
• Inspect the proposal receipt state:
• `PROPOSAL_PDA="$PROPOSAL_PDA" npm run inspect:zk-proposal -- --proposal "$PROPOSAL_PDA"`
• Lock the proposal into `zk_enforced`:
• `PROPOSAL_PDA="$PROPOSAL_PDA" npm run configure:zk-mode -- --proposal "$PROPOSAL_PDA" --mode zk_enforced`
• Finalize through the correct path:
• `PROPOSAL_PDA="$PROPOSAL_PDA" yarn finalize -- --proposal "$PROPOSAL_PDA"`
• Execute only after normal lifecycle success and timelock clearance:
• `PROPOSAL_PDA="$PROPOSAL_PDA" yarn execute -- --proposal "$PROPOSAL_PDA"`

Receipt Strength Rule

Parallel receipts are not enough for `zk_enforced`.

A proposal can only move into `zk_enforced` when:

• vote receipt is `zk_enforced` and recorded by the DAO authority
• delegation receipt is `zk_enforced` and recorded by the DAO authority
• tally receipt is `zk_enforced` and recorded by the DAO authority

If even one receipt is still only `parallel`, the stronger finalize path must remain blocked.

Operator Checks

Before enabling `zk_enforced`, confirm:

• the proposal PDA is correct
• all three receipt PDAs exist
• each receipt is proposal-bound
• each receipt is in `zk_enforced` mode
• each receipt was recorded by the DAO authority
• the verifier program field is present for the stronger receipts

What This Does Not Claim Yet

This flow does not claim that full Groth16 verifier enforcement is already the final canonical boundary on chain.

What it does provide today is:

• proposal-bound on-chain proof anchors
• DAO-authority on-chain verification receipts
• stronger receipt mode hierarchy
• proposal-level policy locking
• a distinct finalize path for `zk_enforced`

Why This Matters

This operator flow makes the stronger path usable without breaking existing governance.

It gives reviewers and operators a deterministic sequence for:

• inspecting receipt strength
• enabling the stronger policy
• finalizing with the stronger path
• keeping the remaining blockers explicit