Validation Pool

The Validation Pool is the mechanism for minting new REP tokens and holding REP-weighted votes to determine their distribution in the DAO. The Validation Pool smart contract (VPSC) is the primary mechanism for governing a DAO under DGF. VPSC and the Forum form the core of the back-end software of DGF. A new instantiation of the Validation Pool is called to register consensus on each assertion made in the DAO.

A Validation Pool is analogous to a betting pool, in that members may register their votes with REP tokens, then, in a binding vote, those voting for the losing side have their REP tokens redistributed to the winners, proportionally. However, it must be stressed vehemently that when votes are binding, a Validation Pool should always result in unanimous agreement. A binding vote where any member loses REP indicates the DAO is not healthy--i.e., there is serious disagreement about protocols or the canonical viewpoint of the decentralized network, or there are Byzantine actors. Such redundant and inefficient displays of unanimity are held merely to motivate, define, and demonstrate consensus in a decentralized network. Binding votes are held to ensure the decentralized viewpoints of diverse nodes are in agreement. Non-binding votes are also held, for the purposes of deliberative legislative governance when unanimity is not expected.

The Validation Pool is the mechanism which institutes weighted-democratic governance in DGF. The will of the DAO membership is registered through votes weighted by REP tokens. Weighted votes means a member with twice as many REP tokens has twice as much power to influence the outcome of a vote.

In executive governance the Validation Pool is used to police posts in the Forum with binding votes. In legislative governance the Validation Pool registers the will of the group on proposals posted to the Forum in a sequence of votes that move from non-binding to binding. In judicial governance an older post in the Forum can have its REP value reviewed and changed by adding a new post which references it positively or negatively, as long as the new post is successfully validated by the VPSC.

The Validation Pool mechanism is necessary to ensure consensus and harmony in a decentralized environment. However, processing and recording the transactions of every member using their REP tokens to validate every official action the DAO makes is maximally redundant, extremely inefficient, and currently very expensive using blockchain technology. Before the age of modern computing, this is the reason that absolute decentralized governance was completely impractical. There needed to be a centralized authority in charge of soliciting and recording votes on decisions. With the speed and capacity of contemporary information technology it is now conceivable that every single member of a DAO would have the storage, processing power, and bandwidth to execute and record a Validation Pool. The Bitcoin network demonstrated an architecture for decentralizing power to every single node in a global network. Each node in the Bitcoin network redundantly checks the validity of every single transaction that ever happens in the entire history of the network.

However, in order to keep track of every single official action that a DAO takes, current technology is insufficient to the task of enabling the full functionality of a for-profit DAO -- at least not one that is sophisticated enough to compete with a centralized corporation. Therefore, off-chain roll ups are currently required to make continual Validation Pool executive governance feasible at the scale of a global DAO.

Specification

Overview

The VPSC is the primary component of the DGF workflow. An instantiation of the VPSC is called a Validation Pool. A Validation Pool takes as initial input a new post's address in the Forum, a cash fee, and a type of REP token to be minted. VPSC returns newly minted REP tokens. In addition each owner of REP tokens specific to the domain of the post may encumber their tokens and vote up or down on the post. VPSC redistributes the new REP and the encumbered REP as described below.

Let ${\textstyle R_{T}}$ denote the total number of reputation tokens in a DAO with $n$ experts $e_{k}$ for $0\leq k\leq n-1$. An expert is defined as anyone who owns a REP token. Let $R_{k}$ denote the number of tokens owned by expert $e_{k}$. So ${\textstyle R_{T}=\sum _{k=1}^{n-1}R_{k}.}$

Mint new REP

When VPSC is called, the fee $\$f$ is encumbered, and $mf$ new REP tokens are minted of the type specified. The parameter $m$ is called the minting ratio, which determines the proportional number of REP minted to the fee, as set by the DAO.

Vote

The original poster (O.P.) sends their post to the forum associated with the fee. The platform mints new reputation tokens proportional to the fee. ½ of the newly minted tokens are staked for the O.P. as an upvote, ½ are staked as a downvote, then the rest of the experts are allowed to evaluate the post and participate in the betting pool.

VPSC then encumbers default $c_{2}=1/2$ of the newly minted tokens in the poster's name as an upvote, and encumbers $1-c_{2}=1/2$ of the newly minted tokens as a downvote, left unassigned to any owner until the completion of the smart contract. The $c_{2}$ fraction of the new tokens is thus given to the worker who put their evidence of work in the post. The remaining $1-c_{2}$ fraction of the new REP tokens is given as a reward for participating in policing.

