Define governance consensus mechanics

[sajanrajdev]

• Decisions around the governance reach has been made: https://github.com/Badger-Finance/ebtc/issues/237#issuecomment-1480022406
• Specs for the technical implementation have been generated: https://github.com/Badger-Finance/ebtc/issues/278

Let's use this ticket to track the definition of the consensus mechanism of the governance. In other words, how will governance look like from a user/team/DAO perspective:

• Timelock (What period, will there be veto?)
• Multisig (policy of x/n and internal, external or mix signers)
• Transparency (Governance process definition, will there be a Frontend?)
• Separate from Badger? Can we use or partially use the Gov 2.0 setup?

@spadaboom

[ICEBADGER]

@sajanrajdev I think we need to prioritize this one for next week. We may not be able to finalize, but we should at least make some progress towards defining a list of parameters etc.

Going to adjust the ship date and iteration accordingly.

[spadaboom]

Governance Consensus Mechanics

As agreed in #237 there are 5 parameters where governance consensus are involved.

Fee oriented

• Redemption fee
• Collateral yield share

Protocol/Emergency Oriented

• Oracle backup swap/addition
• Extensible minting w/caps
• Emergency withdrawal mode

There are 3 categories of governing bodies that could make these decisions;

• External/shared multisig
• Internal multisig
• Badger token holders via onchain/offchain governance

Fee oriented parameters

To make it simple. I don't think anyone outside of Badger should govern anything fee related because Badger DAO is the sole recipient of these fees.

Within that, with Gov 2.0 and introduction of the association framework, Badger DAO has moved to a representative democracy based model. Where qualified participants are voted in to council roles by token holders on a semi-frequent basis and those token holders approve the policy to which they council members can operate within.

For that reason and the obvious aligned interests of council members, I propose the fee oriented parameters are governed by the Badger Association Council. This should be a 5/9 multisig threshold without timelock or VETO. Timelock doesn't add additional security and the fee % when broken down per day is so small even if its moved to 100% that a user doesn't need days during a timelock to exit.

Protocol/Emergency Parameters

These parameters are a bit trickier since they could technically affect the underlying protocol and its users. Although adhering to non-custodial methodology there still is a direct impact especially if used maliciously.

That coupled with the desire to decentralize the protocol as much as possible I think we should have an external multisig with strong defi protocol representations (those with vested interest like the DAO issuing the liquid staked eth token we use as collateral, liquidity DEX, bribing market etc.) + Badger contributors on it to govern these parameters.

The question is do we start there or do we end there?

Out of extra per-caution and for ensuring further skin in the game from a partner protocols, my suggestion is we progressively move to this model and start under the same governance framework as the fee parameters (Badger Association Council Multisig) both without timelock or VETO. I think both timelock and VETO defeat the purpose of emergency actions and with caps in place on Extensible minting, that protects against malicious actions.

As eBTC grows, has larger collateral, more external protocol integrations, larger participant in DEX liquidity etc. we should look to have a 5/9 multisig comprised of these protocols where eBTC is most used.

Banning Governance Rights

This parameter should be under timelock and VETO. Based on the stage of governance progression, it should be enforced by whatever multisig is controlling Protocol/Emergency Parameters at the time. (external or the association).

[sajanrajdev]

@spadaboom, I agree with almost everything in your proposal with the following exception and notes:

• I think that the extensible minting feature should be subject to a Timelock and Veto. I can't think of an emergency situation that would require of quick access to this feature. Even if capped per contract, it can be abused by introducing multiple minters if the multisig is compromised. Also, given the criticality and potential risks that this feature can introduce I can see there being an extensive development, testing, auditing and governance process before any contract can be enacted which justifies a lot more the introduction of a Timelock and veto as an additional security and transparency measure.
• With that being said, I think we should also be specific around the Timelock's period. Based on what I have seen in the industry, I propose a 1 week period. I think it is reasonable for the timelocked functions and shows a strong stance on transparency and decentralization.
• I think that having the association's multisig governing both the fees and protocol parameters to begin with makes sense with the clear and announced intention to transition into an industry multisig for the second once a number of clear checkpoints are reached.
• Given that we will use Gov2.0's setup to begin with, I think that the current Governance Transparency site should do for eBTC with minor modifications. Once the industry multisig is enacted we should modify it accordingly. Unless we want to have the transparency side within eBTC's App or Landing page. What do you think?

[spadaboom]

Makes sense across the board.

Last point you mentioned. I think the current governance transparency site is fine for now. We can work to build something in the future.

[sajanrajdev]

Closing as defined