ZIP-0017: DAO Governance Framework

Abstract

This proposal establishes the on-chain governance framework for Zoo Network. It defines the DAO structure, proposal types, voting mechanisms, quorum thresholds, timelock parameters, and the interaction between on-chain governance and the Zoo Labs Foundation board's compliance veto authority as outlined in ZIP-0000.

Motivation

Zoo Labs Foundation operates as a 501(c)(3) nonprofit with community-driven governance. A formal framework is needed to:

Legitimize decisions: Provide transparent, verifiable decision-making for treasury and protocol changes
Balance autonomy and compliance: Preserve community sovereignty while respecting nonprofit legal obligations
Prevent capture: Ensure no single entity can dominate governance outcomes
Enable iteration: Allow the governance process itself to evolve through proposals
Coordinate resources: Direct conservation funding, grants, and protocol upgrades effectively

Specification

Governance Architecture

Community (ZOO holders)
        │
        ▼
   Proposal Submission
        │
        ▼
   Voting Period (7 days)
        │
        ▼
   Timelock (48 hours)
        │
        ▼
   Board Review Window (24 hours, veto only)
        │
        ▼
   Execution

Proposal Types

Type	Quorum	Approval	Timelock	Description
Parameter Change	4%	>50%	48h	Adjust protocol parameters
Treasury Spend	10%	>60%	72h	Allocate funds from treasury
Protocol Upgrade	15%	>66%	168h (7d)	Smart contract upgrades
Emergency Action	1%	>80%	0h	Critical security response
Meta-Governance	20%	>75%	168h	Change governance rules

Proposal Lifecycle

lifecycle:
  submission:
    minimum_stake: 100000 ZOO  # Anti-spam threshold
    deposit: 10000 ZOO         # Refunded if quorum met
    cooldown: 24h              # Between proposals per address
  discussion:
    duration: 3 days
    forum: governance.zoo.network
  voting:
    duration: 7 days
    method: token-weighted
    delegation: enabled
    options: [For, Against, Abstain]
  timelock:
    standard: 48 hours
    treasury: 72 hours
    upgrade: 168 hours
  execution:
    window: 14 days  # Must execute within window or proposal expires
    executor: any    # Permissionless execution after timelock

Governance Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ZooGovernor {
    struct Proposal {
        uint256 id;
        address proposer;
        uint256 startBlock;
        uint256 endBlock;
        uint256 forVotes;
        uint256 againstVotes;
        uint256 abstainVotes;
        bool executed;
        bool vetoed;
        ProposalType pType;
    }

    enum ProposalType { Parameter, Treasury, Upgrade, Emergency, Meta }

    mapping(ProposalType => uint256) public quorumBps;
    mapping(ProposalType => uint256) public approvalBps;

    function propose(
        address[] calldata targets,
        bytes[] calldata calldatas,
        string calldata description,
        ProposalType pType
    ) external returns (uint256 proposalId) {
        require(getVotes(msg.sender) >= proposalThreshold(), "below threshold");
        // Create and store proposal
    }

    function castVote(uint256 proposalId, uint8 support) external {
        // Record vote weighted by token balance at snapshot
    }
}

Vote Delegation

Token holders may delegate their voting power to any address without transferring tokens. Delegation is transitive up to one level (A delegates to B, but B cannot re-delegate A's votes).

Board Veto Mechanism

Per ZIP-0000 Section 15, the Foundation board retains a narrow compliance veto:

Board may veto only for legal, mission, or donor-restriction violations
Veto must include a public written justification
Vetoed proposals enter a 30-day appeal period where a supermajority (80%) can override

Rationale

The tiered quorum and approval thresholds scale with the impact of the decision. Low-impact parameter changes need only 4% quorum, while changes to governance itself require 20%. This prevents governance fatigue while ensuring high-stakes decisions have broad consensus.

The 100,000 ZOO proposal threshold (~0.01% of supply) balances accessibility against spam. The refundable deposit further deters frivolous proposals without permanently penalizing good-faith participants.

Emergency actions have minimal quorum but require 80% supermajority, enabling rapid response to security incidents while preventing abuse.

Security Considerations

Flash loan attacks: Voting power is snapshotted at proposal creation block, preventing flash-loan governance attacks
Timelock: All non-emergency actions pass through a timelock, giving users time to exit if they disagree
Proposal spam: Minimum stake and deposit requirements prevent denial-of-service on governance
Voter apathy: Delegation allows active participants to represent passive holders
Centralization risk: No single address may hold more than 5% of delegated voting power (enforced at contract level)

DAO Governance Framework