VPSC then allows each expert $e_{k}$ to encumber any of their REP tokens (of the proper type) with an input $v_{k}$ of upvote ($v_{k}=+1$) or downvote ($v_{k}=-1$) or default abstention ($v_{k}=0$). Once the voting period is finished, VPSC counts the votes by calculating the vote total ${\textstyle V_{T}:=\sum _{k=1}^{n-1}v_{k}R_{k}.}$ If $V_{T}\geq 0$ that means the total REP used to upvote ${\textstyle R_{U}:=\sum _{\{i|v_{i}>0\}}R_{i}}$ outweighs the total REP used to downvote ${\textstyle R_{U}\geq R_{D}:=\sum _{\{i|v_{i}<0\}}R_{i}.}$ This means ${\textstyle V_{T}=R_{U}-R_{D}.}$ Therefore if ${\textstyle V_{T}\geq 0}$ the post is validated. If $V_{T}<0$ then the downvote wins and the post is invalidated. (The fact that ${\textstyle V_{T}=0}$ results in validation reflects the almost arbitrary decision that ties will always favor the upvotes.)

In this example the upvotes on the evidence-of-work post win with 90 tokens against 80 staked as downvotes. The original poster’s (O.P.) newly minted 50 added to a supporter’s 40, against the 50 newly minted downvote tokens added to 30 tokens cast as downvotes by detractors. The losers’ 80 tokens are split between the O.P., who receives 50/90 of the 80 lost tokens, and his supporter, who receives 40/90. Then the post holds a record of how popular it was amongst experts to determine the post’s power as precedence.

Redistribution: binding vs. non-binding

The newly minted tokens on the losing side are distributed to the winning side proportionally. I.e., if upvotes win, each expert voter $e_{j}$ with $v_{j}>0$ receives ${\textstyle {\frac {R_{j}}{R_{U}}}mf(1-c_{2})}$ of the new tokens. If downvotes win, each voter $e_{j}$ with $v_{j}<0$ receives ${\textstyle {\frac {R_{j}}{R_{U}}}mfc_{2}}$ of the new tokens. In that case, those tokens were taken from the poster whose post was invalidated. This proportional arithmetic ensures that someone who risks twice as many REP tokens on an assertion earns twice as much reward if they win.

A VPSC can be binding or non-binding. If an instantiation of the VPSC is binding, that means the REP tokens of all those who voted against the winning side will lose the tokens they encumbered to those who won, proportionally. E.g., if the post is validated, then all the REP used to downvote ${\textstyle R_{D}}$ is redistributed to those who upvoted, meaning each voter $e_{j}$ with $v_{j}>0$ receives ${\textstyle {\frac {R_{j}}{R_{U}}}R_{D}}$ new tokens.

Further, a VPSC can be $p$-binding for any $0\leq p\leq 1$. A $p$-binding VPSC redistributes the fraction $p$ of the losers' tokens to the winners.

REP salary

Finally, the Validation Pool takes the fee encumbered from the beginning and distributes it to all DAO members in proportion to their REP token holdings. The proportionate REP salary means someone who owns twice as many REP tokens gets twice as much cash reward from the fee. Specifically, expert $e_{k}$ who owns $R_{k}$ tokens gets a reward of $fR_{k}/R_{T}$.

Pseudocode

An instantiation of VPSC flow on Ethereum is described as follows:

1. Accept three initial inputs :                        #Usually the inputs come from the Work Smart Contract

• Address of a Forum post.                         #This address in the Forum typically holds the information that the Validation Pool is called to vote on. It also typically includes pointers to previous posts in the Forum, i.e., references. In this case the post is associated with a type of REP, which is the root post in the sub-DAG determined by the pointers. If no pointer is included, it is a root post and therefore a new expertise tag. An expertise tag is simply the address of the Ethereum transaction that is a root post, but it will also have a human readable name such as E500. If a pointer is included, the post is a new leaf on an existing expertise tree.
• an ether-based fee. #The fee would ideally be denominated in a robust stable coin to give the DAO business predictability.
• REP. #The REP is typically the Worker's REP which was encumbered from the ASC and sent to the WSC according to DGF workflow.
  

  Flowchart for Ethereum instantiation of pseudocode

2. Mint new reputation tokens in the relevant type of REP tag in proportion to the amount of the fee.  

  #For example, if the human readable name of a DAO's expertise tag is E500, the newly minted tokens in E500 will be ERC-20 tokens of the type XRP-E500.

3. Stake half the new reputation tokens in the poster’s name along with the other optional reputation tokens the poster sent as an upvote bet. Stake the other half of the newly minted tokens against the post as a downvote. #This choice of ${\textstyle p=1/2}$ stake is a tunable parameter in the full version, subject to governance.

