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.