OREC: Optimistic Respect-based Executive Contract

Introduction

In this blog post, we explore the Optimistic Respect-based Executive Contract (OREC), a groundbreaking smart contract designed to facilitate decentralized decision-making within organizations and communities that utilize non-transferrable reputation tokens, known as Respect.

OREC aims to address common challenges faced by decentralized autonomous organizations (DAOs), such as voter apathy and the need for effective governance without relying on traditional voting methods. The article delves into the mechanics of OREC, its motivations, specifications, and how it fits into the broader vision of ORDAO, the state-of-the-art decentralized governance protocol that combines sophisticated smart contracts with an innovative consent-based voting system to enable truly democratic community coordination. Readers will gain insight into how OREC can empower communities to make collective decisions efficiently while maintaining a high level of decentralization and trust.

Please note that this article is in an early stage of development and will be updated soon. You can ask questions about ORDAO and OREC Optimism Fractal discord, join the ORDAO Office Hours, and watch the ORDAO video playlist to learn more.

Table of Contents

• Introduction
• What is OREC?
• Motivation
• OREC approach
• Specifications
• Rationale
• What is ORDAO?
• Developer Resources
• ORDAO Office Hours
• Code Repositories
• Web Applications

What is OREC?

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.

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).

Specifications

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 motivation behind this mechanism is to tolerate majority of participants being passive, allowing proposals to be passed without having high voter participation, while also enabling a community to rally around to block any proposal fairly easily.

There’s a usually a big category of participants who are not proactive in governance decisions but are aware and would be able to react in case of contentious proposals being passed. The reason to block a proposal could simply be the perspective that proposal needs more consideration. So proactive governance participants could simply ask passive participant to “Veto” with an argument that “we need more discussion around this”. So passive voter would not need to understand the proposal fully to “Veto”, they would simply need to get a sense of it’s importance. This way we can utilize “passive but aware” category of participants for security thus avoiding reliance on any (typically arbitrary) quorum requirements and allowing organization to move forward even in cases of low voting turnout.

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.

Spam prevention

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.

What is ORDAO?

ORDAO is a decentralized governance protocol that combines sophisticated smart contracts with an innovative consent-based voting system to enable truly democratic community coordination. Built around the Optimistic Respect-based Executive Contract (OREC), this elegant system transforms how communities make and execute decisions onchain while enabling true decentralization with active participation.

Learn more about ORDAO in this article and in the videos below.

Developer Resources

ORDAO provides comprehensive educational resources for developers interested in learning about and contributing to the project. The open-source codebase welcomes community contributions. Learn more about development details below.

ORDAO Office Hours

Register for ORDAO office hours sessions hosted by the creator of ORDAO, Tadas, to learn implementation details. These are scheduled on an ad hoc basis, so you can register for email reminders to be notified when they’re announced. Watch videos of past ORDAO Office Hours and more educational video content in the ORDAO Video Playlist.

Code Repositories

All ORDAO code is open-source with a GPL-3.0 License and available for review and contribution:

• ORDAO Repository - Core smart contracts and implementation
• Original frapps Repository - Historical development archive
• FRAPPS Repository - Curated collection of fractal application software

Web Applications