Skip to content

Latest commit

 

History

History
114 lines (78 loc) · 11.5 KB

OREC.md

File metadata and controls

114 lines (78 loc) · 11.5 KB
Raw

Optimistic Respect-based Executive Contract

Optimistic Respect-based Executive Contract (OREC) is a smart contract that executes transactions on behalf of a DAO, that has a non-transferrable reputation token (which we call “Respect” here). It enables minority of proactive contributors to act on behalf of a DAO even if they hold a small amount of Respect (hence "optimistic" in the name). The security comes from a time delay between voting and execution during which other contributors can easily block a transaction if they collectively have at least half the Respect that initiators have.

Motivation

DAOs being an onchain organizational unit often need to execute onchain transactions as a unit. Simplest voting solutions typically suffer from voter-apathy. This leads to DAO setting low quorum requirements to adapt to low voter turnout, which is a compromise in security. Setting the right quorum requirement is tricky, since we typically want higher requirement for security, but setting it too high can lead to DAO getting stuck. What makes this hard is that this has to be done in advance and it is hard to predict what kind of voter participation DAO will have in the future. All of this often causes DAOs to leave control to some kind of multisignature setup by the founders, where founders are expected to execute based on poll results (instead of voters being in control directly). This protects against a DAO getting stuck, but makes it more dependent on a limited and potentially centralized set of actors.

Over the past few years a new kind of DAOs emerged called "fractals". Their main feature relevant here is "Respect" token assigned to contributors based on community consensus about value of their contributions relative to contributions from other participants (you can read more about this mechanism here). This effectively creates a non-transferrable reputation token and gives a problem described above a slightly different twist: in this case voting power cannot be bought and it also cannot be split among many accounts belonging to the same owner (no sybil attacks).

OREC approach

OREC features a novel approach to combat voter-apathy in the context of fractals with non-transferrable reputation token. It is also oriented for contexts where community uses off-chain tools to build consensus. The approach can be summarized as follows:

  • Set quorum required to execute onchain transactions to be very low (to say 5%);
  • As a result, under typical low voter turnout scenario, a single bigger contributor is enough to execute transaction;
  • In case a transaction which community disagrees with is proposed, rely on rest of the community to block it;
  • Make it easy to block transactions by adding a time delay between voting and execution during which only negative votes are accepted;

The assumption here is that community will use variety of off-chain tools to communicate as well as build consensus and OREC will be used as the last step in the decision-making process. So a vote in OREC is not a vote on idea proposals, it's a vote on whether "a proposed transaction represents consensus of the community (does community want to execute this transaction now)". This makes it much easier to rally community to block a dangerous or contentious transaction proposal. It could simply be done on the grounds that - "we need to discuss this more". But transaction proposals which haven't gone through the agreed-upon process of deliberation are unlikely to happen often in OREC, because eligible proposals can only be initiated by respected members of community (respect-holders).

Specification

Definitions

  • Proposal - proposal to execute some transaction. Once proposal is passed this transaction can be executed;

Variables

  • voting_period - first stage of proposal. Anyone can vote either YES or NO here;
  • prop_weight_threshold - minimum amount of Respect voting YES for proposal to be eligible for passing;
  • veto_period - second stage of proposal. Anyone can vote NO but no one can vote YES;
  • respect_contract - contract storing Respect balances;
  • max_live_votes - limit for how many live proposals a single account can vote YES on;

Mechanism

  1. Anyone can create a proposal to execute some transaction;
  2. For voting_period from proposal creation anyone can vote YES or NO on a proposal;
  3. After voting_period from proposal creation, anyone can vote NO, but no one can vote YES on a proposal. This lasts for veto_period;
  4. Every vote is weighted by the amount of Respect a voter has according to respect_contract at the time of the vote;
  5. Proposal is said to be passed if all of these conditions hold:
    1. voting_period + veto_period time has passed since proposal creation;
    2. At least prop_weight_threshold of Respect is voting YES;
    3. yes_weight > 2 * no_weight, where yes_weight is amount of Respect voting YES and no_weight is amount of Respect voting NO;
  6. Only passed proposals can be executed. Execution can be trigerred only once and anyone can trigger it;
  7. Proposal is said to be failed or rejected if it is past the voting_period and either 5.2. or 5.3. conditions are not satisfied;
  8. Proposal is said to be expired if it is rejected or its execution has been triggered. Otherwise proposal is said to be live;
  9. Each account can only be voting YES on up to max_live_votes live proposals at a time;

Rationale

  • The purpose of 9th rule is to preven spam attacks. Without this rule, any respected member with more than prop_weight_threshold could spam with many proposals and force honest members to waste a lot of gas vetoing each one.
  • If we consider total turnout to be union of Respect voting in both stages then a one way to think about it, is that 2/3rds + 1 of turnout is able to pass a proposal, which also means that 1/3rd of turnout is able to block it.
  • In context where community builds consensus off-chain and only uses OREC for execution, veto period can be likened to a challenge period concept that other "optimistic" protocols use (e.g.: optimistic rollups, optimistic oracle). In case of OREC, during challenge period community can dispute and block a transaction proposal by proving lack of consensus through negative votes on that proposal.

Further research

Applicability to other contexts

OREC was thought out for the context of fractals which have non-transferrable reputation token. However the general idea of "veto period" where only "no" votes are accepted might be helpful addition in other contexts as well. Furthermore, in some contexts it might be possible to replace Respect with some typical staked governance token in combination with some identity mechanism, where to have your vote weighted by your stake you would have to have some sort of soulbound token (proving unique identity or some reputation of an account). This soubound component is needed to prevent spam attacks where stake would be split over many accounts to overcome max_live_votes parameter and spam the system with many proposals to reject.

Adaptive quorum biasing

Adaptive quorum biasing is a voting system where required supermajority of 'yes' votes is adjusted based on the voter turnout, so that lower turnout would require bigger supermajority to vote 'yes'. This makes the voting system quite adaptive in that it can keep working under low-turnout scenario with a helpful caveat that you need active voters to have more agreement in those cases.

Currently the percentage of 'yes' votes needed to pass a proposal is fixed to 2/3+1 of all votes in OREC. OREC might benefit from using adaptive quorum biasing instead. This would make the specification a bit more complex, but could make it even more adaptive to various scenarios over time and make it more easy to configure in a secure way.