• General
  • Introducing Parthenon: Olympus On Chain Governance

Decentralized protocols have predominantly leveraged two frameworks (with a few others in minority): Governor Bravo by Compound Labs or OpenZeppelin Governor.  Being on chain requires decentralized organizations to properly coordinate and execute initiatives, code, and upgrades in a fair and transparent way. These systems have been deployed by hundreds of organizations and were inspirational primitives to the system designed by OlympusDAO. Below, we propose several modifications and novel mechanisms to ensure the success and fairness of the protocol.

https://blog.tally.xyz/understanding-governor-bravo-69b06f1875da Current Operations: Currently, the Olympus governance flow begins with community discussion, either in the discord server or as an RFC on the forum. From there, edits are made based on community feedback and the proposal moves to OIP Proposal status on the forum. Community members show support or dissent via a poll and/or comments at this stage. At the end of the predetermined voting period, a passing OIP then moves to snapshot for a ratifying vote. After the snapshot period has concluded, execution then falls to a multisig or a team within the DAO to carry out the approved actions.

The Problems:

1. Actions aren’t executed directly on-chain; instead, they rely on multisig or DAO members to implement them after the proposal process. This setup may appear centralized, though the DAO and MS only work to execute wishes of holders as expressed through voting.. Shifting operations on chain eliminates this dependence, ensuring the protocol can automate processes, enhancing security against censorship and potential misconduct.

2. There are no quorum thresholds in place. Without these thresholds, passing votes may not accurately represent the broader community’s sentiments. Limited participation can pose a security risk, which is currently mitigated by using the multisig for execution.

3. There are insufficient incentives for proposers to submit high-quality proposals. While we encourage discussions on various topics in the discussion/RFC stage, proposals should demonstrate meaningful effort and thoughtful consideration. Spam proposals lead to governance fatigue and strain the governance system.

4. The proposer is not responsible for creating executable code. Anyone can suggest a product with numerous features, subject to extensive community debate. However, this approach can lead to incompatibilities between proposed features or configurations and the protocol. Since proposers aren’t tasked with providing executable code, the final product may deviate from the original intention due to design changes or shifts in the broader economic landscape.

**Parthenon Governance System
**
Mechanisms were developed to address governance issues and mitigate various security risks identified over more than a year of deliberations. This extensive planning process led to multiple iterations of the governance framework.The resulting system is presented below, detailing each mechanism, and a visual flow chart has been included to illustrate the proposal’s journey.

It is crucial to emphasize that in immutable governance, the concept of an exploit doesn’t exist. Attempting to add an excessive number of safeguards to protect a specific perspective ultimately introduces a potential vulnerability one way or another. In any system, if a single holder amasses sufficient voting power or mobilizes a substantial number of votes, the proposal will succeed.

Participation stands as the primary means to prevent unfavorable outcomes. The most effective system strives for simplicity, ensuring that token holders can easily comprehend their voting influence and the subject of their votes. This approach promotes fairness and transparency within the system.

Proposal Collateral: Preventing Spam and Aligning Goals

Proposal Collateral is designed to prevent spam and ensure that proposal posters are aligned with the protocol. To submit a proposal, the proposer must post OHM as collateral equal to 5% of the total supply of vOHM, with a hard minimum of 1,000 OHM. This collateral is locked for 16 weeks unless the proposal passes, in which case the proposer can immediately withdraw the collateral.

By doing so, the opportunity cost to submit a proposal scales with the total vote supply, and the minimum guarantees that a baseline opportunity cost exists for submitters in the case of low circulating vOHM supply. Proposal submissions are limited to OHM holders. Community members who wish to submit a proposal but lack the necessary collateral can circulate their ideas with the DAO or other holders for sponsorship, helping to ensure the cost barrier is not a blocker for well intentioned Ohmies.

Activation: Giving Time for Review and Deliberation

The activation timelock gives voters enough time to properly review and deliberate on a new proposal before a decision can be made. Proposals are in an activation timelock for 48 hours before they are able to be activated by the proposer. Proposals must be activated between 48 hours and 72 hours after original submission by the proposer. If a proposal is not activated, it is closed, and collateral remains locked for 16 weeks.

This timelock allows community members that wish to vote on the proposal to obtain vOHM prior to the snapshot being taken. It is a short enough time to not cause excessive delays in governance proposals, but long enough to allow interested parties to take the actions needed to participate.

A snapshot is taken at the point of proposal activation to determine the total vote supply for that proposal. If the minimum vOHM circulation supply is not met, proposals cannot be activated. This parameter prevents attacks due to low vOHM holdings and ensures there are minimum standards in place for community representation in the voting decision.

Consensus: Determining Successful Collective Agreement

Consensus is designed to determine what qualifies as successful collective agreement within the protocol for a proposal to execute. A proposal will remain in a state of active voting for 120 hours, regardless of initial voting outcome, to allow for participation and as a risk mitigation tool. The proposal voting period will end after the 120 hour mark. Then the proposal will either be moved to execution timelock (passing vote), or be closed (failing vote).

