Legislative governance

From DAO Governance Wiki
Revision as of 03:13, 2 May 2023 by Craig Calcaterra (talk | contribs) (→‎System design)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Legislative governance is the process of steering future behavior by planning and implementing changes to executive governance protocols in a DAO. Legislative goverance is one of three branches of governance under DGF. Legislative governance determines changes to the future behavior of smart contract parameters, smart contract logic, UI appearance and function, backend logic, the protocols for governance itself, and soft protocols.

The process of legislative governance follows a sequence of Validation Pools which allow members to register their opinion by voting with REP tokens. The sequence proceeds from loosely-coupled votes to tightly-coupled votes. Loosely-coupled votes encourages authentic deliberation and truth discovery, while tightly-coupled votes enforce timely resolution of any changes the DAO requires in response to changing markets.

Overview[edit | edit source]

??

Legislative governance proposals[edit | edit source]

Main page: Legislative governance proposals

??Move these details <-- ??

Legislative proposals use the same mechanism as judicial governance proposals, they merely have different intent, and so we use different terminology. A legislative governance proposal is future-oriented, whereas a judicial governance proposal is past-oriented. An example legislative concern is to propose development changes to the DAO, such as offering bounties for UI development, or suggesting an adjustment to the Work smart contract. An example judicial governance proposal would be to redress a grievance concerning how a member's action was over- or under-valued in the past.

Mechanism design[edit | edit source]

Legislative governance under DGF uses the Forum reference mechanisms, the Validation Pool, and the Work smart contract. To explain the process we pick a basic example.

Example for dev bounty[edit | edit source]

Suppose a DAO wishes to offer a bounty for improving the UI, say to make the skin more attractive. The basic process would be to make a proposal to the DAO that they should pay a certain amount , which could be claimed by anyone who satisfies the stipulations of the proposal. If the proposal is eventually accepted by the DAO according to the following legislative process, then the proposal would become an active smart contract which selects a developer for the job following DGF work flow. The process for funding the proposal is also detailed below.

Legislative process for adopting a bounty proposal[edit | edit source]

The governance process is as follows:

  1. A proposal is submitted.
  2. If accepted the proposal becomes a promise.
  3. Future work posts donate their REP to fill all promises.
  4. When a promise is filled it becomes a fulfilled promise.

In greater detail: A proposal is a post submitted to the Validation Pool for gREP owners to consider. If the proposal is accepted by the DAO through a Validation Pool, then it becomes a promise. A promise typically has 0 value at initiation and will only gain REP value after subsequent references give it power. A proposal references other posts, donating and/or leaching, which entail a suggestion for redistribution of REP. In other words, a proposal has a set of references and number called its full potential. The full potential is the value it proposes to eventually receive by future work posts. The full potential and the references determine the actual value of REP redistribution of a proposal.

That is, a promise is a validated proposal in the Forum which has a set of references and a specified full potential, which is filled by references from future WSCs.

Funding the bounty[edit | edit source]

Typically a promise starts with 0 value, then subsequent work posts donate REP value (governance tax) to it until it reaches value equal to its full potential. Then the promise becomes a fulfilled promise. Before a promise is fulfilled, it is an unfulfilled promise.

The WSC has the functionality of referencing unfulfilled promises. The worker UI scans the Forum for new promises and parses the difference between the sets of fulfilled and unfulfilled promises. If there are no outstanding unfilled promises, then the UI automatically donates its governance tax to the incinerator. The other worker UIs verify that each new WSC submitted has added the required references before validating.

DGF work flow for claiming the bounty[edit | edit source]

For a worker to do the work and claim the example bounty, the worker follows basic DGF work flow.

  1. Workers willing to participate encumber REP in the bounty availability smart contract (ASC).
  2. Bounty Work smart contract (bWSC) selects the worker(s) from the ASCs.
  3. Worker finishes the work off chain, then has the bWSC submit the proof as a post to the Forum, which opens a Validation Pool.
  4. Validation Pool mints new REP and opens the voting for validation. VP distributes the fee and new REP.

There are several alternatives for funding the bounty and paying the worker, as discussed in REP tokenomics applications.

Governance tax[edit | edit source]

The governance tax is a percentage of all newly minted REP that is used in the governance process to fulfill legislative and judicial proposals, or sent to the incinerator when there are no outstanding proposals.

For the purposes of illustration, we assume the DAO enforces a global tax on all new REP value minted in the DAO. This number is not necessary for any particular DAO and the percentage is arbitrarily chosen for the purposes of illustration. By a tax, we mean that whenever new fees enter the system the amount of new REP minted is . In this case, is the minting ratio and the extra is the governance tax. We call it a tax, because if the newly minted tokens are not burned, then they can dilute the power of previous REP tokens. All members are affected in that case, since their REP salary is diminished, being shared amongst more tokens.

By fiat, the DAO requires that every new Work smart contract (WSC) post which earns fees and REP must donate of the new REP to fulfill to promises. New work posts automatically reference approved proposals, because the UI automates the process of fulfilling promises, and other members' UIs automate the validation of these WSC posts, downvoting any that violate the governmental referencing protocols.

From the DGF model, the parameter is included in the minting ratio . It can be chosen by the DAO to be any number .

The REP salary is unaffected by the REP tax whenever it is incinerated.

Similarly if governance equally redistributes REP within the Forum – meaning the amount leached from posts is equal to the amount donated to posts – then any member whose posts are not affected will not have any change in their REP salary.

The only time the REP salary is affected by the governance tax is when the reference donation and leaching is not equal. When donation is larger than leaching, then the REP salary of other members is decreased, since the total REP is increased, diluting the power of their REP. When leaching is larger than donation, then the REP salary of other members is increased, since the total REP is decreased, which concentrates the power of their REP. Therefore the effect on the salary is bound by the size of and is typically much smaller. It is worth reiterating: governance tax REP sent to the incinerator is good for every member of the DAO.

To repeat, a tax of does not affect the value of REP unless it is used to donate to new posts in excess of leaching, which should only be done to redress past mistakes (judicial proposals) or fund development (legislative proposals).

Fairness & availability[edit | edit source]

The governance tax is particularly equitable, since every worker pays precisely the same amount, relatively. Since every WSC donates the same to governance references, then the remaining REP every worker receives from a WSC has the same value by the quantity theory of money in economics. To illustrate this point, notice that if every members' REP holdings were arbitrarily doubled, then the salary each member receives would be unaffected.

Regardless of the change in REP total, the tax affects every member proportionally equally, since the tax dilutes REP universally, which diminishes the REP salary the same for every existing REP token.

Since every WSC post generates of its REP for governance, then that REP is available for revaluing the Forum WDAG in response to governance proposals that the DAO approves, as long as the DAO is actually earning revenue, which is the most important time for revaluing the REP distribution.

Governance agility vs stability[edit | edit source]

Finally, the parameter is arbitrary. Governance can decide to make if the DAO wishes governance to move slower, or if it desires faster governmental responses. A smaller number gives greater stability and less responsive regulation. A larger choice destabilizes the DAO and is a threat to security, but also makes the DAO more nimble and responsive to changes in the market and makes policing more effecting.

Example legislative proposals[edit | edit source]

  • Proposal to change a smart contract's parameters
  • Proposal to change a smart contract's logic
  • Proposal to change the governance of a DAO
  • Proposal to change soft protocols

Applications[edit | edit source]

Code[edit | edit source]

See Also[edit | edit source]

Notes & References[edit | edit source]