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.

Specifications

1. Task-based, revenue-generating work

1. 1. Expert stakes REP to register availability

```mermaid graph

subgraph EOA

 expert(Expert)

end

subgraph Contracts

 availability(availability)

end

expert -- 1. Stake ℝ --> availability

```

1. 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. 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. 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. 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. 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. 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. 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 ```