Voters will have their vOHM locked for 7 days after performing a vote action, this ensures tokens used to vote on a proposal are committed until the end of the proposal process. Voters may use their vOHM to participate in more than one proposal vote at a time, the locking period resets after the last action taken. Locking the vote tokens prevents flashloan attacks and also ensures that the total voting supply is known for a particular proposal- this helps to mitigate last minute voting attacks as the total supply is known and fixed.

Having a fixed voting time period allows for voting until the end of the time frame, not just if quorum is initially met. This prevents proposals from quickly reaching quorum and passing before allowing all eligible voters a chance to voice their opinion- especially important as Olympus has a global reach with community members spanning all time zones.

Counting Votes: deltaVotes

The Olympus Governance system uses a unique method to determine whether a proposal is considered passed. While most governance systems use a simple quorum threshold and majority voting, Parthenon uses a passing criteria called deltaVotes, which is calculated as the margin of votes between yes and no. In the governance system, the percentage of total voting supply that a proposal must reach in deltaVotes is determined by the EXECUTION THRESHOLD, which is initially set to 33% of the circulating votes.

There are a few interesting properties of voting that emerge with deltaVotes. First, the quorum is not a static number, but adjusts dynamically higher as a vote becomes increasingly controversial. If a proposal has no opposition, only 1/3 of the voting supply needs to participate for the proposal to pass (quorum: 33%). However, if a proposal has 1/3 of the voting supply opposing it, then the entire voting supply is needed to pass a proposal (quorum: 100%), because it would require 66% of the voting supply to approve it to reach the prerequisite deltaVotes. As a result, dissenting votes on a proposal will increase the baseline quorum for that proposal to pass. Controlling 1/3 of the voting supply grants that voter (or collective group of voters) unanimous veto power in the governance process, preserving minority interest.

Execution: Ensuring Proposal Success and Time for Dissent
The execution mechanism determines proposal success & ensures enough time is given to dissenting voters to react to incoming proposal effects prior to execution. The execution timelock will have a duration of 48 hours. Proposal posters must execute the proposal after this timelock, but before the execution deadline which is 48 hours after the timelock period. Failure to execute the proposal during this time period will result in the proposal being closed, and collateral locked for 16 weeks. The timelock also plays an important part in the initial setup of the system where a Safety Backstop is implemented.

Safety Backstop: An Additional Layer of Security

The Safety Backstop is a critical component of the new governance system designed to provide an additional layer of security from malicious proposals as we transition to this new on-chain state. The Safety Backstop was created to ensure that the governance system can be frozen in the event of a governance attack (i.e. malicious proposal). This action prevents proposals from being executed and gives the community time to respond. The emergency multisig will have access via the Safety Backstop to ensure that we have a safe and smooth transition to our new governance system. The intent is to phase out the Safety Backstop over time as the governance system proves itself and community trust has been built that the process is operating as designed.

There are a number of ways a proposal can fail along the path. Active participation from the proposer is necessary for a proposal’s success. Initial governance participation (outside of testing) will be on Ethereum. Initial operations recognize OHM and gOHM in exchange for voting tokens.

A note on Cooler Loans

Cooler Loans present a unique challenge to governance. Cooler Loan takers have a limited financial risk as they've converted some backing to DAI. With terms as favorable as Cooler offers, looping multiple times into Cooler gives users the ability to significantly multiply their gOHM stack. To strike a fair risk balance, it makes sense to limit the governance power that gOHM in Cooler Loans has. We propose to apply a 95% reduction in governance power to gOHM in Cooler.

Knowing that Ohmies in Cooler still have the best interests of the protocol in mind, it's beneficial for all to design a system which lowers the friction needed to "upgrade" to 100% voting power if needed. Enter Parthenon Loans.

A Cooler user may choose to put up their borrowed DAI as collateral into Parthenon. In exchange, they receive the full voting power as if they were a standard gOHM holder. There are some diagrams below which provide some detail into how that could work. The protocol benefits from a boost in interested voting power. The user benefits from an enhanced voice in the protocol’s future.

Interim Safety Measures

In the spirit of an orderly transition to on-chain governance, treasury composition should remain unchanged until OCG is live.

The Parthenon framework introduces on-chain Olympus governance, enabling proposals to directly impact the codebase. Prioritizing safety and long-term viability, Parthenon maintains a design that is both straightforward and flexible. Initial parameter settings are deliberately conservative, and they can be fine tuned though governance voting as participation analytics are gathered over time.

Questions for Discussion:

  • What should the minimum supply of vOHM be to allow proposals to begin being activated? 10% circulating OHM? 50%?

  • How much governance power should OHM in Cooler Loans have? 0% reduction? 95% reduction? And should Parthenon Loans be developed in order to reduce the friction needed to regain full voting power?

  • When should the protocol phase out the Safety Backstop?

  • Does Parthenon fail to address any of your concerns with decentralized governance?

