--- id: c9-governance-mechanisms-spec title: Governance Mechanisms Spec module: GROW-S9 module_slug: grow-s9-dao-governance cluster: Coordination type: spec version: v0.1.0 status: Gate-reviewed tier: membership contract_role: "" canonical_url: "https://grow.goodcombinator.ai/library/registry/c9-governance-mechanisms-spec" download_url: "https://grow.goodcombinator.ai/library/registry/c9-governance-mechanisms-spec.md" license: CC-BY-4.0 (proposed — owner confirmation required) source: GROW by Good Combinator retrieved_at: 2026-05-29 --- # Governance Mechanisms Spec The Governance Mechanisms Spec defines the precise rules under which proposals are counted, quorum is measured, votes are weighted, delegations are registered, working groups operate, and emergency powers are invoked. These are the rules the voting infrastructure enforces — not aspirational principles but machine-checkable conditions that determine whether a proposal passed or failed. Every mechanism in this spec derives from the decision-rights assignments in `c9-decision-rights-matrix`; this spec translates those rights into exact thresholds and procedures. Changing any threshold requires a `parameter-update` proposal except where noted; changing the quorum or approval-threshold structure itself requires a `contract-change` proposal. --- ## 1. Quorum Rules Quorum is the minimum participation threshold that must be met for a vote to be valid. It is separate from the approval threshold (what fraction of participating votes must be "yes" to pass). A vote can clear quorum and still fail approval; a vote that does not clear quorum is void regardless of the approval ratio. ### 1a. Quorum Definition Quorum is measured as the fraction of eligible voting weight that participates (casts a vote or explicitly abstains) during the voting window. ``` quorum_met = (votes_cast + abstentions) / total_eligible_weight >= quorum_threshold ``` "Total eligible weight" is the governance-token supply eligible to vote on the specific decision class at the moment the voting period opens. Tokens locked in active proposals or under dispute are excluded from the denominator until resolved. ### 1b. Quorum Thresholds by Decision Class | Decision Class | Quorum Threshold | Notes | |---|---|---| | `treasury-allocation` | 20% of eligible weight | Low threshold to prevent gridlock on operational decisions | | `contract-change` | 35% of eligible weight | Higher participation required given meta-governance stakes | | `working-group-charter` | 15% of eligible weight | Minimal; working-group scope is contained | | `membership-change` | 30% of eligible weight | Membership changes affect all participants | | `parameter-update` | 35% of eligible weight | Changes to governance parameters must reflect broad engagement | | `retroactive-reward` | 20% of eligible weight (excluding nominee) | Nominee's weight excluded from both numerator and denominator | | `platform-partnership` | 20% of eligible weight | Board gate is the primary control; token vote is ratification | | `emergency-ratification` | Steward Council majority (not token-weighted) | Emergency measure; full token vote follows for any expenditure exceeding $5,000 (illustrative) | ### 1c. Quorum Failure If quorum is not met by the close of the voting period, the proposal fails with outcome `quorum-failed`. The proposal may be resubmitted in the next cycle without modification; a resubmitted proposal restarts the review and voting period clock. Quorum failure is logged in the C11 provenance record with `outcome: quorum-failed` — it is a governance outcome, not an error. --- ## 2. Approval Thresholds The approval threshold determines what fraction of participating votes (those cast, not including abstentions) must be "yes" for the proposal to pass. ``` approved = yes_votes / (yes_votes + no_votes) >= approval_threshold ``` Abstentions count toward quorum but do not count in the approval ratio. A voter who abstains is participating (counts for quorum) but is not expressing a directional preference (does not affect the yes/no ratio). | Decision Class | Approval Threshold | Notes | |---|---|---| | `treasury-allocation` | > 50% (simple majority) | Standard operational decision | | `contract-change` | ≥ 67% (supermajority) | Meta-governance; high bar intentional | | `working-group-charter` | > 50% | Simple majority | | `membership-change` | ≥ 67% | Supermajority; changes affect collective | | `parameter-update` | ≥ 67% | Governance-parameter changes require broad consensus | | `retroactive-reward` | > 50% (excluding nominee weight) | Nominee excluded from denominator and numerator | | `platform-partnership` | > 50% for token ratification (Board gate separate) | Two-gate structure; both must pass | | `emergency-ratification` | Steward Council majority | Immediate; full token vote follows for large amounts | ### 2a. Veto Exercise A veto by the Vetoer (named in `c9-decision-rights-matrix`) overrides a passed vote if exercised within the veto window. Veto is logged as a `governance-vote` event with `outcome: vetoed` in the C11 provenance record. After a veto, the proposer may submit a revised proposal; the revised proposal restarts the full review and voting clock. A veto does not expire a proposal's concept — only that specific proposal instance. --- ## 3. Voting Mechanics ### 3a. Voting Weight Model Default: linear token weighting. One governance token = one vote. **Alternatives** (require a `parameter-update` proposal before use): - **Quadratic voting:** vote weight = √(tokens committed to that vote). Reduces concentration of influence; requires token lockup per vote. Not default. - **Reputation-weighted:** vote weight is a function of on-chain contribution history. Requires a defined reputation oracle. Not default. - **Multi-class voting:** different token classes have different weights or vetoes. Requires membership-class definition. Not default. ### 3b. Vote Casting Window The voting window opens and closes at the timestamps declared in the proposal header. Late votes are not counted. The voting platform must enforce the window; manual overrides of the close timestamp are a governance violation and require a `contract-change` proposal to permit. ### 3c. Vote Finality Once the voting window closes, the tally is final. No corrections or additions may be accepted. Any dispute about vote eligibility (e.g., token transfer during voting) must be raised before the window closes. Post-close disputes are resolved by submitting a new proposal to reverse or modify the outcome. --- ## 4. Delegation Token holders may delegate their voting weight to another participant for a defined scope. ```yaml delegation_record: delegator:
delegate:
scope: valid_from: valid_until: registered_at: ``` **Delegation rules:** 1. A delegation must be registered before the voting period opens for any vote it covers. Retroactive delegation is not permitted. 2. A delegate may not sub-delegate without an explicit new delegation record from the original holder. 3. A delegation may be revoked at any time before the voting period opens. Revocation after the voting period opens takes effect in the next voting cycle. 4. A delegate who holds their own tokens votes their own tokens directly; their delegated weight is additive. 5. A delegate may not split the delegated weight across multiple "yes" and "no" positions — delegation is all-or-nothing per proposal. --- ## 5. Working Groups Working groups are sub-units of the DAO authorized to act within a defined scope and budget by a passed `working-group-charter` proposal. They are the mechanism for delegating ongoing operational authority without a vote on every action. ### 5a. Working Group Charter Requirements A working-group-charter proposal must define: ```yaml working_group: id: mandate: lead: members: budget_ceiling: budget_period: authority_level: # operational = binding execution; advisory = recommendations only renewal_required: reporting_cadence: dissolution_trigger: ``` ### 5b. Working Group Decision Authority A working group with `authority_level: operational` may take actions within its mandate and budget without a separate DAO vote, provided: 1. Each action falls within the `mandate` scope. 2. The cumulative spend does not exceed the `budget_ceiling` for the period. 3. The action does not cross an irreversible-impact boundary defined in `c9-governance-purpose-charter` §3. 4. The action is reported to the full DAO within the stated `reporting_cadence`. Actions that exceed any of these bounds revert to the full `treasury-allocation` proposal process. --- ## 6. Emergency Powers Emergency powers allow the Accountable Steward to act before a vote when an immediate threat exists. They are deliberately narrow and subject to mandatory retroactive review. ### 6a. Trigger Conditions Emergency powers may be invoked only when: - Immediate threat to physical property, persons, or data at the governed site or platform. - A regulatory deadline will be irreversibly missed within the window required for a standard vote. - A critical infrastructure failure requires immediate expenditure to prevent larger loss. "We could have voted but it was inconvenient" is not a trigger condition. The Accountable Steward invoking emergency powers must document the trigger condition at the time of action, not in retrospect. ### 6b. Emergency Action Protocol 1. Accountable Steward acts immediately to address the threat. 2. Within 24 hours, the Steward submits an `emergency-ratification` proposal documenting: what was done, why, what evidence supports the trigger, and what the outcome was. 3. The Steward Council votes on ratification within 24 hours of submission. 4. If ratified: a C11 provenance record is emitted with `decision_class: emergency-ratification, outcome: passed`. The action is retroactively authorized. 5. If not ratified: the action stands (it cannot be undone if irreversible), but the Accountable Steward is subject to accountability review and the DAO may seek remediation through a new proposal. ### 6c. Emergency Spending Cap Emergency spending without prior vote is capped at 3% of the treasury balance at the time of the action. Amounts above this cap must have Steward Council verbal approval before action and formal ratification within 24 hours. --- ## 7. Governance Review Cadence The full governance system is reviewed on a defined schedule. These are not optional social events; they are the mechanism by which the DAO detects drift in governance health. | Review Type | Frequency | Scope | Output | |---|---|---|---| | Treasury health report | Monthly | Reserve ratio, unallocated %, overdue milestones | Published dashboard | | Proposal pipeline review | Monthly | Open proposals, stale proposals (> 30 days in review), quorum-fail rate | Steward Council action log | | Governance parameter review | Annually | Quorum thresholds, approval thresholds, tranche ceilings | `parameter-update` proposal if changes needed | | Charter and rights matrix review | Annually (or on trigger) | Decision-class coverage, exclusion list currency, meta-governance rule | `contract-change` proposal if changes needed | | Working group performance review | Per working-group period | Mandate delivery, budget utilization, reporting compliance | Renewal or dissolution recommendation | --- ## 8. Worked Example — PP DAO Quorum and Vote Tally **Proposal:** `pp-dao-prop-2026-003` — AI inference hardware refresh `(illustrative)` **Decision class:** `treasury-allocation` **Quorum threshold:** 20% of eligible weight **Approval threshold:** > 50% | Metric | Value | |---|---| | Total eligible weight (governance tokens eligible at voting open) | 1,000,000 tokens `(illustrative)` | | Votes cast ("yes" + "no") | 218,000 tokens | | Abstentions | 12,000 tokens | | Total participating | 230,000 tokens | | Quorum check | 230,000 / 1,000,000 = 23% ≥ 20% — **quorum met** | | Yes votes | 168,000 tokens | | No votes | 50,000 tokens | | Approval ratio | 168,000 / (168,000 + 50,000) = 77% > 50% — **approved** | | Veto window | 48 hours; Founding Steward Council passed with no veto exercised | | Outcome | `passed` | | C11 record trigger | `c9-execution-accountability` emits the C11 record before Treasurer executes M1 disbursement | --- ## 9. Failure Modes in Governance Mechanisms | Failure Mode | Signal | Correct Behavior | |---|---|---| | Vote closed late by manual override | Tally timestamp differs from declared close | Void the vote; resubmit with correct timing; log as governance violation | | Delegation not registered before window | Delegate casts vote on behalf of delegator without pre-registration | Disqualify delegated votes; re-tally; notify affected parties | | Quorum denominator includes locked tokens | Quorum met only because locked tokens were excluded post-hoc | Re-tally with correct denominator; escalate if outcome changes | | Emergency powers invoked for convenience | No documented immediate threat at time of action | Ratification fails; accountability review; remediation proposal | | Working group exceeds mandate | Action outside defined mandate scope | Action void; working-group lead accountable; `contract-change` or new WG charter required | --- ## 10. Cross-Reference Summary | Artifact | Relationship | |---|---| | `c9-decision-rights-matrix` | Per-class quorum and approval thresholds derive from the rights matrix rows | | `c9-resource-allocation-framework` | Working-group budgets and emergency spending cap reference tranche rules | | `c9-proposal-design-template` | Review period minimums in `c9-proposal-design-template §8` must match this spec | | `c9-execution-accountability` | C11 emitter; reads quorum and approval outcomes to determine `outcome` field value | ## Usage Notes Set quorum thresholds conservatively at launch — a DAO with a thin token distribution cannot meet high quorum targets without coordinated effort. The thresholds in §1b are starting recommendations; use a `parameter-update` proposal to tune them based on observed participation rates after the first two quarters. Any change to the approval or quorum threshold structure (not just the numeric values but how the ratio is calculated) is a `contract-change`-class change, not a `parameter-update`.