gov: CommonDAO

[salmad3]

Context:

Warning

Scope and criteria are still being discussed and remain a work in progress.

Over the past few weeks, we've converged on a concept called “CommonDAO.” It builds on earlier DAO-related efforts (like “AdminDAO” and “ModerationDAO”) to provide governance in a standardized, extensible, and on-chain manner. The preliminary implementation of CommonDAO was initiated as part of r/boards2, which evolved from the AdminDAO model.

Beyond boards, CommonDAO is intended as a default governance framework for Gno-based dApps. The immediate use case is enabling governance for the r/boards realm (discussion forums) and the r/events realm (event planning). Future dApps are expected to adopt CommonDAO for similar governance needs.

Foundational Goals:

• Provide a reusable governance model that multiple realms (dApps) can adopt.
• Keep the initial implementation minimal but allow room for future enhancements.
• Leverage the Common DAO Spec from the AtomOne Constitution where applicable.

Expected Outcomes:

1. A clear specification for CommonDAO v1: proposals, voting, subDAO structure.
2. A functional reference implementation (Gno package) for easy deployment in new realms.
3. A migration path for future versions.

Structure:

CommonDAO uses a tree-based governance structure. A CommonDAO may be the root of its own subtree or a child within a larger hierarchy. SubDAOs are child DAOs created under a parent’s authority. A parent CommonDAO can impose mandates, override memberships, or dissolve a subDAO with a supermajority vote. SubDAOs conduct everyday decision-making via their own councils, as long as they follow inherited rules.

Core Requirements:

Note

These may evolve into acceptance criteria.

Scope for v1:

1. Council Setup: Initialize a CommonDAO, define its charter, and seat its initial council.
2. Two Proposal Types: Simple majority for routine governance and supermajority for sensitive changes like membership.
3. SubDAO Creation: Let a parent CommonDAO spawn subDAOs with a simple majority.
4. Membership Management: Allow councils to add or remove members, subject to supermajority.
5. Bylaws: Enable a DAO to set or revise internal voting thresholds or roles.
6. Mandates: Respect top-down mandates; full logic for complex inheritance can come later.

1. Council and Voting

   • One council per CommonDAO, with each member typically holding one vote.
   • Simple majority for general proposals.
   • Supermajority (two-thirds or more) for sensitive actions like membership changes.
   • No quorum requirement by default; proposals stay open until decided or expired.

2. Charter, Bylaws, and Mandates

   • Charter defines the CommonDAO’s purpose, description, and initial council seats.
   • Bylaws govern internal rules like thresholds or roles.
   • Mandates are top-down obligations from a parent or ancestor DAO.
   • Bylaws can be changed internally. Mandates can only be modified by the ancestor that issued them.

3. SubDAOs

   • A CommonDAO can spawn child CommonDAOs (subDAOs) by a simple majority proposal.
   • Each subDAO has its own charter and council but inherits constraints from ancestor bylaws and mandates.
   • A supermajority in a parent (or ancestor) can revoke or alter a subDAO’s membership or dissolve it.

4. Escalation

   • A subDAO can escalate problematic or deadlocked proposals to a parent or ancestor.
   • Future versions may require a threshold (e.g., 10% or two members) to request escalation.
   • Escalation can freeze a proposal for higher-level intervention, preventing forced outcomes under gridlock.

5. Conflict Resolution

   • Freezing can pause a DAO or proposal while issues are resolved.
   • A subDAO facing repeated deadlocks or crises can be frozen or restructured by a parent.
   • A later observer DAO role might freeze from outside to add checks and balances.

6. Membership Mutation

   • Adding or removing council members typically requires a supermajority.
   • A CommonDAO can update its membership, but an ancestor may override this with a supermajority vote.
   • This preserves local governance while allowing top-down fail-safes.

Implementation Considerations:

• Package Design

  • Provide a Gno package (e.g., p/commonDAO) with clear interfaces for creating proposals or tallying votes.
  • Include configurable defaults for thresholds, membership rules, and so on.

• Proposal Types

  • Simple majority proposals for everyday decisions.
  • Supermajority proposals for major decisions like membership changes or subDAO creation.
  • Potential expansions include freeze, escalate, or budget proposals in later releases.

• Upgradability

  • Maintain state in a way that supports future versions without disruptive migrations.
  • Consider a proxy pattern or stable data realm approach for updating code.
  • The exact upgradability approach may evolve as gno.land matures.

[n2p5]

Thanks for adding this @salmad3.