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.

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.

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.

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.