Skip to content

Requirements

Governance

We identify three aspects of governence: Executive, Legislative, and Judicial. Executive governance is focused on the present, day to day operations of a DAO. Legislative governance is focused on the future, and deals with the process of making changes to the operations of a DAO. Judicial governance is focused on the past, providing an opportunity for a DAO to review and reinterpret past actions.

Core Contracts

The key insight of On-Chain Governance of Decentralized Autonomous Organizations (Craig Calcaterra, 2018) is to use Reputation as the primary incentive mechanism for DAO members, rather than relying on fungible currency alone as the representation of a DAO member's power.

Validation Pools mint and award Reputation (REP). REP can be used for staking for/against Validation Pools or staking availability to perform work, and entitles the holder to a share of DAO revenues in proportion to their REP balance.

Reputation

  1. The Reputation contract must be able to associate a non-negative numeric value with any given wallet address or contract address.

  2. The value associated with a given wallet address may be modified only by the results of a Validation Pool (explained below). The Validation Pool must be able to execute the following operations

    1. Mint: Increase the value associated with a given wallet address

    2. Burn: Decrease the value associated with a given wallet address

    3. Update (a.k.a. Transfer): Decrease the value associated with one wallet address, and increase the value associated with another address by the same amount.

  3. A Reputation holder must not be able to transfer Reputation to any other account.

  4. A Reputation holder must be able to stake some or all of their Reputation for or against a Validation Pool (explained below).

  5. A Reputation holder must be able to delegate permission to another account to stake a given amount of Reputation on their behalf.

Bench of Experts

The contract housing the Validation Pools can be thought of as a Bench of Experts. These experts sit ready to receive submissions and render a decision on each. The experts will stake their reputation on the soundness of their judgements.

  1. Anyone may initiate a Validation Pool

    1. A Validation Pool may be initated with or without a fee

      1. Reputation (REP) is minted in proportion to the submitted fee. If no fee is included, no REP should be minted.

      2. Half of the minted REP is staked in favor of the VP

      3. Half of the minted REP is staked against the VP

    2. A Validation Pool must include the following parameters

      1. Quorum (Between 1/10 and 1)

        1. For the Quorum to be met, the total amount of REP staked for and against the VP, divided by the total available REP in the DAO, must be greater than or equal to this ratio.

        2. Quorum must be greater than or equal to a minimum value, such as 1/10, in order to prevent validation pools from being pushed through without sufficient participation.

      2. Win Ratio (between 0 and 1)

        1. For a VP to be accepted, the amount of REP staked in favor, divided by the total amount of REP staked for and against the VP, must be greater than or equal to this ratio.

      3. Binding Percent (between 0 and 100%)

        1. This represents the amount of staked REP that may be lost if staked on the losing side of a VP. 0% Binding means that no staked REP may be lost. 100% Binding means that all staked REP may be lost. A value between these extremes means that a fraction of staked REP may be lost.

      4. Redistribute Losing Stakes (boolean)

        1. If Redistribute Losing Stakes is true, then the Binding % of REP staked on the losing side of the VP is distributed among those who staked on the winning side, in proportion to their stakes. If Redistribute Losing Stakes is false, then the Binding % of REP staked on the losing side of the VP is burned rather than being redistributed.

      5. Target Forum Post (explained in the Judicial governance section)

        1. The Target Forum Post represents the subject of the Validation Pool.

  2. A DAO member may stake Reputation for or against a Validation Pool after the pool is initiated and before the duration elapses

  3. Once the duration has elapsed, the outcome of the VP may be evaluated.

    1. If the Validation Pool is accepted,

      1. If Redistribute Losing Stakes is true, Binding Percent of losing stakes shall be distributed among DAO members who staked in favor of the VP, in proportion to their stakes.

      2. If Redistribute Losing Stakes is false, Binding Percent of losing stakes shall be burned rather than redistributed among the winners.

      3. The half of the minted REP that was staked in favor of the VP is awarded to the Target Forum Post.

    2. If the Validation Pool is rejected, and Redistribute Losing Stakes is true, losing stakes as well as the half of the minted REP that was staked against the VP shall be distributed among DAO members who staked against of the VP, in proportion to their stakes.

  4. After the Validation Pool concludes, the fee provided by the Customer shall be distributed among all DAO members (Workers) in proportion to their REP balance.

Executive

