DAO Governance Framework

The DAO Governance Framework (DGF) is a software framework for building DAOs by providing a governance structure. An essential aspect of any organization is to specify the protocols governing acceptable member behavior. In a primary DAO it is especially important that these protocols be formalized and automated with open source smart contracts processed by distributed computing. Governance is the process of specifying and updating these protocols.

DGF gives DAO founders the template structure to formally specify the protocols for 1. work flow, 2. review procedures, and 3. the process for updating the protocols, themselves. These are alternately described as 1. executive, 2. judicial, and 3. legislative governance, respectively.

The most important function of a DAO, work flow, determines the reward mechanism. The work flow process answers the question of why anyone would ever choose to participate in a DAO. The failure to build sophisticated and balanced incentive mechanisms is the primary reason for the failure of any DAO. DGF relies on reputation tokens (called REP) for all its governance mechanism. Reputation tokenomics analyzes the meaning, value, and security of any REP token design.

Specific examples of DAO instantiations using DGF are growing.

System Design

The DAO Governance Framework (DGF) project uses blockchain technology to make decentralized business possible. To do this, we provide tools to build DAOs. DAOs require IT tools to facilitate their decentralized governance. The core tool of decentralized governance is a meaningful and secure reputation token, REP. The core mechanism of REP tokens in DGF is: 1. REP is minted and given to the person who brings $ to the DAO. 2. The $ doesn't go to the person who earned it; $ is distributed proportionally to everyone who previously has earned REP.

The pages in this wiki explain the consequences of using this type of REP token for building DAOs. How it solves the problems with current blockchain initiatives. How DGF makes business and social collaboration more efficient. How REP-focused governance can create a system that promotes human flourishing, materially, socially, and spiritually. And how such lofty and abstract values can persist in a system that is simultaneously built from cold, hard, algorithmic execution of digitally codified business and civil contracts.

In order to optimize for collaboration and community participation, we will be focusing early on modular, sharable specifications. There are elements of the dynamic framework that are common to a wide variety of specific instantiations of DAOs. This common subset forms what we refer to as Minimum Viable Protocol Requirements (MVPR).

DGF MVPR refers to the specification of an algorithm that implements the governance framework described in and .

We conceptualize an MVPR DAO as the Bench of experts who provide some service to the public, together with their Forum. Experts are members of the DAO, determined by ownership of REP tokens. REP tokens are digital representatives of reputation for doing the expert work of the DAO. REP tokens serve as the basis of power in the DAO. The Bench is defined as the list of experts. The public is defined as all nonmembers of the DAO, conceived of as potential customers that the experts intend to serve for fees. The Forum is the evolving history of accepted and rejected actions the experts perform.

In an MVPR DAO, REP tokens confer on each expert the power to do work and governance:

• Work: Providing official DAO service to the public for fees. Fees are fungible cash money, typically in the denomination of some stable coin.

• Governance
  • Executive: Automated policing of peer work
  • Legislative: Debating and voting on updates to DAO operating parameters and smart contracts (hard protocols), and cultural norms (soft protocols)
  • Judicial: Reviewing past actions and decisions by revaluing the Forum

Common to all these domains is the power accounting feature of REP ownership. REP is gained by peer validation and staked upon assertions.

DGF workflow

Main page: DGF workflow

The DGF system is designed as a feedback loop consisting of three major components: 1. the Forum, 2. the collection of members of the DAO, called the Bench of experts, and 3. the public, consisting of non-member users of the system who pay fees to the DAO for work.

The basic DGF workflow is as follows:

1. A public customer uses the public UI to find the most current work smart contract (WSC), both of which are contained in the Forum.
2. Customer encumbers the appropriate $ fee and selects relevant parameters to engage the WSC.
3. WSC randomly selects a worker from the DAO from amongst the available experts who have encumbered REP tokens in availability smart contracts (ASCs).
4. Selected worker completes job offline, then completes the requirements of the WSC.
5. WSC publishes evidence of completed job to a post in the Forum, opens an instantiation of the Validation Pool.
   
   • WSC sends address of post and public customer's $ fee to an instantiation of the Validation Pool (VP)
   • VP mints new REP in proportion to the $ fee.
   • 1/2 of new REP is staked in worker's name as an upvote. 1/2 staked as a downvote, unassigned.
   • VP broadcasts voting is open to REP staking on betting pool.
   • VP tallies the vote, decides the winner.
   • VP publishes the result & distributes REP tokens from losing side to the winners, weighted according to stakes.
6. The $ fee is distributed to all DAO members in proportion to REP holdings (REP salary).

Smart Contracts

• Availability smart contract (ASC): Enables DAO participants to declare their availability to produce work by staking REP

• Work smart contract (WSC): Evolving official protocol for how the DAO provides service to the public. Enables public users to request work products from the DAO. This WSC accepts certain parameters that will function to specify the proposed agreement, including the standards for fees the public pays, the mechanism for selecting the expert from the active ASCs, the standards for acceptable work, the mechanism for recording evidence of work to the Forum, and the code calling for a Validation Pool to verify successful completion of the WSC.

