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 RFC 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 three-stage rollout of on-chain governance:

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

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

  • OCG Stage 3 (end of Q4 2024) - Deprecate emergency MS

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.

Governor Bravo vs Parthenon

To implement a governance-minimized structure, we have two potential solutions: Parthenon and Governor Bravo. The Parthenon 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 for the Parthenon governance system, 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 a Parthenon implementation would require dev and time resources, taking focus away from current RBS 2.0 audit.

What about governance risk? Governor Bravo uses majority voting - a minimum number of YES votes (i.e. the quorum) is required to pass any proposal. There are two governance risks to consider: first, if the quorum is too low, a single adversary can pass a proposal that benefits them at the expense of tokenholders. Second, when quorum is too high, no proposal can pass because of dead gOHM supply, effectively bricking the protocol. To mitigate both governance risks, a quorum should be chosen with this in mind:

  1. No single faction has enough for a majority vote - this prevents a single ideology from taking over the protocol. For context, the largest gOHM holder using Cooler Loans owns 10.88% of supply. Top 10 Cooler Loans users own 29.31% and Top 20 own 37.28%.

  2. Require consensus from major factions - each faction serves as checks and balances against other factions. With a high enough quorum, a proposal from one faction must gather enough support from the opposing faction. Thus, any proposal that passes will at least have consensus from major factions.

  3. Acquiring supply should be hard - if a faction were to bypass other factions, it should have a hard time acquiring large enough supply to become the majority vote. The ability to loop in Cooler Loans makes this theoretically possible but a high quorum makes this practically improbable. Consider that AMM liquidity today is ~1169 gOHM, or 1.95% of gOHM supply. A quorum of at least 10% means looping, by itself, is not enough to reach a majority. There are, of course, other ways to acquire OHM (e.g. otc trades)

  4. Account for dead supply - if the quorum requires tapping into gOHM supply that is dead, the protocol won’t be able to make any upgrades, effectively bricking it. One way to avoid this is to use Cooler Loans as a benchmark for active gOHM supply, which today sits at 58.44%. We know for sure that this supply has been active in the past 4 months (since launch of Cooler Loans). Keep in mind that dead gOHM supply can increase over time, in particular if a large % of Cooler Loans default.

In general, the highest quorum that does not brick the protocol should be chosen. One may argue that this limits upgradeability of the protocol in the future but that’s by design. In a hyperstructure, any proposal implies the current mechanisms are deficient in some way, and thus in need of maintenance, contradicting the notion that the protocol is a hyperstructure in the first place. There are extreme cases where a protocol should need upgrading but that should be rare, and require a true majority participation and consensus.

Parameters

So what's the best path forward? We deploy OCG with Governor Bravo and implement "minimal governance" with full voting power for all. Broadly, this means:

  1. Spot gOHM and gOHM escrowed in contracts with delegate ability get voting power (i.e. Cooler Loans)

  2. Limit governance to select few system parameters

  3. Require high quorum. Very few decisions should make it to OCG, and if they do, should fail unless quorum is high.

Specifically, here are the proposed parameters for Governor Bravo. Definition for each can be found in docs:

  • Quorum Votes: 33% of gOHM supply

  • Proposal Threshold: 10 gOHM (this is ~$31K or 0.017% of supply)

  • Voting Delay: 1 day

  • Voting Period: 7 days

  • Timelock: 1 day

The 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 three-stage migration plan over the course of 6 months:

  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

  3. OCG Stage 3 (end of Q4 2024) - Deprecate emergency MS

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:

OCG Stage 3

