OREC

[sim31]

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). The main use case is performing code updates of a DAO (if OREC is set as an owner of a proxy contract) but it can be used for other transactions as well.

It is optimistic because it trusts a minority of contributors who take the initiative to act on behalf of a DAO even if they hold a small amount of Respect. The security comes from a time delay during which other contributors can easily block a transaction if they collectively have a significant enough amount of Respect relative to what the initiators have.

Mechanism

The goal is to enable contributors to 1) propose transactions to be executed, 2) vote whether they should be executed, and 3) if they receive enough votes - to execute them.

Variables

• stage1_period = 1 week;
• stage2_period = 1 week;
• min_vote_threshold = 128 Respect;
• respect_period = 12 weeks;

Process

1. The whole OREC contract goes through cycles, each cycle being composed of 2 stages. At any point in time contract is in one of these 2 stages;
   1. The first stage is the “voting stage”, where contributors can propose and vote on proposals. It lasts stage1_period;
   2. The second stage is the “blocking” stage, where contributors can block proposals. It lasts stage2_period;
2. Each cycle has a board, which is a set of accounts (board members) that have a weighted vote and the ability to propose transactions;
3. A vote is weighted by the amount of Respect earned by an account over the last respect_period;
4. The total weight of a board is the sum of the vote weights of all the board members;
5. To become a member of a board an account has to submit a transaction to register onchain. Registrations hold only for the current cycle.
6. During the “voting stage” of a cycle, the contract allows:
   1. Accounts to register to be members of the board of the current cycle;
   2. Members of the current board to propose transactions (make proposals);
   3. Members of the current board to vote on proposals;
7. During the “blocking” stage of a cycle, the contract allows only to register to be members of the board of the current cycle (does not allow making proposals or voting on them);
8. A proposal can be executed if at the end of a cycle it satisfies the following requirements:
   1. It has received more than min_vote_threshold worth of votes;
   2. The total weight of approval votes constitute more than 2/3rds of the total weight of a board;

Rationale

The effect of the fact that in the 2nd stage, accounts can only register to be board members but not vote (approve) proposals means that in the 2nd stage, proposals can be blocked. This can be done simply by registering to be a board member, because it increases the total weight of a board, which increases the amount of vote weight required to pass proposals, thus potentially un-approving some proposals that might have had enough votes in stage 1. This creates a flexible system where most contributors won’t need to bother with voting for proposals and execution as long as they consent to the transaction proposals being passed.

Typically organizations need to elect people who represent them in doing administrative tasks (like making transactions), which adds overhead. This mechanism avoids that. Anyone who has some Respect can take the initiative. The rest of the community has at least 1 full week (by default parameters) to block anything they don’t like or simply do not have time to review. To block you don’t need to vote against, you simply register. Here having a perspective that proposal needs more review is a perfectly valid reason to block it. Contributors who want to protect their DAO and be part of any executive decision-making can simply register every cycle to be part of the board and only vote for what they are sure of. Registration during a cycle simply signals - “I’m online this cycle and willing to participate in executive decision making. Don’t execute anything without counting my vote.”

The requirement to register for every cycle ensures that DAO does not get stuck because of people who signaled membership a while ago but are not actively participating in governance anymore. Or people who have a lot of Respect, but don’t have the time or the knowledge necessary to review and execute transactions.

The DAO can still be “maliciously” blocked by members who hold enough Respect. But this is up to Respect distribution process to prevent that. If Respect distribution represents reality this should not be an issue: if blocking made by some member is perceived as counterproductive that member should receive less Respect ^[1]. Vote weight is computed only from the last respect_period, so given enough time vote weight should shrink for contributors who are blocking too much or who approve too much according to the rest of a DAO.

---

---

1. In fractally-style communities this is achieved using Respect Game ↩