• Validation Pool smart contract (VPSC): Mechanism for DAO experts to vote weighted by REP ownership in order to
  1. Police experts' execution of the WSC through automated votes (executive governance)
  2. Register approval of proposed changes to DAO protocols through deliberate votes (legislative governance)
  3. Review past actions (judicial governance)

The Validation Pool is the heart of DGF as it mints all new REP tokens and performs their initial distribution. Finally the Validation Pool distributes the fee from the WSC to all members of the DAO in proportion to the ownership of REP. This is called the REP salary.

• Forum smart contract (FSC): Records the history of the DAO as a linked list of documented official DAO expert actions. Links are weighted references, positive or negative, that donate or leach REP from the post referred to. Gives the context for discussion on modifications to the DAO.

UI Software

Main article: Front-end software

A DAO must have software that allows the public and its experts to access its capabilities. UIs therefore have two faces. This software provide a view of the Forum that enables its respective audience to interact for their respective purpose. Primarily, experts use their UI to engage their REP holdings to secure work and to govern the DAO. Secondarily, experts use their UI to search the Forum for pressing issues in governance. The public primarily uses their UI to engage experts by encumbering fees in Work Smart Contracts. Secondarily, the public uses their UI to search the Forum to find the WSC and evaluate whether the DAO's reputation is sufficient to warrant their business.

Ideally the UI software would be formally governed by each DAO itself. However, pseudonymity and openness makes this impractical to enforce. Individuals can engage a distributed database with any UI they choose. Thus competing UIs are likely to emerge in most DAO instantiations. DGF simply provides recommended defaults on out-of-the-box UI software, and allows each DAO to choose their minimal canonical UIs.

In its purest, ideal form this system would support stateless client applications, serving all operational data reliably from blockchain storage. However, blockchain storage is currently expensive; so in practice, we can only use it in cases where we require the long-term guarantee, such as the REP ownership list.

This means that we must implement a separate, off-chain stateful layer. There are a variety of options for this off-chain data layer such as IPFS. For now we merely specify that such a layer must exist.

There are both formal and informal processes – hard and soft protocols – associated with each of the above outlined areas of power. Hard protocols are specified by code, and enacted by running systems, whether on or off chain. Soft protocols refer to patterns of participant behaviors.

Key Concepts

Reviews

Main pages: Executive governance & Judicial governance

A goal of the DAO is to deliver quality results to its customers. To achieve this, experts submit work products for review by other experts within the DAO. This is executive governance which is implemented through the Validation Pool mechanism. These reviews, as well as the review process itself, are subject to future review under judicial governance which is implemented primarily through Forum reference mechanisms.

Governance

Main page: Governance

The MVPR parameters are designed to allow customization of the rules that govern the operations of the DAO.

Reputation

Main page: Reputation

DAO participants shall be awarded with reputation tokens for contributions which the other DAO members deem valuable.

Reputation token types should be specific to the relevant domain of action. For instance, a typical primary DAO begins with three distinct kinds of reputation:

• REP - Work product reputation
• gREP - Governance reputation
• cREP - Comment reputation

REP is associated with a work product. When members do work directly with the public they receive REP tokens. Usually, REP value is minted in proportion to the fees the worker earned for the DAO.

gREP is associated with proposals to modify the DAO's governance parameters. This is what we consider governance of the hard protocols in the system. gREP may be staked toward new proposals. Successful proposals shall attribute new gREP to their authors and supporters. It is likely that there will be a close relationship between gREP and REP since successful workers will likely have the best understanding about how to improve a DAOs protocols for work. In this case there is no need for a distinction in many DAOs.

cREP plays an important role in the soft protocols governing the organization. Fundamentally a DAO is a group of individuals. Their behavior will be shaped partly by the communication that occurs among them. Comments will be a central vehicle for this communication. Each organization may develop its own ways of associating meaning with comments. An organization may want its participants to be able to stake their own reputation toward promoting particular comments, and toward suppressing others. Our goal is to enable each community to articulate its own values, in a way that is transparent for the community as well as the public to observe.

cREP is the most difficult REP token to valuate. A typical comment will likely be submitted without any associated cash fees when they are first posted in the Forum. DGF has options for DAO founders for making an initial protocol for valuing such tokens which do not have the grounding value of cash money. For instance a variation on the PageRank algorithm can be used to weight the Forum's WDAG based solely on the strength of edges without requiring weights of nodes. However, before any type of REP token is grounded with the concrete meaning gained by being associated with money, the system is particularly susceptible to gaming. The basic PageRank algorithm, for instance, can be gamed by spamming the Forum with self referential posts driven by sockpuppets.

Distributed computing perspective

