DGF workflow

From DAO Governance Wiki
Jump to navigation Jump to search

DGF workflow is the core process that underlies the functioning of any DAO that uses the DGF system. 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 (customers). The interaction between these three components is DGF workflow: from the public downloading information about the DAO from the Forum, to the public using that information to engage work from the members of the DAO, to the DAO members analyzing and recording that work in the Forum.

DGFsystem.png

DGF workflow inputs $ fees from customers and outputs newly minted REP tokens distributed to DAO members who do off- and on-chain work, with a record of that activity in the Forum.

The following DGF workflow is a generic process that can be used iteratively in many different applications of DGF in any type of DAO to achieve decentralized governance of any type of work.

Process[edit | edit source]

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.
    DGF flow.png
    • 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[edit | edit source]

  • 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.
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.

Specifications[edit | edit source]

  1. Task-based, revenue-generating work
    1. Expert stakes REP to register availability

```mermaid graph

subgraph EOA

 expert(Expert)

end

subgraph Contracts

 availability(availability)

end

expert -- 1. Stake ℝ --> availability

```

    1. Public submits work request with fee

```mermaid graph

subgraph EOA

 expert(Expert)
 public(Public)

end

subgraph Contracts

 business(Business)
 availability(availability)

end

public -- 1. Request
with fee $ --> business business -- 2. Assign
work --> availability availability -- 3. Transfer
staked ℝ --> business availability -- 4. TODO Notify --> expert ```

    1. Expert submits work evidence

```mermaid graph

subgraph EOA

 expert(Expert)

end

subgraph Contracts

 business(Business)
 forum(Forum)
 pool(Pool)

end

expert -- 1. Work
evidence --> business business -- 2. Post --> forum business -- 3. Stake ℝ --> pool ```

    1. Peers validate the work evidence

```mermaid graph

subgraph EOA

 peers(Peers)

end

subgraph Contracts

 forum(Forum)
 pool(Pool)

end

peers -- 8. Stake ℝ --> pool pool -- 9. Validate post,
Transfer ℝ --> forum ```

    1. Rewards are distributed

```mermaid graph

subgraph EOA

 expert(Expert)
 peers(Peers)

end

subgraph Contracts

 pool(Pool)
 business(Business)
 forum(Forum)

end

pool -- Reward ℝ --> peers forum -- Award ℝ --> expert forum -- Award ℝ
via citation
WDAG --> peers business -- Award % fee $
weighted by ℝ--> expert business -- Award % fee $
weighted by ℝ--> peers ```

  1. Internal operations
    1. Expert starts new DAO

```mermaid graph

subgraph EOA

 expert(Expert)

end

subgraph Contracts

 forum(Forum)
 pool(Pool)

end

expert -- Post --> forum expert -- Fee $ --> pool

```

    1. Expert joins existing DAO

```mermaid graph

subgraph EOA

 expert(Expert)
 peers(Peers)

end

subgraph Contracts

 forum(Forum)
 pool(Pool)

end

expert -- 1. Post --> forum expert -- 2. Fee $ --> pool peers -- 3. Stake ℝ
to approve --> pool ```

    1. Expert submits governance post

A governance post can be considered one that is respected in some way by the operations of the [Client/UI](./client-or-ui.md).

This is a broad class of posts.

Each type of governance post can be individually (or by category?) handled by the business contract for a given DAO.

```mermaid graph

subgraph EOA

 expert(Expert)
 peers(Peers)

end

subgraph Contracts

 forum(Forum)
 pool(Pool)
 business(Business)

end

expert -- 1. Stake ℝ on
governance post --> business business -- 2. Post --> forum business -- 2. Fee $ from
internal fund? --> pool peers -- 3. Stake ℝ
to approve --> pool pool -- 4. Validate --> forum ```


See Also[edit | edit source]