The day to day operations of a DAO are centered around Work Smart Contracts (WSC) and Validation Pools (VPs). Customers request work; the work is assigned to an available worker; the worker submits Work Evidence (WEV); and the Work Evidence is validated by the rest of the DAO in a Validation Pool.

Work Smart Contracts

  1. A Worker may stake reputation toward a Work Contract (WSC), representing their availability to perform the work.

    1. This availability stake should specify the duration of their availability window.

  2. A Customer may submit a request for work to the WSC, including a fee and any necessary request details.

    1. The work must be assigned to an available worker

    2. The worker may be chosen by random weighted selection, weighted by the amount of REP each worker staked toward their availability.

  3. The assigned Worker must submit a Work Evidence Post to the WSC, providing any necessary supporting information to verify that the work was performed correctly.

  4. The Customer must submit approval/disapproval of the work to the WSC.

  5. The WSC must initiate a Validation Pool targeting the Work Evidence Post.

    1. This Validation Pool may target a single WEV Post, or multile WEV Posts (see Rollup section, below).

    2. The fee from the Customer should be included when initiating this VP. The VP mints Reputation based on the provided fee.

    3. The Staking Clients must verify the work evidence, and stake for/against the Validation Pool targeting the Work Evidence Post.

    4. If the VP is approved, the minted Reputation is awarded to the Worker who submitted the Work Evidence.

    5. The VP then distributes the fee among all DAO members, in proportion to their Reputation balances.

Note that the Worker does not directly receive the fee for the work they perform. Instead, they receive Reputation; then, based on their Reputation balance, they receive a fraction of all future fees sent to the DAO. The purpose of this is to incentivize long-term considerations and investment in the future of the DAO. The more REP a Worker earns, the more they get payed over time, as the DAO takes in revenue.

Legislative

The DAO will need to be able to update the rules by which it operates, in order to respond to changing circumstances or goals. There will not always be unanimous consensus regarding what changes to make. Therefore, we need a legislative governance process that a DAO can use in order to progress from disagreement to agreement.

To achieve such a process, we introduce a Proposal mechanism. The proposal must first reach a certain level of Attestation; then it must progress through a series of Referenda. If all Referenda are accepted, then the Proposal is accepted; otherwise the Proposal is rejected.

Proposals

  1. Anyone may submit a Proposal

    1. Note that, if desired, this requirement could be strengthened such that only a DAO member may submit a Proposal

    2. A Proposal may include a callback, to be executed when and if the Proposal is accepted. This callback may also include opaque data to be passed to the callback when executed.

  2. A DAO member may attest a certain amount of REP to indicate that they are aware of the proposal. The amount must be less than or equal to the DAO member's REP balance.

  3. Once the Proposal has reached 10% Attestation, meaning that 10% of the DAO's total supply of REP has been attested, the first Referendum shall be initiated. This referendum should be a Validation Pool that is 0% binding, with a quorum of 1/10 and a win ratio of 2/3.

    1. If the Referendum does not meet quorum, then the Proposal is failed.

    2. If the Referendum is rejected or does not meet a 50% participation rate, then the Referendum may be retried up to 3 times.

  4. If the first Referendum is accepted and meets a 50% participation rate, then a second Referendum shall be initiated. This referendum should be a Validation Pool that is 1% binding, with a quorum of 1/10 and a win ratio of 2/3.

    1. If the Referendum does not meet quorum, then the Proposal is failed.

    2. If the Referendum is rejected or does not meet a 50% participation rate, then the Referendum may be retried up to 3 times.

  5. If the second Referendum is accepted and meets a 50% participation rate, then a third Referendum shall be initiated. This referendum should be a Validation Pool that is 100% binding, with a quorum of 1/10 and a win ratio of 2/3.

    1. If the Referendum does not meet quorum, then the Proposal is failed.

    2. If the Referendum does not meet a 50% participation rate, then the Referendum may be retried up to 3 times.

    3. If the Referendum is rejected, then the Proposal is failed.

  6. If the third Referendum is accepted and meets a 50% participation rate, then the Proposal is accepted.

    1. If provided, the callback should be executed. This can be used, for example, to update parameter values of a smart contract.

Judicial

In the Executive governance section we outline how the DAO polices the REP minting process, and the Legislative governance section we outline how the DAO may modify the rules by which it operates. Now, we need to consider that as the DAO develops new rules, it may wish to reevaluate past REP rewards in light of new perspectives.

