search

Governance Architecture

The governance architecture of ZK DAO is designed to separate authority, decision-making, and execution, while keeping all sensitive information private. Each sub-layer has a clearly defined role and interacts with others only through verifiable proofs.

This architecture ensures that governance is deterministic, enforceable, and confidential.

Architectural Overview

ZK DAO governance is composed of four internal layers:

  1. Identity & Membership Layer

  2. Proposal & Rule Definition Layer

  3. Voting & Finalization Layer

  4. Execution Authorization Layer

Each layer enforces constraints that the next layer depends on, forming a one-way, non-bypassable pipeline.

hashtag
1. Identity & Membership Layer (Governance Context)

This layer defines who is allowed to participate in governance.

Key responsibilities:

  • Issuing governance-scoped zkIDs

  • Encoding roles and permissions

  • Enforcing role constraints at proposal creation and voting

Properties:

  • No public member lists

  • No address-role mappings

  • Membership proofs are scoped to governance context

This ensures that only authorized participants can influence governance outcomes.

hashtag
2. Proposal & Rule Definition Layer

This layer defines what can be decided and how.

Each proposal includes:

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

  • Required roles to propose and vote

  • Voting model (token, role, stake, hybrid)

  • Quorum and threshold definitions

  • Execution constraints and expiration

Design choices:

  • Proposal rules are explicit and immutable once created

  • Proposal parameters may be hidden or partially revealed

  • All constraints are enforced inside circuits and contracts

This prevents rule manipulation during the voting process.

hashtag
3. Voting & Finalization Layer

This layer handles decision-making without visibility.

Key responsibilities:

  • Accepting ZK voting proofs

  • Enforcing voting weight and eligibility

  • Preventing double voting

  • Aggregating votes privately

  • Determining final outcome

Important properties:

  • No interim vote counts

  • No visible quorum progress

  • No voter identity exposure

Finalization outputs:

  • Approved / Rejected / Expired state

  • A cryptographic proof of correctness

hashtag
4. Execution Authorization Layer

This layer bridges governance and execution.

Responsibilities:

  • Binding finalized proposals to execution rules

  • Defining required execution thresholds

  • Accepting ZK multisig approval proofs

  • Locking execution to a single valid path

Properties:

  • Execution is impossible without finalized governance

  • Execution thresholds cannot be bypassed

  • Signer identities remain private

This layer ensures that governance decisions are enforced, not just recorded.

hashtag
Governance Data Flow

  1. A participant proves authorization to create a proposal

  2. Proposal rules are fixed and published

  3. Eligible members vote using ZK proofs

  4. The system finalizes the proposal privately

  5. Execution authorization is unlocked

  6. Execution proceeds only with valid ZK multisig proofs

At no point is sensitive governance data revealed.

hashtag
Governance Isolation Guarantees

The architecture guarantees that:

  • Governance cannot directly move funds

  • Execution cannot occur without governance approval

  • Settlement cannot occur without execution authorization

  • No layer can be skipped or bypassed

Each layer is isolated by cryptographic constraints.

PreviousGoals of ZK DAONextPrivate Proposal System

Last updated