The high-level goals of this stage are to deprecate Emergency MS. After this, Olympus becomes a hyperstructure. The specific implementation is proposed below:

    Great proposal! Governance should be straightforward and effective, full support from me. I do have a question regarding Boosted Liquidity Vaults – is there a plan to reinstate them?

      streetjesus thanks. Regarding BLV, decision to re-instate should emerge from community and go thru on-chain governance when live. A perfect use case, imo.

        Strongly in support. Definitely agree that quorum should be relatively large to ensure votes are only implemented when it has strong, majority support from holders, due to Olympus's goal to be a stable reserve currency not requiring active governance or changes to fulfill.

        I am for it but I would increase:

        the voting delay to 2 days

        the voting period to 10 days

        the timelock to 2 days

        Any proposal that happens will likely be significant and I think we should have more time for the community to learn about it and react to it.

        Also I think for a proposal to pass it should need maybe 60% of those voting to vote for it instead of just over 50% like what it seems like in the compound docs.

        unbanksy33

        While the goal of re-shaping Olympus into a hyperstructure entity is laudable, I think that the quorum is far too high and carries an unreasonably high risk of bricking the protocol. Here you are proposing that 33% of gOHM supply or approximately 5.33mm OHM votes are required to meet quorum. The most notable Olympus proposal in recent memory was the Cooler proposal (TAP-28) which had a voter participation of ~2.5mm OHM votes. What is the justification for setting OCG quorum to 2X higher than the vote total in one of the most highly debated and highly participated proposals in Olympus history?

        We should not conflate a higher threshold for approval with a higher threshold for quorum. The failure to achieve the former suggests a lack of community consensus, whereas the the failure to achieve the latter merely reflects voter apathy which is endemic across all DAOs. There is zero evidence provided to suggest that the inertia from apathetic or indifferent voters is the true governance safeguard of the DAO. One can make a far more compelling argument that active gOHM holders are the stakeholders who are looking out for the best interests of the DAO and not the inactive holders.

        IMHO we should not use an arbitrary % cutoff based off a meme as the baseline for quorum in OCG. I would suggest an alternative criteria for OCG where we use numbers that are close to the empirical numbers from an actual recent snapshot e.g. TAP-28 to set the governance parameters:

        1. 15% of gOHM supply (~2.4mm OHM) is the quorum for a new OCG proposal
        2. 75% YES (approve) is the threshold for passing the OCG proposal

            luzdeltemplo thanks for feedback.

            Regarding approval thresholds, Governor Bravo contracts are simplistic and do not allow for approval thresholds. The quorum, therefore, serves a dual purpose of a minimum participation AND approval threshold.

            Regarding quorum, my choice of 33% is not arbitrary but based on the following:

            • Cooler Loans utilization is at 58% of gOHM supply. Imo, this is a better indicator of "active" vs "inactive" supply than TAP-28,
            • When looking at voting patterns of Cooler Loan participants, 34% of gOHM supply voted in at least one proposal in the past 6 months. This makes 33% quorum a matter of coordinating active voters rather than engaging apathetic voters.
            • No entity should single-handedly make decisions for the entire protocol. Olympus has thrived from dissenting opinions and, going forward, it's even more important to keep Olympus resilient/anti-fragile in absence of a human-managed multisig. The entity with the most supply today is TempleDAO, at 11.5% of gOHM supply. Owning large chunks of supply is not necessarily bad, but it should be taken into account when designing quorum threshold.
            • Any defaults in Cooler Loan will shrink the total supply, thereby increasing % ownership of remaining active holders. This is a minor point but should still be considered.

            I concede that 33% is a meme number but the process for arriving at that number was not of memes. The right number is probably a few percentage points up/down, but not 15%.

                unbanksy33

                Let's set aside the dubious proposition that Olympus protocol should be made static in a space that evolves rapidly. The highly subjective nature of how you came to this quorum threshold strongly suggests that it is fundamentally incompatible with the best interests of the DAO.

                1. You cannot project voter participation in the future and therefore should set threshold conservatively. There's no reason to think just because someone voted one time means that they will continue to do so. In fact, it is highly likely that they will become more and more inactive given that Olympus is more or less bricked at 33% quorum. And even if they are not totally inactive, given the anonymous nature of DeFi, how are these potential voters supposed to "actively" coordinate with each other?

                2. You've singled out Temple as the reason why you're proposing to set the threshold so high even though Temple A) Does not control a particularly high percentage compared to governance whales in other Protocols; B) Is a DAO member in good standing, and C) Has not even put forth a single proposal of its own. Where does it say in the hyperstructure paper that preventing any individual holder from meeting quorum is critical system specification? Are you willing to risk bricking the Protocol just to prevent Temple from being able to meet OIP quorum on its own in the distant future?

                3. There is no evidence and no example to indicate that Governor Bravo was designed with work with such a high quorum threshold. Even Compound which already has implemented Governor Bravo has set a threshold of 5% of COMP circulating supply. You are proposing a threshold that is more than SIX times higher. Why should DAO stakeholders support this sort of experimentation?


                  IMHO we should move away from setting a quorum threshold in such a subjective and presumptuous manner and let empirical data decide. Since you believe that Governor Bravo is a mission-critical path that lays the foundation for the future of Olympus, then it should most definitely garner high voter participation on par with future proposals in a world determined by Governor Bravo.


                  We should set the quorum to the actual total vote participation for Governor Bravo OIP. If 5mm OHM vote in this OIP then the threshold will be set to 5mm OHM.

                    luzdeltemplo

                    1. What you're proposing (being conservative) opens the protocol to a governance attack whereby a minority can take over the treasury at the cost of other tokenholders. I don't think majority of holders want that. So being conservative is the wrong way to think about this.

                    In your second point you say that inactivity will follow from a bricked protocol but that's based on a false assumption that high quorum bricks the protocol. So the conclusion is a non sequitur.

                    2. "Where does it say in the hyperstructure paper that preventing any individual holder from meeting quorum is critical system specification?" An individual holder meeting quorum, and thereby taking control of the protocol, breaks the Unstoppable and Credibly Neutral property of the hyperstructure. On the former, that holder can vote to shutdown the protocol. On the latter, that individual holder will exert their bias to steer protocol in the direction they choose (at expense of other tokenholders)

                    "Are you willing to risk bricking the Protocol just to prevent Temple from being able to meet OIP quorum on its own in the distant future?" Loaded question so I'm going to unpack this. First, my goal is to NOT brick the protocol. My goal is to create a governance system that balances continuity with neutrality. The simplistic nature of Bravo forces us to debate the quorum threshold.

                    Second, if a single entity has the ability to reach quorum, then that should be seen as a governance attack because that entity can vote AND pass a proposal that benefits them at the expense of all other tokenholders (i.e. redirect $180M to [enter wallet address]). If you're saying that entity would never do something like that, then you're asking tokenholders to enter into a social contract with that entity. That defeats the purpose and ideals of a trust-minimized, resilient and unbreakable protocol.

                    3. False equivalence to compare Olympus to Compound or Uniswap. First, largest voting blocks of Compound and Uniswap are well-known VCs that are closely aligned with the founding team. The 5% quorum hides an unspoken social contract between the protocol's core team and those holders. Olympus is one of the few projects in crypto where token distribution was, more or less, fairly distributed over time. Or, at least, more fair than Uniswap/Compound. Unfortunately, that means it doesn't benefit from any social contract. Lacking that, quorum threshold should be higher than Compound/Uniswap.

                    Second, it's important to know WHAT you're governing over when comparing Uniswap/Compound. UNI holders can vote to turn on the protocol fee switch and grants. COMP holders can vote on various lending market parameters. None of these are nearly as high stakes as what you're governing with Olympus: $89M DAI (total treasury minus borrowed via Cooler).

                    Regarding your proposal to use total vote participation in Governor Bravo OIP, consider the following governance attack: large voting block chooses to abstain from participation, creating an artificially low quorum. With that ratified, the block votes to direct the treasury to their wallet address. Let's avoid inventing new governance mechanics in forum posts.

                    Instead, let's focus on Governor Bravo and arrive at a consensus for quorum. I'm going to look into feasibility of introducing an Approval Threshold (as you suggested in your initial post). Having that + a lower quorum may provide a path forward.

                        4 days later

                        Alright, I've confirmed that we can customize contracts to include approval threshold. We now have two levers to pull with respect to governance. They are:

                        1. **Minimum Quorum** - Minimum FOR votes needed. Measured as % of total gOHM supply at time of proposal,

                        2. **Majority Approval** - Minimum percent of FOR votes relative to total votes needed

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

                        Introducing majority approval **allows us to reduce minimum quorum without increasing risk of governance takeover**. This is possible because while a malicious proposal may reach quorum, approval provides a second level of defense to rally to defeat it.

                        But approval threshold introduces a new type of governance attack that I want to highlight: filibustering. High majority approval make it easier for a minority malicious actor to vote AGAINST any proposal (an act known as filibustering in United States Senate) and cause a governance stalemate. For instance, if approval threshold is 75% and 21,000 gOHM vote, then it takes only 5,250 gOHM voting AGAINST to defeat any proposal. This becomes problematic if there's a minority voting block that wants to disrupt protocol upgrades temporarily or permanently. For context, United States Senate started with simple majority (50% approval threshold) and evolved toward a supermajority (60% approval threshold).

                        I'm proposing a 25% minimum quorum with 55% majority approval. 25% quorum is 14,992 gOHM as of today's balance and represents around 42% of Cooler utilization. 55% majority approval is close to a majority but provides leeway for voters to push proposal forward OR block proposals. This represents a balanced approach.

                        Recent discussion centered around 33% quorum being too high. The arguments have focused on using false analogies comparing Olympus to Compound/Uniswap, or pointing to Olympus' past voting history and saying high quorum is unrealistic. So I want to back my decision with numbers:

                        • I've identified 14,130 Coolered gOHM that has voted in at least half of all proposals in past 6 months. In fact, most of these are active Discord community members.
                        • 1,520 Cooler gOHM are identified as pOHM and have voted in at least 5 proposals in past 6 months.
                        • There is a further 8,830 gOHM that I've identified belong to pOHM or pOHM-proxy wallets that haven't voted on proposals (but have utilized Cooler). I believe these to be active holders that will exercise vote if required.

                        This represents a potential 24,480 active voting power, excluding any "smaller" wallets that represent another 10,569 in potential voting power.

                        I've also heard arguments that Cooler Loans defaults will increase chances of bricking the protocol. I disagree; in fact, defaults will make it easier to reach quorum. That's because quorum is defined as % of gOHM supply at time of proposal; not a fixed number. Here is a simulation of what gOHM supply remains after X% defaults, and how this changes the minimum quorum and majority approval needed:

                        Notice how in the unlikely event of 75% Cooler Loan defaults, 8,762 gOHM remain in Cooler with 8,420 needed for quorum. Even in this unlikely scenario, quorum is able to be reached.

                        Finally, I want to re-iterate that this proposal breaks OCG into three stages. The first stage, aiming to be completed end of January, will start Olympus on that journey. The actual migration to Governor Bravo, and where concerns of bricking the protocol become real, won't happen until Q3 2024. We can also adjust as we approach this deadline.

                        For the reasons above, I'm proposing we move forward to OIP with 25% minimum quorum and 55% majority approval.

                          Thanks for your work on this Unbanksy. I think we've had the right level of discussion, here and on both discord servers, to move forward very confidently.

                          On a personal note, I think the solution we've whittled down to is a great compromise of security, customized to our needs at Olympus, fairness to all Ohmies and familiarity to the rest of Defi. I'll be voting in favor of this when it comes to OIP and inshallah Snapshot.

                          unbanksy33

                          You seem to think that numbers are self-evident unto themselves without acknowledging the deeply subjective interpretation you are using to color those numbers. Not a single proposal related to OCG has had 25% of gOHM supply voter participation including Cooler loan yet I'm accused of propagating a false equivalence to use Olympus voting history to draw a parallel between what is a reasonable quorum and what is not. It's false equivalence to use historical voter participation to project future voter participation.

                          I've identified 14,130 Coolered gOHM that has voted in at least half of all proposals in past 6 months. In fact, most of these are active Discord community members.

                          • Please show how you know that "most of these are active Discord community members". If they are so active why did so few of the 14,130 gOHM vote in TAP-28?

                          1,520 Cooler gOHM are identified as pOHM and have voted in at least 5 proposals in past 6 months.

                          • I do not have the means to check your numbers, but you again refuse to address your presumption that voter participation in the past predicts future participation. This is a false assumption. The voting history of Olympus strongly trends toward dwindling voter participation yet you seem to ignore this historical observation completely.

                          There is a further 8,830 gOHM that I've identified belong to pOHM or pOHM-proxy wallets that haven't voted on proposals (but have utilized Cooler). I believe these to be active holders that will exercise vote if required.

                          • You subjectively "believe" that these dormant voters will vote "if required" based on what evidence besides your own inclination to believe that to be true? Do you control those voters?

                          Let's follow the flimsy logic of designing the quorum around the current % of gOHM supply that Temple owns to the bitter end. Temple currently owns about 10% and you say the quorum should be set to 25% or 2.5X the percentage controlled by Temple. If TempleDAO increases its share to 15% of gOHM supply due to Cooler defaults, then you will certainly come to believe that the 25% quorum is too low. If TempleDAO one day owns 20% of the gOHM supply inshallah will you try to increase the quorum to 50% to restore your perfect governance moat against a Temple takeover of Olympus?

                          Economic interests are aligned through deployment of capital NOT arbitrary chamber rules that you decree. Quorum is primarily intended to reduce spam not block governance whales. It is fruitless and counterproductive to design a governance system that works heavily against the largest token holders just because you really like hyper structures, and then accuse them of untoward motives when they wonder why they are being asked to vote against their own interests.

                              unbanksy33 thank you for your comment. Based on comments here and especially on discord, this RFC is not ready at all to move to OIP.

                              Your data points need to be confirmed and as you did not want to share them here or on discord, it needs to be done manually by holders. 25% quorum is way too high based on all historical data, but also based on data from other defi governances. And a governance should not be built on beliefs or trust that some holders that have never voted, will vote when time comes.

                              Imho, this RFC needs more time and work before push towards OIP.

                                luzdeltemplo

                                https://docs.google.com/spreadsheets/d/1efmaBlLZMZqp3m1o-2F1RMiDbmwem013XJuOO-X7dnE/edit?usp=sharing

                                Here is a spreadsheet that shows Coolers, balances and # of proposals addresses voted on in proposals past 6 months. There are two categories, defined as follows:

                                • Active - someone who has voted in at least 5 proposals in past 6 months OR is a known wallet of an active DeFi persona
                                • pOHM - someone who received pOHM or is a proxy of pOHM holder (directly or indirectly)

                                For simplicity, I excluded wallets with < 100 gOHM. Here is the gOHM balance broken down by category:

                                Active gOHM represents 25.39% of supply, enough to clear quorum threshold. Keep in mind this is Active only (which we know to have voted in at least 5 proposals in past 6 months or are known to be active in DeFi presently); there are also active pOHM holders voting, representing an additional 2.82% of supply. Notice how 28.21% represents active gOHM supply without ever invoking the dormant pOHM holders.

                                You keep harping on the voting history of Olympus as the raison d'etre why 25% quorum is unreasonable. Yet consider this:

                                1. 28.21% of gOHM supply is active and has had significant voting presence in the past 6 months. This is facts that fly in the face of historical voter turnout for a single proposal. What this shows is that you can coordinate supply but not when you cherry-picking single proposals.
                                2. Proposals in the months leading up to Cooler Loans had poor voter outcome but Cooler Loans onward saw a 10x+ increase in voter outcome. This again demonstrates that historical voter turnout is a poor indicator for protocol paradigm shifts. If anything, Cooler Loans has shown the potential of voter turnout going forward.
                                3. OCG is a paradigm shift in governance and there should be few (if any) proposals per year. The engineering effort being done to launch RBS 2.0 and OCG is meant to reduce protocol upgrades such that the protocol runs autonomously, without management and without need for governance except in certain situations. Historical voter turnout was around meaningless proposals such as "Cross chain native OHM as bonus project for 2023". Future proposals should be few but deeply meaningful - and a high quorum is what makes them meaningful.

                                I hope this puts to rest the argument that I ignore historical observations completely.

                                You say: "Quorum is primarily intended to reduce spam not block governance whales". Huh? By definition, a quorum refers to the minimum level of vested interest needed to pass a proposal. If you see quorum as a spam filter then you're missing the point: vested interest of Olympus is not just TempleDAO. It's ALL of the tokenholders. And it's only fruitless and counterproductive if you believe my goal is to somehow sabotage TempleDAO. If you take the alternative view that choosing the right quorum is about long-term sustainability for Olympus, you would be less likely to accuse me of untoward motives.

                                I've said this before and I will say it again: my role at Olympus is not to prevent a governance takeover by TempleDAO for all eternity. I have no interest in living my life, meticulously watching your wallet address and devising nefarious quorum schemes that disenfranchise you until end of time. I am tasked with finding a path forward for OCG in the present. That path includes preventing a scenario whereby a single entity votes AND passes a proposal that benefits them at the expense of all other tokenholders, in the present moment. If TempleDAO manages to secure 50% of gOHM voting supply AFTER OCG is live, then so be it.

                                  4 days later

                                  The Temple community remains steadfast in our belief that the premise for setting the Olympus OCG threshold as high as 33% is deeply flawed based on both logical analysis and quantitative analysis.

                                  First, the OP posits that the system should be protected from a potential governance attack from a 10% minority stakeholder (like TempleDAO) by setting the quorum to 25 - 33%.

                                  How can it be that those same 15% to 18% of "active voters" whose voting participation is critical to the health of the system according to the OP would do nothing to stop Temple or any other minority stakeholder from malicious actions regardless of the quorum?

                                  It is contradictory to believe that these "active voters" will be motivated to be vigilant and vote actively if the quorum is HIGH but not if the quorum is LOW.

                                  On the contrary, it is our belief that a lower quorum encourages more active participation whereas a high and seemingly unreachable quorum will only make voters more passive and pay less attention because nothing will ever happen due to the incredible systemic inertia that must be overcome to avoid NO by default. This is known as a "pocket veto" in the American system.

                                  In other words, setting an outrageously high quorum is equivalent to a de facto "bricking" of the Protocol, leaving Olympus in the control of the multi-sig signers until the end of OCG Stage 3.

                                  Second, the voting record used by unbanksy to support setting the threshold to 33% or even 25% based on his definition of "active voters" is not supported by the numbers. One of Temple's community members went through each Olympus snapshot in the past 6 months to !verify those voting wallets vs their current OHM holdings.

                                  Starting from TAP-26A (*) and including only wallets that hold > 100 OHM:

                                  * unbanky included TAP-25 which was actually 7 months ago and should not have been included.

                                  Total percentage of OHM supply that voted at least once during this time frame: 34.33%

                                  Total percentage of OHM supply that voted at least 5 times (unbanksy arbitrary criteria): 19.84%

                                  Total percentage of supply that voted at least 5 times OR used to be active earlier in OHM discord OR known major holders (known Team members plus prominent holders et al): 27.17% (this inclusion criteria is more expansive than what unbanksy suggested).

                                  Based on our research, and using unbanksy's own definition, only 19.84% of OHM supply can be confirmed as active and on top of that an additional 7.33% have been active before this 6 month time frame OR are known large wallets that may theoretically be activated via direct contact.

                                  Therefore we believe that the interpretation that "28.21% of gOHM supply is active and has had significant voting presence in the past 6 months" is pure speculation and is not supported by available voting records.

                                  Furthermore, this interpretation assumes that these "active holders" will continue to be active into the future with no reduction in voting participation. In my view this is an unsubstantiated assumption free from any supporting evidence.

                                  Based on the arguments above, I support ending further debate on this RFC and moving to snapshot with two additional voting options in addition to the option proposed by unbanksy:

                                  15% quorum with 70% approval

                                  20% quorum with 66% approval

                                  Furthermore, I would like to propose an expedited timeline for the OCG roll-out in the snapshot. We can all appreciate that once RBS 2.0 is launched, initial parameters at deployment might need to be tweaked which would take longer to do if these minor changes were done through Governor Bravo.

                                  By stipulating the end of Q1 2024 as the migration date, this allots 1-2 months (as opposed to 6 months) for RBS 2.0 parameters to be tweaked if necessary before transferring control to the Governor Bravo module. Barring new circumstances, I don't see any justification for an additional 3 months e.g. end of Q3 2024 before migration of DAO MS to Governor Bravo.

                                  OCT Stage 1: End of January 2024 (same as OP)

                                  OCG Stage 2: End of March (Q1 2024)

                                  OCG Stage 3: End of June (Q2 2024)

                                    Gm,

                                    After multiple convos and community feedback, I’d like to propose revisions to my RFC that I believe represents a fair compromise for all. Before I dive into these revisions, I’d like to suggest a lens through which to view the governance parameters. The depth and breadth of discussions around this reflects the complexity of the problem, and it would be helpful to have a framework by which to judge whether the chosen governance parameters. We cannot predict what future governance will look like but we can evaluate the efficacy of the parameters through a game theoretic lens.

                                    Governance through the lens of game theory

                                    Governance can be thought of 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 and a detailed analysis following that:

                                    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

                                    (High consensus, not malicious) = cooperative

                                    Situation: in this situation, proposals are non-controversial and provide clear win-win benefits to the protocol (as viewed by most tokenholders).

                                    Dominant strategy: as this benefits most, the optimal decision for tokenholders is to cooperate to pass the proposal. There will be little to no AGAINST voting so the primary challenge is not opposition but reaching quorum. The lower the quorum, the better. If the quorum is too high, even win-win proposals will have trouble passing (“bricking”).

                                    (High consensus, malicious) = deterrence

                                    Situation: Malicious proposals where there is high consensus are exploits by outside parties (e.g. Bean protocol governance hack). Alternatively, these can arise after a top holder gets hacked and the voting power transfers to the attacker.

                                    Dominant strategy: the dominant strategy is that of deterrence, and tools needed to enforce a threat of retaliation. Governance framework provides multiple tools for that purpose:

                                    1. Reasonably high quorum

                                    2. Emergency MS

                                    3. High majority approval

                                    On (1), a high enough quorum makes it harder for malicious parties to bring proposals to vote. On (2), in cases where quorum is reached, and proposal is malicious, then Emergency MS provides a way to shutdown the protocol by deactivating both treasury and minter modules. On (3), a high majority approval lowers the threshold to veto the proposal.

                                    (Lack of consensus, malicious) = defensive

                                    Situation: Malicious proposals where there is lack of consensus in the community are proposals by a tokenholders that aims to disenfranchise a subset of tokenholders. As they are malicious, there is no disagreement of their intent, e.g. “transfer the entire treasury to Top 20 wallets”.

                                    Dominant strategy: The dominant strategy is similar to the example above (deterrence) but since there's a lack of consensus, a quorum can be reached as the proposal is coming from existing tokenholders. In that case, the disenfranchised coalition can respond to aggression through a defensive strategy. A high majority approval lowers the threshold for a defensive veto. One can argue that a majority approval condition isn’t necessary with Emergency MS but there can be cases where MS bribe is part of the proposal.

                                    (not malicious, low consensus) = mixed

                                    Situation: These “controversial proposals” are well-intentioned but lack broad support due to differing opinions on potential impact. Proposals like “what is the vision of Olympus and what should product development look like as a result?” are some examples. There is no right and wrong and the important point here is to have strategies available to both parties, fairly.

                                    Dominant strategy: there is no dominant strategy as one coalition may pursue offensive strategies while the others pursue defensive strategies. Controversial proposals warrant higher engagement among tokenholders and therefore should demand a higher quorum to ensure diverse viewpoints. Furthermore, as these proposals are controversial and there is no right/wrong, dissenting minorities shouldn’t have an outsized influence on the outcome. Thus, majority approval threshold should be as low as possible (as close to 50%) to reflect the balance of power between both strategies.

                                    Revisions

                                    Revision: 20% minority quorum with 60% supermajority

                                    20% minimum quorum and 60% majority approval represents a fair compromise between various stakeholders, protects the protocol from malicious proposals while enabling future protocol upgrades. Furthermore, these parameters allow tokenholders to react under various proposal configurations outlined above: 

                                    1. (High consensus, not malicious) = cooperative

                                    A 20% quorum (11,994 gOHM) requires coordination from only Top 4 Coolers, making it realistic that the dominant strategy will have an outcome. If Top 4 Coolers are not interested, holders 5 to 21 can coordinate to reach quorum. In my previous post, I showed that 15,228 gOHM has been active in governance. This supply can be tapped to reach quorum, as well.

                                    2. (High consensus, malicious) = deterrence

                                    20% quorum, or 12,000 gOHM, makes it challenging for malicious parties to bring these proposals to vote because top holders act as guardians. Tokenholers should see this as reassuring as they don’t have to worry that a malicious proposal can go to vote at any moment.

                                    3. (Lack of consensus, malicious) = defensive

                                    Same as above, 20% quorum makes it challenging for malicious parties to bring these proposals to vote. As these proposals will be coming from existing tokenholders, it’s most likely that quorum will be reached. In that case, a 60% majority approval only requires 8,000 gOHM (or just Top 2 Cooler holders) to defeat a proposal at 20% quorum. Alternatively, if Top 4 holders collude, then holders 5 to 12 can coordinate to defeat. 

                                    How does the majority approval threshold change with increasing FOR votes? Below is a table that summarizes the AGAINST votes needed to defeat a proposal:

                                    Even for 16,000 FOR votes, a 60% supermajority requires “only” 10,666 AGAINST votes to defeat. In this case, this would require participation from all active voting supply and the 2.5% pOHM supply that has been active in voting.

                                    4. (not malicious, low consensus) = mixed

                                    20% quorum provides a meaningful threshold to bring controversial proposals to vote. I already showed that this requires participation from just Top 4 holders. 

                                    However, it’s likely that in controversial proposals, holders may engage in passive resistance by abstaining from voting. It’s important that the governance parameters allow for a smaller coalition to coordinate to reach quorum, even when top holders abstain. If the top holder abstains, those in position 2 thru 11 can reach quorum. If top 2 holders abstain, those in positions 3 thru 17 can reach quorum. And if top 3 holders abstain, those in position 4 thru 21 can reach quorum. 

                                    60% majority approval provides a fair balance between the offensive strategy and the defensive strategy, as demonstrated in the example above. That is: if 16,000 vote FOR, then 10,666 AGAINST votes represents a meaningful 17.79% of supply voting against. Here is how the distribution would change if majority approval was 75%:

                                    In this case, 16,000 voting FOR can be defeated by only 5,333 AGAINST votes, which represents only 8.89% of supply, or Top 1 holder or Top 2-6 holders.

                                    Revision: Remove Stage 3

                                    I mentioned previous that Emergency MS provides a powerful deterrence tool against malicious proposals. Whereas I previously defined a timeline for removing Emergency MS, upon further thought it’s too early to be setting arbitrary timeline. For this reason, I’m removing Stage 3 and will leave it to future OCG proposal to remove it, if the community wills.

                                    luzdeltemplo looks like we posted over each other.

                                    I don't think fragmentation thru additional voting options is needed. I believe that 20% minimum quorum with 60% majority approval is a fair compromise, and pretty close to 2nd option you're proposing.

                                    With regards to timeline, I still believe that Stage 2 should extend thru end of Q3 2024 for the following reasons:

                                    1. Cooler Loan defaults - End of Q3 2024 encapsulates two additional Cooler Loans deadlines. As these deadlines trigger, some % of holders/supply will leave the system. Having more data on this ultimately increases resiliency of the governance system.
                                    2. Migration complexity - While RBS 2.0 is an important component, it's only a subset of the entire migration process. There are about 18 roles that have to be migrated to Governor Bravo spanning Kernel, RBS, Staking, TRSRY, MINTR cross chain, OHM bonds and Distributor. To minimize risk, we should migrate these sequentially, observe for a period of time, and then proceed with next set of contracts. Targeting this to be done by June 2024 means we'd have to do several things in parallel, which adds unnecessary risk.
                                    3. General system updates - there might be new proposals that come up that require system updates. Case in point, community members are currently asking how we can make OHM votable. While these upgrades should be on-chain executable via OCG, having a DAO MS in the interim significantly reduces implementation complexity.
                                      Write a Reply...