DGF workflow
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.
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
The basic DGF workflow is as follows:
- A public customer uses the public UI to find the most current work smart contract (WSC), both of which are contained in the Forum.
- Customer encumbers the appropriate $ fee and selects relevant parameters to engage the WSC.
- WSC randomly selects a worker from the DAO from amongst the available experts who have encumbered REP tokens in availability smart contracts (ASCs).
- Selected worker completes job offline, then completes the requirements of the WSC.
- 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.
- 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
- Police experts' execution of the WSC through automated votes (executive governance)
- Register approval of proposed changes to DAO protocols through deliberate votes (legislative governance)
- 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
- Task-based, revenue-generating work
- Expert stakes REP to register availability
```mermaid graph
subgraph EOA
expert(Expert)
end
subgraph Contracts
availability(availability)
end
expert -- 1. Stake ℝ --> availability
```
- 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
```
- 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
```
- 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
```
- 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
```
- Internal operations
- Expert starts new DAO
```mermaid graph
subgraph EOA
expert(Expert)
end
subgraph Contracts
forum(Forum) pool(Pool)
end
expert -- Post --> forum expert -- Fee $ --> pool
```
- 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
```
- 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
```