Governance Layer

The Governance Layer is responsible for decision-making without visibility. It allows organizations to create proposals, collect votes, and reach binding outcomes without revealing who voted, how they voted, or how the vote evolved over time.

This layer ensures that governance remains enforceable, private, and resistant to manipulation.


Purpose

Traditional on-chain governance exposes:

  • Voter identities

  • Vote choices

  • Real-time vote counts

This creates influence, coercion, vote buying, and governance capture.

The Governance Layer in ZKFund replaces transparent voting with zero-knowledge verified voting, where:

  • Eligibility is proven, not shown

  • Vote weight is enforced, not visible

  • Results are final, not trendable


Design Goals

The Governance Layer is designed to:

  • Support private proposal creation

  • Enforce role-based and stake-based voting

  • Hide interim voting results and quorum

  • Prevent double voting and replay attacks

  • Produce a final, verifiable outcome only


Proposal Lifecycle

Every governance action in ZKFund follows a strict lifecycle.

1. Proposal Creation

  • A proposal is created by an authorized role

  • It defines:

    • Action type (swap, withdraw, allocate, config)

    • Required roles

    • Voting model

    • Execution thresholds

    • Expiration rules

  • Proposal metadata and parameters may be:

    • Public

    • Partially hidden

    • Fully private (verified via circuit constraints)

2. Voting Phase

  • Eligible members submit ZK voting proofs

  • Each proof confirms:

    • Membership validity

    • Role authorization

    • Vote choice correctness

    • Proper vote weighting

  • Votes are unlinkable and non-replayable

3. Finalization

  • After the voting window closes:

    • Quorum is evaluated inside the circuit

    • Votes are aggregated privately

  • Only the final state is published:

    • Approved

    • Rejected

    • Expired

Interim vote counts are never revealed.


Voting Models

The Governance Layer supports multiple voting models, enforced inside ZK circuits.

  • Token-Weighted Voting Vote weight proportional to staked token amount

  • Role-Weighted Voting Different roles carry different weights

  • Stake-Weighted Voting Weight derived from locked stake or fund exposure

  • Hybrid Models Combination of token, role, and stake

All models:

  • Enforce correct weighting

  • Prevent over-voting

  • Do not expose individual contributions


Hidden Quorum & Hidden Results

ZKFund supports hidden quorum by design.

  • The required participation threshold is enforced privately

  • Observers cannot infer:

    • How many votes have been cast

    • Whether quorum is close to being met

  • Finalization reveals only success or failure

This removes:

  • Bandwagon effects

  • Last-minute manipulation

  • Strategic abstention


Anti-Abuse Protections

The Governance Layer includes protections against:

  • Double Voting Prevented via session-bound nullifiers

  • Replay Attacks Proofs are bound to proposal IDs and epochs

  • Unauthorized Proposals Enforced via proof-of-role at creation

  • Governance Spam Mitigated through stake requirements and proposal costs


Output of the Governance Layer

The Governance Layer produces:

  • A finalized proposal state

  • A cryptographic proof of correctness

  • A deterministic execution authorization

It does not:

  • Execute transactions

  • Move funds

  • Reveal governance participants


Why Governance Is Separated from Execution

By separating governance from execution:

  • Decisions can be private

  • Enforcement can be strict

  • Execution remains deterministic

  • Privacy does not compromise security

The Governance Layer answers “Should this action happen?”, but never reveals “Who decided?”.

Last updated