Editing Validation Pool (section)

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