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
- Smart Contracts
- Videos about OREC
- Related Posts
What is OREC?
The description of OREC, motivation, and specifications in this section are written by Tadas, the creator of ORDAO and OREC. They were originally published on the Github Page about the concept of OREC and are pasted below for your convenience.
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
- Anyone can create a proposal to execute some transaction;
- ForĀ
voting_periodĀ from proposal creation anyone can voteĀYESĀ orĀNOĀ on a proposal; - AfterĀ
voting_periodĀ from proposal creation, anyone can voteĀNO, but no one can voteĀYESĀ on a proposal. This lasts forĀveto_period; - Every vote is weighted by the amount of Respect a voter has according toĀ
respect_contractĀ at the time of the vote; - Proposal is said to be passed if all of these conditions hold:
voting_period + veto_periodĀ time has passed since proposal creation;- At leastĀ
prop_weight_thresholdĀ of Respect is votingĀYES; yes_weight > 2 * no_weight, whereĀyes_weightĀ is amount of Respect votingĀYESĀ andĀno_weightĀ is amount of Respect votingĀNO;- 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_periodĀ and 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Ā
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
ORDAO Console
- Management Interface:Ā of-console.frapps.xyz
- Purpose: Advanced governance operations and system monitoring
Submission Interface
- Primary Application:Ā of.frapps.xyz
- Purpose: Basic interface for consensus submission and onchain submission
Fractalgram app
- Fractalgram Frontend:Ā github.com/optimystics/fractalgram-web
- Live Application:Ā respect-game.vercel.app
- Article with details: Optimystics.io/fractalgram
- Purpose: Intuitive app for consensus formation and onchain submission
Smart Contracts
The system is currently deployed on the OP mainnet on the Optimism Fractal community account and ORDAO Office Hours account with testing environments available on multiple EVM-compatible networks. Regular updates and improvements continue to be deployed based on community feedback and testing results.
See ORDAO Deployment Information below for details and account addresses:
Videos about OREC
OTH 27: Optimism Fractal ORDAO Software Implementation
How is ORDAO advancing onchain democratic governance? Discover a revolutionary protocol for consent-based community coordination powered by reputation. Learn how this groundbreaking software is transforming governance for Optimism Fractal and the Superchain šļøš»
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 giving a brief overview about ORDAO here and see Tadasā 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.
ORDAO Office Hours 3
The third ORDAO Office Hours meeting, featuring an overview of ORConsole. Recorded on September 18, 2024.
ORDAO Office Hours 4
The fourth ORDAO Office Hours meeting, featuring discussions about integrating ORDAO with Optimism Fractal and the next Office Hours. Recorded on September 19, 2024.
ORDAO Office Hours 5
Discussing ORDAO v1.1, testing new Privy functionalities, and exploring integrations with Fractalgram. Recorded on December 18th 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 in fair, fast, and fun governance.
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, reputation systems, and public goods funding mechanisms on Ethereum.
A revolutionary governance system designed to enhance decentralized decision-making, democratic participation, and resource allocation in all aspects of society through the Respect Game.
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.
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.