This is an OIP based on RFC: Governance Path Forward. Please see https://forum.olympusdao.finance/d/4084-rfc-governance-path-forward for relevant discussion.

Summary

The present goal of the DAO is to get the protocol into a fully autonomous state by end of January, while taking the path of least risk. This OIP aims to show how adopting a governance-minimized philosophy with the right Governor Bravo parameters is the optimal path to achieving the protocol's goal by the specified timeline. The below plan proposes a two-stage rollout of on-chain governance:

  • OCG Stage 1 (end of January 2024) - introduce Governor and deprecate Policy MS

  • OCG Stage 2 (end of Q3 2024) - migrate remaining DAO MS to Governor

Governance-maximized vs governance-minimized

To evaluate whether a governance-maximized or governance-minimized approach makes sense for Olympus, it’s helpful to consider what the end state for the protocol looks like.

Explicitly or implicitly, OIP-148 assumes the end state of Olympus to be a hyperstructure. What is a hyperstructure? First introduced by Zora, it is a protocol that runs forever without maintenance, interruption or intermediaries. Properties of hyperstructures are:

  1. Unstoppable - the protocol cannot be stopped by anyone

  2. Valuable - accrues value which is accessible by token holders

  3. Expansive - there are built-in incentives for participants in the protocol

  4. Permissionless - universally accessible and censorship-resistant

  5. Positive sum - creates a win-win environment for participants to utilize the same infrastructure

  6. Credibly neutral - the protocol is user-agnostic

To date, Olympus is not a hyperstructure, but OIP-148 and a fully autonomous structure makes it one:

  • Unstoppable - after OIP-148, the protocol will run forever, and cannot be stopped by a set of actors. It is possible that a community majority votes to disband the protocol, but that’s different than a subset minority exploiting mechanisms to take control.

  • Valuable - the protocol accrues value from sDAI, RBS, Cooler Loans, and UniswapV3. All participants can exit the system through guaranteed liquidity in the form of Uniswap V3, RBS or Cooler Loans.

  • Expansive - Liquid backing offers an intrinsic and sustainable incentive for participants to hold OHM. Cooler Loans amplify the incentive by de-risking exposure. Multiple markets in the form of UniV3, RBS and Cooler Loans present constant arbitrage opportunities that liquidity providers can capitalize on.

  • Permissionless - after OIP-148, the protocol will operate fully on-chain with minimal oracle dependencies.

  • Positive sum - anyone holding OHM or building on OHM reaps the benefits of a strong store-of-value asset. Increased activity with OHM leads to increase in liquid backing, which benefits holders and builders alike.

  • Credibly neutral - no individual token holder gets preferential treatment.

What governance mechanisms accelerate Olympus toward a hyperstructure? To answer this, it might help to consider what governance mechanisms do NOT make a hyperstructure:

  • Manual - any action requires human discussion and consensus. Workflows might be autonomous but will always have a human-in-the-loop to execute decisions.

  • High maintenance costs - humans must be paid to work due to the opportunity cost each rational actor takes. A system with manual workflows and management means this system must pay for human performance, which is deducted directly from the value accrued by the network.

  • Broad powers - protocols that do not constrain governable parameters open the door for self-interested parties to find ways to maximize power.

  • Frequent interruptions - depending on who is in charge, vision and product roadmaps change, leading to redundant work, poor execution, distractions and exploits.

  • Stoppable and exploitable - broad powers and financial incentives means there will always be motivated actors looking for ways to exploit the protocol for profit.

If this sounds familiar, it’s because Olympus is such a system today. OIympus today can be summarized as a governance-maximized system. Conversely, something that runs forever without maintenance implies a governance-minimized system that requires little to no participation to function:

  • No multisig - when there is no multisig, there is no possibility for rogue signers to take control of the protocol. The signers don’t even need to go rogue; all it takes is an adversarial nation-state to coerce them into handing over control.

  • Few (if any) parameter changes - no system is perfect, which is why having *some* governance is necessary. If given the chance, humans tend to seek to maximize power. That is why it’s important to limit the maximum power afforded by governance. One way to implement this is by limiting what can be changed. A perfect example of this is Uniswap’s governance - Uniswap v3 allows UNI holders to change only protocol fee, add new pool fee tiers and/or transfer ownership

  • High quorum - a hyperstructure, by definition, runs without interruption. Since a governance proposal is an interruption in the system’s regular operations, it implies a deviation from the structure’s intended long-term operation. Almost certainly, such a change will impact ALL tokenholders that depend on the hyperstructure’s existing properties, and must therefore require a high quorum threshold. A high quorum threshold also reduces chances of self-interested parties taking control, de-platforming tokenholders, and breaking the credible neutrality of the protocol.

  • Few (if any) governance proposals - if the protocol is running autonomously, as expected, there should be little to no governance proposals. The few proposals that make it to governance should be meaningful enough to necessitate high governance participation. The expected mode of operation, therefore, is one with a handful of governance proposals per year (if any). This property should follow directly by limiting what can be changed and therefore requiring a high quorum threshold to change it. This also aids in preventing governance attacks from inattention because proposals need significant buy in to be successful.

Implementation