To achieve such reevaluation, we introduce the Forum reference mechanism. The Forum is a collection of Posts. A Post has a unique ID and one or more authors. A Post may also include weighted references to other Posts. Each Validation Pool targets a given Post. When a VP is accepted, the minted REP percolates through the Forum, to the author(s) of the targeted Post, and recursively to the Posts referenced by the targeted Post, the Posts referenced by those Posts, and so on, up to a limit determined by the Reference Chain Limit parameter.

Each reference may be positive or negative. A positive reference "donates" Reputation, while a negative reference "leaches" reputation.

A Post may also reference the Incinerator. Any reputation donated to the Incinerator is burned. A Post may not leach reputation from the Incinerator.

Forum

  1. Anyone may add a Post to the Forum

  2. A Post must have a unique identifier.

    1. The Post ID should be a content hash.

    2. The Post ID should correspond to an off-chain record housing the Post's content.

  3. A Post must have one or more authors.

    1. Each author is identified by their Wallet address.

    2. Each author has a weight. Author weights must sum to 100%.

  4. A Post may include zero or more references.

    1. Each reference must include a weight between -1 and 1.

    2. Sum of negative weights must be >= -1.

    3. Sum of positive weights must be <= 1.

    4. A Post may reference the Incinerator with 0 <= weight <= 1.

    This Forum reference mechanism enables executing any conceivable change in the REP awarded to Posts and their authors.

  5. When a Validation Pool targeting a given Post is accepted,

    1. The REP that was minted and staked in favor of the VP is transferred to the target Post.

    2. For each Post referenced by the target Post, a fraction of the incoming Reputation given by the weight of that reference, is transferred to the referenced Post; and so on, recursively, until the Reference Chain Limit is reached.

      1. Positve references donate REP

      2. Negative references leach REP

      3. Negative references have the power to undo the effects of prior references, but a negative reference may not cause a Post to lose more REP than it had previously gained.

    3. Remaining Reputation after donation and leaching, is transferred to the authors of the Post in proportion to their author weights.

      1. A Post does not retain ownership of any REP

      2. The REP value of a Post is defined as the amount of Reputation that its authors have gained via that Post.

Rollup

As described above, in order for REP and fees to be distributed to DAO members, an on-chain Validation Pool must be executed. However, network gas fees must be payed every time a contract is called. Therefore a DAO may wish to batch multiple Posts and the Validation Pools targeting those Posts, into one consolidated Rollup Post and a single Validation Pool targeting that Rollup Post. To accomplish this, we introduce a Rollup contract.

The Rollup contract can be thought of as a specialized form of Work Contract (WSC), as it uses the same Availability stakes mechanism to select a batch worker.

  1. When the Rollup contract is deployed, a Batch Interval must be specified.

  2. A Work Contract may call the Rollup contract to add an item to the batch queue.

    1. The fee that would have gone toward the VP, goes to the Rollup contract instead.

    2. The Worker availability stakes that would have gone toward the VP, go to the Rollup contract instead.

  3. A Worker may stake REP to register their availability to be the next batch worker.

  4. Once the Batch Interval has elapsed, the current batch worker must add a Rollup Post to the Forum and call the Rollup contract to initiate a Validation Pool targeting the Rollup Post.

    1. Only the current batch worker may submit the next Rollup batch.

    2. If there is no current batch worker assigned, then anyone may submit the next Rollup batch.

  5. When the batch is submitted,

    1. Rollup contract initiates a Validation Pool targeting the Rollup Post.

      1. The fees that were included with each batch go toward the Rollup VP.

      2. The REP stakes that were included with each batch go toward the Rollup VP.

    2. The next batch worker is selected by random weighted selection from among the Batch worker availability stakes.

      1. If there are no Batch worker availability stakes, the transaction reverts, so the VP is not initiated.

  6. If the current batch worker fails to submit the next Rollup batch before the Batch Interval plus a grace period elapses,

    1. A Validation Pool should be initiated with no fee

    2. The batch worker's availability stake should be staked in favor of the VP

    3. A new batch worker must be selected

    4. The DAO members should stake against the VP, in order to punish the batch worker for failing to complete their work

In this requirements section, we omit any details of the mechanisms for implementing the necessary off-chain validation that leads to the production and verification of the Rollup Post. We will provide those details in the System Design section.