Governance flow note:
This is a major change to the protocol which has been discussed extensively already. We want to give everyone ample time to consider this concrete proposal. We'll have one week of discussion via RFC and community call, followed by up to a week to rework the proposal, then 3 days of RFC + 7 days Snapshot. Total governance time is up to 24 days.

What should the minimum supply of vOHM be to allow proposals to begin being activated?

This piece should be driven by supply concentration. I don't have that in front of me right now so can't contribute, but that's how it should be decided. It also should be subject to periodic review as supply concentration changes.

OHM in Cooler Loans

95% reduction. I also think Parthenon Loans should not be added. It's just added complexity. If your interests align long-term then you will want to participate in governance. Participation in governance should require holding OHM for the same reason. Allowing a user to participate in governance via DAI from Parthenon Loans effectively allows a user to participate while short.

Safety Backstop

Phase out in 1 year, pending a future RFC that assesses the health of the system at that time.

Other Concerns

We need to work on the social aspects of governance:

  1. Emails, texts, twitter, wallet - wallet messaging, etc. to make it easier to monitor proposals
  2. A healthy system probably carves out yearly funding for an analytics team to review active proposals from a security & economics perspective. In my view this would be a separate RFC and could allow for multiple teams to put forward proposals & pricing.

Based and governance pilled!

On cursory reading this seems well written. Will have to take more time to digest.

sorry for late response to this - looks great, glad we reached consensus in Discord and ironed out everything. Would just echo what @lasso said in Discord about using sDAI for Parthenon Loans, but can't see that being contentious.

5 days later

Interesting proposal sers, thank you! I have two questions.

  1. The vOHM that is borrowed from Parthenon Loans are transferrable or not? Can I pair them against DAI and set up a Uni v2 pool?
  2. What happens if I change my mind on a vote that I placed? Does the 7 day vOHM lockdown reset? Am I allowed to change my mind on the same proposal?
    5 days later

    luzdeltemplo

    1. vOHM is non-transferrable
    2. votes are final, you can't change your mind after voting. Voting is an action that kicks off the 7day lock. If you vote on a different proposal it will then reset that countdown.

    9 days later

    I do have a concern when it comes to reducing/removing voting power from Coolered supply. I understand that the intention behind this is to prevent the accumulation of undue influence via Cooler looping, but I think it inadvertently increases the risk of gov takeover instead. This is true if Coolered supply can be used as a proxy for active supply -- if you are active, you are likely Coolered because not doing so has greater opportunity cost than the interest paid. Assuming most active supply is Coolered, and assuming you've taken away governance power from Coolers, your remaining voters are now either inactive supply that will not vote, or a small non-coolered active subset. This is especially problematic in the current situation in which 100m sDAI remain in treasury and OHM trades roughly at backing -- that small active non-cooler minority can now control these funds in an OCG world.

    TL;DR to this point: if Coolers have (close to) no votes, you exasperate the honeypot problem by allowing less supply to control governance (they just can't be Coolered).

    Another important thing to note is that the execution of this attack does not require concern about the tokens purchased to execute it. An attacker paying 10m for OHM used to steal 100m DAI does not care about the OHM after the fact. This removes the efficacy of a locking mechanism (at least in this scenario).

    This is the single biggest danger when it comes to governance imo. Note that governance structure itself is only one piece of the puzzle -- I think no matter how you slice it, this danger exists so long as it is possible to move around funds. I think two things that fix this are:

    1. Restrict governance from controlling present treasury funds. What this would look like is gating those funds into a clearinghouse-only structure, where governance can possibly control loan-to-collateral (within rational bounds) but cannot move them outright. Yield can be accounted for and pointed to new places, but todays backing remains outside the purview of governance and thus beyond the risk of attack.
    2. Consolidate system modules into simple parameters. Again, reducing attack surface area reduces likelihood of attack, or cost from attack.

    The two of these satisfy my concerns without looking at governance structure itself. However, I do think that with them implemented, the complexity of the system outlined in this post may be unnecessary. I am personally more of a proponent of a classic Governor Bravo system (the current industry standard), as it comes security tested with full tooling out of the box and is the simplest UX-wise of any solution. I'm not sure this is a hill I want to die on though, considering the effort that has been put into this Parthenon system to date. My main worry is making sure we don't get rugged and I think the solutions above do plenty to accomplish that.

      nicnombre thanks for the input. I agree that the locking mechanism is kinda pointless with cooler loans active.

      I also tend to agree with your proposed fixes to simplify the Treasury by basically bricking access to the funds.

      With the first fix, the main drawback is that the protocol would be "locked in" to using DAI forever. I could imagine that a change to the DAI token would end the current instance of the Treasury. In that case, users could migrate via Cooler to a new Treasury that accepts the new token. It'd be quite painful though and likely would have a significant loss of users in that case.

      It's an edge case but it definitely is a major impact, should it come to be.

      Write a Reply...