Common DAO Spec Feedback

[salmad3]

Context:

The gno boards working group is referencing the Common DAO Spec as part of our efforts to implement a similar DAO in gno.land. While reviewing with Jae, we identified a few gaps.

Suggestions:

• There is no defined method for shutting down or dissolving a sub-DAO. The specification explains how to create sub-DAOs but is silent on thresholds or processes for removing them.
• Membership changes require a supermajority at both the DAO and ancestor levels, although no specific threshold is given for closing a sub-DAO.
• The default voting rule excludes abstentions from the tally’s denominator but does not clarify how to treat those who neither vote nor formally abstain.
• Bylaws and mandates are governed differently: councils can change bylaws, but an ancestor must change mandates (and charters). This is not necessarily contradictory, but it prevents sub-DAOs from altering their own mandates.
• There is no mechanism to “freeze” a proposal mid-vote, nor a clear method for a minority to escalate or pause disputed proposals within a sub-DAO.
• Although “oversight” powers exist at a higher level, there is still no concept of a sub-DAO–level observer role or any built-in path for internal sub-DAO disputes to be escalated.
• No procedure is outlined for reassigning a sub-DAO to a different parent, merging multiple sub-DAOs, or otherwise restructuring the tree of DAOs beyond initial creation.
• While DAOs can override some rules in their governing documents, it remains unclear if they can adopt varied voting thresholds (for example, something other than simple majority or two-thirds) for different proposal types.
• There is no deposit, bonding, or rate-limiting mechanism to handle spam or large volumes of proposals. “Expiration” is mentioned but lacks concrete parameters, leaving the risk of indefinite or excessive proposals.
• No formal versioning or alignment procedure is described for how changes to the Common DAO spec or a higher-level constitution propagate down through DAOs, nor how these updates should be managed at each level.