Hi all
Following this week meeting with lawyer we must start working on the MIDAO Governance Structure so we can launch it and are legally able to receive the Foundation’s assets.
The MIDAO legal framework allows us to bypass the classic slow, expensive corporate paperwork. Instead, our reality will be essentially driven by a Radix dApp On-Chain Governance Registry that [in the beginning] will points to flexible, community-written rules hosted on GitHub.
We don’t need a 100-page corporate contract, we need a “Minimum Viable DAO” (MVD), a lightweight, flexible set of starting rules that we can upgrade independantly over time.
We need at least one lead by topic, so some developers, governance thinkers, and writers to build this as a community. Here are the three main areas to tackle together:
1. The Governance Documents (The “Minimum Viable” Rules)
The Goal: We need to draft a few core markdown (.md) files on GitHub. These documents will act as our starting Operating Agreement. They don’t need to be perfect; they just need to be clear and protect the community.
What we need to write (The MVD Checklist):
- The Charter: A document stating our mission, the DAO’s purpose (including matching the Foundation’s requirements to the funds release), and our own core values.
- Roles & Bindings: A clear definition of what the different “Members” are, what the “RAC” (Radix Advisory Council) is, and what powers/liabilities are at each level.
- Temporary Provisions: Specific, temporary rules needed purely to execute the handover from the Foundation smoothly.
- Checks & Balances: The emergency brakes. If a RAC multi-sig signer goes rogue or AFK, or the network goes down, what is the exact process to still move forward?
- Voting Mechanism: How the Radix consultation dApp should be used and its different threshold.
- Update pipeline: See part 3 of this post.
- Reputation Mechanism: A lightweight system to define how we weight trust in our community over time so the right voices are elevated in decision-making or funds granted.
- Some Lexicon: So we all speak about the same things.
Any other topic ?
2. The dApp Registry (The On-Chain Engine)
The Goal: We need a few developers to build the official “MIDAO board” on the Radix ledger. This dApp REGISTRY will hold the official topics and their links pointing to the GitHub documents we write above, with the following rough specs:
- Values to store:
Categoriesto map all the different documents (e.g., “The_Charter”) to aLink(its GitHub URL),Versionnumbering for potential audit,Commentswhere we can summarize the change. This proves to the law exactly what our rules were on any given day. - Access Control: Only authorized badges (the RAC multi-sig) can update the registry data, to enforce a community vote (add a category, add a line in a category).
3. The Update Pipeline & UI
The Goal: We need a simple process for how these rules actually evolve, and a place for everyone to read them.
What we need to build:
- The Amendment Process: We need to define the pipeline for upgrading one of our DAO category. (a Draft PR on GitHub => Community Vote => RAC must push the github commit + update registry data ?) and document it.
- The Code: code used by RAC (voting process, badges, multisig etc.) will have to be opensourced for community check and trust.
- The Dashboard: A simple frontend first (github?) that displays the community current active rules and history of past changes, and how to check the dApp registry with console for confirmation, and opensourced used code.
Please let’s break these into distinct working groups so no one is overwhelmed. We are building a light flexible quick system in the beginning, that must be easily iterable, not a rigid corporation.
- Writers: Let’s start a group for the documents.
- Strategists: One group dedicated to the update process.
- Scrypto Devs: Let’s refine the RAC badges, multisig, and REGISTRY dApp architecture with its history.
Please drop a comment below with which area you’d like to jump into, and let’s get our DAO ready for handover!