To implement a governance-minimized structure, we have two potential solutions: Governor Bravo or a custom implementation. The custom governance system evolved through the course of extensive feedback and iteration. After multiple debates surrounding several of the mechanisms, this RFC was shared but the conversation stalled with no clear next steps or buy-in from tokenholders. Given the lackluster response, it’s time to consider the alternative.

Governor Bravo is simple, battle-tested by major protocols (including Uniswap and Compound) on $10B+ in TVL, and addresses all of the governance problems Olympus faces today. It minimizes technical risk toward full automation because any custom implementation would require dev and time resources, taking focus away from current RBS 2.0 audit.

What about governance risk? Governor Bravo uses Minimum Quorum (defined as minimum FOR votes) to pass proposal. Olympus introduces an additional governance lever, Majority Approval (defined as minimum percent of FOR votes relative to total votes needed). To evaluate potential governance attacks, it's useful to view governance as a game where tokenholders are choosing strategies that optimize payoffs against malicious, and non-malicious, proposals in low-consensus, and high-consensus, environments. The two dimensions and their dominant strategies can be visualized as follows:

Given the permissionless vision of Olympus, it’s almost certain we will experience every configuration of proposals. The governance parameters we choose today should provide the necessary tools for tokenholders to govern through all such configurations. What should quorum and majority approval be for each dominant strategy? The summary is below:

  1. (High consensus, not malicious) = low quorum

  2. (High consensus, malicious) = high quorum, high majority approval

  3. (lack of consensus, malicious) = high quorum, high majority approval

  4. (lack of consensus, not malicious) = high quorum, low majority approval

A detailed analysis is available here.

Parameters

Based on the above analysis and discussions in RFC, I propose the following:

  • Spot gOHM and gOHM escrowed in contracts with delegate ability get voting power (i.e. Cooler Loans)
  • Minimum quorum: 20% of gOHM supply voting FOR
  • Majority Approval: 60% of FOR votes relative to total votes
  • Proposal Threshold: 10 gOHM (this is ~$31K or 0.017% of supply)
  • Voting Delay: 3 days
  • Voting Period: 7 days
  • Timelock: 1 day

A proposal can only pass if both minimum quorum and majority approval is satisfied. As an example, 20% quorum implies at least 11,994 gOHM must vote FOR in a proposal (20% of 59,970 at time of writing). If the majority approval is 60% and 15,000 gOHM vote FOR but 11,000 gOHM vote AGAINST, then the proposal would fail because approval was only 57.7% (as 15000 / (11000 + 15000) < 60%).

Roadmap

Olympus today is governed by three multisigs (DAO, Policy and Emergency) with responsibilities defined through Default Framework Roles. A successful transition requires a migration plan for all roles and multisigs to on-chain governance. To balance execution efficiency and security, we propose a two-stage migration plan over the course of ~9 months, in the event the DAO or the Olympus Association finds security or legal concerns with respect to eliminating the DAO MS in favor of Governor Bravo, then this step might be delayed till all warrantees are in place:

  1. OCG Stage 1 (end of January 2024) - introduce Governor Bravo and deprecate Policy MS

  2. OCG Stage 2 (end of Q3 2024) - migrate remaining DAO MS to Governor

OCG Stage 1

The high-level goals in this stage are as follows:

  1. Deploy Governor module (the on-chain governance module)

  2. Migrate Cooler Loans and BLV to Governor

  3. Deprecate Policy MS

The specific implementation is proposed below:

OCG Stage 2

The high-level goals of this stage are:

  1. Migrate executor and admin roles to Governor.sol. Any future upgrade will go through on-chain governance

  2. Migrate remaining DAO MS roles

The specific implementation is proposed below:

Proceed with proposed plan?

This poll has ended.

Thanks for all the discussion that brought us to a really solid solution. I think that the proposed setup strikes a good balance of reactivity and security. I voted to proceed to snapshot.

Appreciate your dedication to crafting this well-balanced solution that sets Olympus on the road to success. I believe the community will be pleased with the proposed terms. Let's ride!

Wonderful balance of security and decentralization. Fully in favor.

Per discussion in Discord, I'm proposing to change Voting Delay from 1 Day to 3 Days. Voting Delay is time between a proposal is submitted and when it goes live. Changing it to 3 days gives community time to digest and discuss a proposal before actual voting starts.

@unbanksy33 great work and than you for being on top of this project. Id like to add that committing to a fix time frame of aprox 9 months is unnecessary. We can keep it as a goal. Would be great, but as we have seen so far unexpected events, findings, or dynamics might make us reconsider that timeframe. I believe that in the event the DAO or the Olympus Association finds security or legal concerns with respect to eliminating the DAO MS in favor of Governor Bravo, then this step might be delayed till all warrantees are in place.

As I discussed in discord and dms, there is no rush to do so, and that should be the final step of all, and only taken when we are 100% sure we are not introducing any risks to governance. Olympus has an impecable record and in general we should not fix whats not broken. I'm all for progress, improvements and automation. But could not be in detriment of security and being wide opened to governance attacks. As we discussed with Tally last call, we can have both. OCG and be protected.

Write a Reply...