4. Broadcast the opening of the betting pool to the network.     #This means the address of the post (and automatically, therefore the relevant expertise tag) is broadcast with a deadline for submitting relevant reputation tokens as upvotes or downvotes on the post. The deadline is another tunable parameter, subject to governance

5. Collect, count, and compare the upvote and downvote reputation tokens to decide the winner. #See above specifications.

6. Publish the result and distribute the reputation stakes from the losing side to the winners, weighted according to stakes.

7.    Distribute the remaining ether fee (after paying necessary gas) as the REP salary to all owners of REP tokens in the expertise tag, weighted according to their holdings.

Consequences

The Validation Pool can be set to binding or non-binding votes to serve the function of executive or legislative governance.

Binding votes and executive governance

Main article: Executive governance

A binding vote means the effects of the proposal will be automatically implemented, typically with smart contract execution. A tightly-coupled vote means the voters' REP tokens ownership will be affected by the outcome of the vote--if their assertion fails, the voter loses their tokens. For stability, a member should only lose REP when they violate the established norms of the DAO. Tightly-coupled votes, therefore, should be used only for policing previously ratified protocols.

Binding tightly-coupled votes are only used for executive governance, meaning policing. Policing should be automated as much as possible, so that the members' UIs vote correctly every time. This means that almost always, executive governance is expensive, inefficient, and extremely redundant. There is continual communication between every member of the DAO using REP-encumbered transactions in order to hold seemingly meaningless unanimous votes on every official action the DAO performs. Unfortunately, this is the necessary cost for decentralization. Since no centralized authority exists to govern the behavior of the group, everyone in the group must govern the behavior of everyone else. Unanimous votes are not meaningless in the decentralized context; they are necessary to establish consensus in an environment with no central authority. In a decentralized network there is no natural canonical view of the network. Due to latency in the gossip network different members will have different views of the order in which transactions were proposed. The Validation Pool creates an artificial canonical view of the transactions in the network that the DAO decides are important.

The only time such executive governance policing will result in a vote which is not unanimous, is when a member is not running the most current canonical version of the UI. The canonical UI holds up-to-date standards for behavior and the correct versions of the newest approved smart contracts. Executive governance policing is required to prevent Byzantine behavior. Byzantine behavior includes editing the UI to change the way the member votes in a Validation Pool, or editing a smart contract to improve the outcome for the Byzantine actor.

Policing needs to be funded by sharing ${\textstyle mf(1-c_{2})}$ of all the newly minted REP tokens that the DAO ever generates. This cost motivates maximal participation to ensure policing is decentralized. This solves the nothing-at-stake problem in distributed computing. See REP tokenomics for an analysis of the cost of policing, based on the choice of parameter ${\textstyle c_{2}}$. The basic idea is to choose ${\textstyle c_{2}}$ large enough so that the cost of running the hardware is sufficiently remunerated. The second motivation for choosing ${\textstyle c_{2}>0}$ is to pay members for automatic participation in the DAO to decentralize power.

Non-binding votes and legislative governance

Main article: Legislative governance

On the other hand, a non-binding vote means the DAO intends to implement the result of the proposal, but that is not hard-coded to automatically execute. A loosely-coupled vote means the opposite of a tightly coupled vote--if their assertion fails, the voter will not lose their tokens. This mechanism of non-binding votes encourages authentic deliberation in the course of legislative governance. The basic idea is to encourage timely adoption of carefully considered protocol updates through a series of Validation Pools, moving from loosely-coupled votes to tightly-coupled votes, through a series of $p$-votes as $p$ is programmed to move from 0 (loose) to 1 (tight). The loosely-coupled votes are voluntary polls of proposals intended to elicit authentic opinion. The tightly-coupled votes ensure validated protocol updates are official, since binding Validation Pools force unanimity.

By using a final vote which is binding, everyone who participates registers the same opinion by algorithmic force, since minority dissent is punished by loss of tokens. Consensus is assured even if it is merely tacit acceptance. It is obviously not ideal to stifle those with differing views. But it is occasionally necessary for the decentralized body to require a timely choice in order to react to an emergency in the changing market.

????

Table ?? holds a summary of this thinking. Binding Non-binding Rigid Non-contentious post & tightly-coupled (E.g., work-evidence post, mandatory plebiscite) Non-contentious post & loosely-coupled (E.g., poll of consensus on established precedent) Flexible Contentious post & tightly-coupled (E.g., forcing consensus on protocol development) Contentious post & loosely-coupled (E.g., protocol development poll, advisory referendum)

Domain-specific REP

One post can be reposted multiple times with separate fees in order to mint multiple types of REP. This is useful when a post is meaningful in multiple different domains. As an example, ??

See also

• Governance
  • Executive governance
  • Legislative governance
• Roll ups