Skip to main content

How We Make Decisions

Living Governance Document

The DAO Masons rulebook is a living document that may change significantly in response to internal governance.

Do you see a way these docs could improve? Click the Give feedback button at the top of this document or join the DAO Masons Discord to let us know.

Who Decides?

  • Core Members always have the option to make Core DAO decisions through Moloch DAO Proposals.
  • Project Leads make Project specific decisions. Project leads can elect to adopt any decision making process, involving Project Contributors as Lead sees fit.

What does the Core DAO decide on?

The Core DAO makes decisions that fall within the Core DAO scope. This includes:

  • Projects. Which Project proposals are approved.
  • Promotions/Demotions. Promoting Contributors to Core Members and demoting Core Members to Contributors.
  • Core DAO Structure. Changes to the Core DAO structure.
    • This includes changes to this rulebook or any other DAO ratified document.
  • Miscellaneous A vote may be called for when significant changes are proposed to a DAO shared resource.

What does a Project DAO decide on?

Project DAOs are responsible for any and all decisions within the scope of a Project. The Project Lead has final decision making authority. Project leads can elect to adopt any decision making process, involving Project Contributors as they see fit.

Project DAO decisions include:

  • Adding and removing members
  • Modifying roles within the Project
  • Minor to moderate changes to the scope of the Project, driven by client needs
    • Larger changes should be brought to the Core DAO and may require a new Project
  • Arbitrating disputes between Project Contributors
    • Disputes involving Project Lead should be brought to the Core DAO for arbitration

Core DAO Decision Making Process

For Non-Emergency Decisions

  • Core Members meet for weekly Core DAO Masons meetings.
  • Items are added to the meeting agenda throughout the week prior.
  • Core Members are expected to have reviewed the agenda before the meeting.
  • Core Members are expected to have reviewed any items that are being voted on before the meeting.
  • Items in the agenda are ordered by priority and time sensitivity.
  • Core members discuss each item in the agenda as time permits.
  • If there is soft consensus on the terms of the item, the DAO makes a Moloch Proposal and votes it through.
  • As a general rule, any Moloch Proposal that has not followed the decision making process should be voted down.

Deeper Discussions and Disagreements

  • If there is no consensus on an item, or the subject requires further exploration, a member can request that we create a discussion thread on the DAO's forum. This is known as a Discussion Period.
  • All Discussion Periods have a deadline (usually 1 week)
  • The DAO can extend the discussion deadline if there is soft consensus to do so.
  • If the DAO finds a compromise by the end of the deadline, the DAO makes a Moloch Proposal with any new changes applied, and votes it through.
  • If there is still disagreement, a member can request a Resolution Meeting to discuss the item. This meeting should not be the Weekly Core DAO Masons meeting. It should be a meeting that is called specifically for this decision. All Core Members should attend.
  • If there is still disagreement after this meeting, the DAO can choose to continue to schedule Resolution Meetings until a compromise is reached. They should only do this if there is soft consensus to do so.
  • However, after the first Resolution Meeting, any Core Member can elect to force a decision by creating a Moloch Proposal. This is meant to safeguard against the DAO getting stuck in governance/meeting hell.
  • Resolution Meetings should only be used for decisions that are non-time sensitive and complex in nature. We expect the DAO to able make most decisions quickly.

Red Alerts/Emergency Decisions

  • Any Core Member can raise a Red Alert if they feel that a decision needs to be made immediately (ex. an attack or exploit)
  • Every Core Member is required to have a contact method that guarantees a response within 12 hours.
  • Every Core Member is required to delegate their shares to another member in cases where they will be away from their computer for an extended period of time (ex, vacation).
  • A meeting will be scheduled within 12 hours of the Red Alert being raised. All non-delegated Core Members are required to attend regardless of whether or not they think the issue is urgent.
  • The meeting is not over until the issue is resolved or an action plan is initiated.
  • In the case of attack, all DAO operations are suspended and all Core members are required to focus on resolving the issue.
  • Once the issue is resolved, the DAO resumes normal operations.
  • If a member feels that another member has abused the Red Alert system, the DAO can vote to demote the member in question.

Governance Backlog

  • To ensure timely decision turnaround times for our clients, External Project Proposals should be prioritized in the agenda for the Core Masons Meeting.
  • If there are any Project Proposals in the backlog, Core Masons need to schedule or extend meetings until they are all cleared.
  • Meetings should be structured so that all or most items in the backlog get a reasonable amount of the allotted time so they can be moved to a forum discussion if needed.
  • If the DAO has a large backlog of non-project decisions to make, they should schedule more Core Masons meetings until the backlog is cleared.
  • If this happens frequently, the DAO should assess the Core Mason Meeting process and evaluate its overall efficiency, and make changes where needed.
  • At no point should any decisions be allowed to sit in the backlog for more than 2 weeks without being addressed.

Current State of This Page

  • Empty
  • Rough Draft
  • Editing passes: 1
  • Final Draft
  • Ratified