Since a primary DAO is an open permissionless decentralized network, Byzantine resistance is the primary design consideration. Any network node has the ability to spam the network with any information they choose. A Byzantine node cannot be prevented from editing any software it uses before communicating with the network. So a decentralized network's protocols must involve checking every message for consistency and integrity. The only defense against such behavior is to ignore Byzantine messages that don't accurately encumber valuable tokens or to slash the tokens encumbered in a Byzantine message which does encumber tokens.

For instance, in DGF workflow, we assume every full node in the network behaves in a similar manner to a full client in the Ethereum network. In Ethereum, a full node participates in the distributed computing architecture called EVM as follows. The node first downloads the entire history of the blockchain – every transaction (TX), every smart contract (SC), every record of how much ether was submitted to run each smart contract, and every output of every smart contract so engaged. A full node has its own database of the entire collection of all ERC20 and ERC471 tokens that have ever been minted and their complete history. A full node refers to this information to determine the validity of every TX request to fulfill a new transaction on the Ethereum network. This means that any Byzantine action is ignored or punished according to protocols that have previously been established by the Ethereum network.

By analogy with Ethereum's EVM flow, in DGF a full node downloads the entire history of the DAO (the Forum) and parses the value of every REP token, in order of creation, by calculating their values according to the changing rules whose history is encoded in the Forum. A record of every successful Validation Pool is required, as well as the rules for what is a successful Validation Pool at the time it was called. For instance, a Validation Pool has a quorum necessary for it to be considered a canonical instantiation that leads to its inclusion in the Forum. The quorum will change as the DAO evolves. The larger and more decentralized that the DAO becomes, the smaller the quorum needs to be in order to maintain security against Byzantine actions.

This counter-intuitive perspective of maximally redundant computation is necessary to maintain the decentralized structure of the network in the inevitable presence of Byzantine actors.

Notes about Implementation

These reputation mechanisms will be encoded as smart contracts. Such contracts run on a block chain and thus provide a resilient, distributed ledger where we can store the records of group participant activities.

It will be necessary to build software tooling that is capable of constructing a consensus view of the state of the DAO. This will need to access block-chain data encoded by the smart contract(s) as they ran at the time each block was written. The smart contracts themselves may change over time. Our goal is to encode these changes such that it is possible to reconstruct the entire computational history of the DAO. To maximize the flexibility of our initial contract, we will implement a set of hyper-parameters. In other words, the smart contract will express a dynamic algorithm; by changing the parameters of the algorithm, the behavior of the algorithm can be modified.

Broadly speaking, upgrading the underlying smart contract itself produces a hard fork. The best case for such a scenario is that the new contract is (sufficiently) compatible with the previous, and that all participants are able to upgrade to the new version in a (sufficiently) timely fashion. A design consideration for this project will be to attempt to reduce the probable costs of such a hard fork, by introducing some kind of internal versioning scheme for the blockchain code and data. TODO: Articulate the relative weight of this forward-compatibility consideration versus the competing design goal of avoiding excess complexity.

Applications

The initial DAOs include applications devoted to some of the most relevant requirements for building a decentralized economy, including:

• Block production - DAO using REP to determine randomized block producer for blockchain consensus.
• Stable coin
• Arbitration DAO - parties may trigger 3rd party arbiter power by adding template language to any smart contract - allows appeals for any smart contract
• Roll ups
• Gig jobs
  • Software Review DAO
• Oracles
  • DeNM - The decentralized news media network.
• deFi
  • Banking rollup DAO
  • Underwriting
  • Marketplaces
    • ForEx
    • Commodities
    • Equities
    • Derivatives
  • Chit fund - A decentralized and global approach to the banking functions of investment, loans, and insurance using a generalization of the traditional chit fund scheme.
• Social collaboration
  • Science Research Organizations
    • [Peer to Peer Technology](Peer-to-Peer-Technology) - The decentralized society for research, development, and sharing of P2P tools.
    • [Decentralized Governance](Decentralized-Governance) - The decentralized society for analysis and development of new approaches to the organization and guidance of decentralized networks.
  • Social organizations
    • Grants
      • Scholarships
      • Poverty relief
    • Community policing
    • Social harmony
  • AI governance

Resources

We are using GitLab Issues to track the concrete steps we are taking in assembling this system. For more information see SD-1.

This wiki is to be maintained as an introduction to the project. See SD-2.

Associated Projects

We rely on previous open source P2P tools such as blockchain and distributed hash tables:

• Ethereum
• IPFS
• Casper

We also learn from other projects working to develop P2P-enabled decentralized governance:

• Cardano

Code

This project is a pilot implementation (SD-4) of a framework (SD-3) for dynamic self-governance of DAOs (decentralized autonomous organizations).

Platform Operations

High Level Sequence Diagram

• Editable
• Presentation mode

See Also

• DGF project
• Governance philosophy
• Guiding principles
  • Individual code of conduct
  • Group governance code of conduct
• Contributors guide
• Ethical considerations
• Governance philosophy
• Gitlab Repo
• Comparisons with other platforms