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