Private Proposal System
The Private Proposal System defines how actions are requested, constrained, and authorized in ZK DAO—without exposing sensitive intent, parameters, or strategy.
A proposal in ZKFund is not just a message or a vote. It is a cryptographically constrained action container.
Purpose
In traditional DAOs, proposals reveal:
What action is planned
When it will occur
How much capital is involved
Who is driving the decision
This creates:
Front-running opportunities
Strategic signaling
Internal pressure and manipulation
The Private Proposal System is designed to separate intent from disclosure.
What a Proposal Represents
A proposal represents:
An intent to perform a specific class of action
A set of governance and execution constraints
A bounded execution context
It does not require revealing:
Exact amounts
Counterparties
Execution routes
Internal strategy rationale
Proposal Structure
Each proposal includes the following components:
1. Proposal Identifier
Unique, immutable ID
Used to bind votes and execution proofs
Prevents replay across contexts
2. Action Type Defines the category of action, such as:
Swap
Withdraw
Allocate
Create pool
Update parameter
Add/remove role
Action type determines:
Required roles
Voting model
Execution thresholds
3. Governance Rules Each proposal specifies:
Who can vote (roles)
How votes are weighted
Required quorum
Finalization conditions
Expiration window
Rules are fixed at creation and cannot be modified.
4. Execution Constraints Execution constraints define what execution is allowed to do, without exposing details.
Examples:
Maximum withdraw limit
Allowed asset class
Time-bounded execution
Destination type (e.g., ZK Pool only)
These constraints are enforced cryptographically at execution time.
5. Hidden Parameters Sensitive parameters may be:
Fully hidden
Partially committed via hashes
Proven via ZK circuits at execution
This allows the system to verify correctness without revealing values.
Proposal Creation Authorization
Proposal creation is restricted by role.
To create a proposal, a participant must prove:
Membership in the fund or DAO
Possession of the required role
Compliance with proposal creation rules
All proofs are:
Non-linkable
Context-bound
Non-replayable
Proposal Privacy Levels
ZKFund supports multiple proposal visibility modes:
Public Proposal Metadata is visible; execution details remain private
Semi-Private Proposal Action type and constraints are visible; parameters are hidden
Fully Private Proposal Only existence and lifecycle are visible
The choice is governed by DAO policy.
Proposal Lifecycle
Created Proposal is registered with immutable rules
Active Voting proofs are accepted
Finalized Outcome is determined privately
Executable Execution authorization is unlocked
Expired Proposal becomes invalid if not executed in time
Anti-Abuse Protections
The system enforces:
Proposal creation limits
Stake or fee requirements
Role-based gating
Automatic expiration
This prevents:
Governance spam
Denial-of-service via proposals
Strategic flooding attacks
What the Proposal System Guarantees
No action can be executed without a valid proposal
Proposal rules cannot be changed mid-flight
Sensitive intent is not leaked
Governance remains deterministic
Why Proposals Are the Core Primitive
In ZKFund, proposals are the only gateway to action.
They:
Encode intent
Bind governance
Constrain execution
Preserve privacy
Everything else—voting, multisig, settlement—depends on them.
Last updated