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:
(High consensus, not malicious) = low quorum
(High consensus, malicious) = high quorum, high majority approval
(lack of consensus, malicious) = high quorum, high majority approval
(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:
Reasonably high quorum
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.
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.