Editing Validation Pool (section)

== Consequences ==
The Validation Pool can be set to binding or non-binding votes to serve the function of [[Governance#Executive governance|executive]] or [[Governance#Legislative governance|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 [https://vitalik.ca/general/2017/12/17/voting.html 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 [[wikipedia:Byzantine_fault|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 <math display="inline">mf(1-c_2)</math> 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 [https://golden.com/wiki/Nothing-at-stake_problem-639PVZA nothing-at-stake problem] in distributed computing. See [[Reputation tokenomics#Policing|REP tokenomics]] for an analysis of the cost of policing, based on the choice of parameter <math display="inline">c_2</math>. The basic idea is to choose <math display="inline">c_2</math> large enough so that the cost of running the hardware is sufficiently remunerated. The second motivation for choosing <math display="inline">c_2>0</math> 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<ref>Vitalik Buterin introduced the terminology of binding and coupled votes in a blog post that is not available at the time of this writing.</ref> 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 <math>p</math>-votes as <math>p</math> 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, ??