This document describes work being done in this repo to upgrade Optimism Fractal software.
The working code-name for this new software package is "ORDAO" (optimistic respect-based DAO).
Scope of the upgrade (components of Optimism Fractal that would be replaced):
- Ownership of contracts transferred to respect-holders;
- Semi-automated distribution of Respect;
- No need for hard rules about how many submissions from the breakout room is needed;
- Fixes current problems with Respect token;
- Enables respect-holders to mint or burn Respect for reasons other than respect game;
- Enables awarding Respect for use cases other than Respect Game;
- Allows fixing mistakes in distribution more easily;
- This is a step towards making it easier to deal with situations where ETH address of a person changes;
- Easier to deal with cases where breakout room submissions need to be corrected;
- Other advantages of OREC;
Current contracts of Optimism Fractal are "owned" by people who started Optimism Fractal. Now that we have a stable Respect-distribution that represents participants of Optimism Fractal, we can transfer control to them.
The control by Respect-holders would be exercised through Orec (Optimistic Respect-based executive contract) - a onchain transaction proposal system that is very flexible in adapting to levels of voter participation onchain.
One of the main issues with the current version is the need for manual distribution of Respect. This looks like a single account issuing transactions to distribute Resepct. This account can be changed by owners of the contract, but it's an issue still both in terms of centralization and amount of manual administrative work required.
ORDAO achieves something I call "semi-automated" distribution of respect. The way it works is that participants submit votes on a proposal to distribute respect and if proposal is passed (according to Orec rules) then proposal enters "execution stage". At that point any account (does not have to be participant of Optimism Fractal) can send a transaction to execute the proposed transaction. The need for this additional transaction to execute the distribution is the only reason it's "semi-automated" and not "automated." But once a good GUI for this app is available this additional action will be as simple as anyone clicking one button and signing transaction with their wallet. This is a big improvement over a current version, where some administrator account has to create transactions "by hand".
The Respect amount to distribute will be automatically calculated by frontend before the user submitting a vote on any proposal to distribute respect. More details here.
Another pain-point in the current version is the requirement for number of onchain breakout room result submissions. It quite regularly results in council having to pass proposals to distribute Respect for rooms which haven't made enough onchain submissions.
The number of required submissions is quite arbitrary, as not reaching this number does not mean that there's no consensus. The fact that pretty much all council proposals to distribute Respect for rooms that didn't have enough submissions pass, proves that there's often consensus about breakout room results even when there are not enough submissions. But of course we still need security mechanisms to prevent attackers from getting Respect.
Respect distribution should be controlled by a fractal. So consensus of a fractal is more important than consensus of an individual breakout room. So if fractal has consensus that a breakout room should get awarded with Respect, it should be so.
I propose ditching the arbitrary requirements for number of submissions from a breakout room and instead using a flexible onchain proposal mechanism (Orec), that adapts to levels of onchain participation, to distribute Respect according to consensus of a fractal.
Respect1155 fixes main headaches with the current Respect contract of Optimism Fractal. It is ERC1155 contract with a fungible token representing fungible Respect and NTTs with value attribute that sums to balance of a fungible token.
OF2-CONCEPT document here describes how the proposed version would work. It is a modified version of the current intent document that Optimism Fractal participants should be familiar with. It serves the same function as the current intent document. It is a human language definition of Optimism Fractal that could be useful to prevent any misunderstandings and contentious forks.
The main change are the addition "Executive contract" section which defines how Optimism Fractal will implement their consensus onchain (distribute Respect, etc) and removal of 3rd section which was about validity of breakout-room results.
Work is being done to implement this concept here.
- Orec - acts as an executive contract (as defined in concept) to distribute Respect and execute other transactions for a fractal. It implements Optimistic Respect-based executive contract as specified here.
- Respect1155 - new Respect token contract, that OREC will use to distribute Respect going forward (OREC will be set as the owner of this contract);
- FractalRespect - this is the old Respect contract that will be used to determine vote weights in OREC;
.
Rationale for this design is in upgrade path description.
Frontend will accept breakout room results as always, but then it will translate it to OREC proposal to distribute Respect for break-out room participants (according to their ranking). When the user submits, he will actually be submitting a vote on that OREC proposal. This way an old and familiar Respect game workflow will integrate seamlesly with the new and more powerful OREC mechanism.
ORConsole is a documentation / console app for interacting with ORDAO. It's already working and it's the main tool right now which I use to interact with ORDAO. It exposes all the functionality that will take time to develop in the GUI frontend. You can think of ORConsole as a web-app for the fractal where all the functionalities are available early in a command-line fashion.
Most importantly it provides documentation for the programming API to interact with Ordao which will make it easier for anyone to build a GUI for ORDAO (or at least some of its features).
Currently GUI worked on in this repo has only as much as the GUI for the previous version of Optimism Fractal - only a frontend for submitting breakout results is implemented. This is where help would be appreciated.
One option is to grow gui project in this repo. But ORDAO is built with composability in mind, exposing APIs through orclient which should make it easy to build a GUI from scratch or integrate interactions with ORDAO into other interfaces. ORConsole is a great tool for learning ORClient.
GUI (and orclient that it uses) can be improved gradually, even after contracts are replaced, so it does not have to slow down the upgrade process as outlines in upgrade path document.
The idea is to deploy implementation on Optimism mainnet as a test version that can potentially become the new "official" version of Optimism Fractal, if Optimism Fractal consensus decides so.
UPDATE: Optimism Fractal passed a proposal to adopt ORDAO this season. The upgrade path ended up being a bit different. Namely in that it happened for season 5 as opposed to season 4 and there's no overlap between the new and old token distribution so far. See this thread for more details.
If you have any feedback about this please share it in Optimism Fractal Discord server or create an issue here on Github.