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.
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.