Introduction
This article provides information about OREC, which is an acronym for Optimistic Respect-based Executive Contract.
Optimistic Respect-based Executive Contract (OREC) is a smart contract that executes transactions on behalf of an organization or community that has a non-transferrable reputation token, aka Respect. This allows communities to easily make collective decisions and onchain actions with a high degree of decentralization.
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 and join the ORDAO Office Hours to learn more.
Table of Contents
- Introduction
- What is OREC?
- Optimistic Respect-based Executive Contract
- Motivation
- OREC approach
- Specifications
- Rationale
- What is ORDAO?
- Videos
- OF 40: Optimism Fractal ORDAO App
- EF 108: Optimistic Respect-based Executive Contract
- NovaCrypto Interview about ORDAO and OREC
- ORDAO Office Hours 1
- ORDAO Office Hours 2
- Related Posts
What is OREC?
Optimistic Respect-based Executive Contract (OREC) is a smart contract that executes transactions on behalf of an organization or community that has a non-transferrable reputation token, aka Respect. This allows communities to easily make collective decisions and onchain actions with a high degree of decentralization.
See the specifications and implementation in the Github Page. Learn more in the video playlist. The specifications are pasted below for your convenience.
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). 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 eitherYESorNOhere;prop_weight_threshold- minimum amount of Respect votingYESfor proposal to be eligible for passing;veto_period- second stage of proposal. Anyone can voteNObut no one can voteYES;respect_contract- contract storing Respect balances;max_live_votes- limit for how many live proposals a single account can voteYESon;
Mechanism
- Anyone can create a proposal to execute some transaction;
- For
voting_periodfrom proposal creation anyone can voteYESorNOon a proposal; - After
voting_periodfrom proposal creation, anyone can voteNO, but no one can voteYESon a proposal. This lasts forveto_period; - Every vote is weighted by the amount of Respect a voter has according to
respect_contractat the time of the vote; - Proposal is said to be passed if all of these conditions hold:
voting_period + veto_periodtime has passed since proposal creation;- At least
prop_weight_thresholdof Respect is votingYES; yes_weight > 2 * no_weight, whereyes_weightis amount of Respect votingYESandno_weightis amount of Respect votingNO;- Only passed proposals can be executed. Execution can be trigerred only once and anyone can trigger it;
- Proposal is said to be failed or rejected if it is past the
voting_periodand either 5.2. or 5.3. conditions are not satisfied; - Proposal is said to be expired if it is rejected or its execution has been triggered. Otherwise proposal is said to be live;
- Each account can only be voting
YESon up tomax_live_voteslive 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 the codename for the next generation of Optimism Fractal software being developed and proposed by Tadas. It features OREC as the core mechanism for decentralized onchain decision-making. Learn more in this article, in the Github Repository, and in the videos below.
Videos
OF 40: Optimism Fractal ORDAO App
How are Respect Game apps transforming Optimism Fractal? Enjoy a collaborative builder-empowering Respect Game, then explore an introduction to ORDAO - a new app proposed as the next generation of Optimism Fractal software 📱🍎🌱
You can watch Dan start talking about ORDAO here and see Tadas’ detailed presentation, followed by a thoughtful community discussion.
EF 108: Optimistic Respect-based Executive Contract
What is the future of onchain governance? Explore OREC, the new Optimistic Respect-based Executive Contract that simplifies decision-making with unprecedented coordination and decentralization 🏛️📜
NovaCrypto Interview about ORDAO and OREC
ORDAO Office Hours 1
The first ORDAO Office Hours, featuring an introductory overview of ORDAO, OREC, and ORConsole. Recorded on September 16, 2024.
Note: Due to a technical issue, Dan's audio was not recorded. We're sharing the raw footage of the recording now as an educational resource and plan to produce versions with higher production quality in the future.
ORDAO Office Hours 2
The second ORDAO Office Hours featuring a deep dive into OREC, the Optimistic Respect-based Executive Contract. Recorded on September 17, 2024.
Related Posts
A mystical soulbound token that represents an opinion to acknowledge the contributions and impact individuals make within a community, serving as a decentralized reputation system and promoting participation.
An overview of apps that make it easy to play the Respect Game, facilitate coordination, and cooperate with fractal governance within communities and organizations.
An innovative web app that empowers communities to connect, collaborate, and build consensus in a fun and effective manner with the Respect Game.
Discover Optimystics' suite of open-source tools and prosocial games designed to revolutionize community governance, impact measurement, and public goods funding on the Superchain.
A collaborative space and educational resource for developers who are interested in building with Optimism Fractal. It includes projects, tasks, and info related to Optimism Fractal development.
An overview of the current status of audits for Optimism Fractal’s open-source applications and protocols.
The Optimistic Respect-based Executive Contract enables onchain, decentralized, consent-based decision-making within organizations or communities that use non-transferrable reputation tokens, such as Respect.