OIP-152: On-chain Governance

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

[Snapshot note: the following section is presented in a compressed format to conform to the 10,000 character limit]:

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: