Category: Governance
Scope: Outline phase 1 plan for DAO decentralization roadmap.
Objective: Gather community feedback and approval around proposed phase 1 transition put forward by the core team.
Status: Accepted
Overview:
Badger DAO’s intention was always to move towards a completely decentralized autonomous organization over time. Our vision is to progressively decentralize with a phased approach while retaining the ability to respond quickly in crisis scenarios. This is critical to ensure protecting users funds remains our top priority.
Today, the Badger dev team operates a ⅗ of multisignature wallet which has upgradability rights on all contracts, sets key parameters and controls permissions of the system. We started with this model to maintain the speed and agility needed to respond to any vulnerabilities if they arose in our young smart contracts.
This made sense in the first few months but now with more battle tested contracts and much larger sums of capital deposited, we should start the process towards putting control into the communities hands.
In doing this though we need to ensure that the core development team continues to have the ability to run operations on a day to day basis while maintaining the speed necessary to respond to emergency situations.
For this proposal I’d like to outline what the core team thinks phase 1 should look like with the intention of collecting feedback, suggestions and collective approval before any transitions happen. Ideally once this proposal goes through the appropriate governance processes the team can implement as soon as next week.
Specifics:
This proposal is focused on the specifics of phase 1. In creating this we collected best practices from other protocols in the space. At a later date with community feedback we will propose the larger plan toward decentralization with additional phases.
Phase 1: Segregated Permissions + Expanded Multisig + Timelock
All permissions today are in the control of 1 multi-signature wallet. We propose segregating those functions across 4 separate multisigs each having different levels of control. This will allow for greater security on the most critical areas while allowing for speed around operations and handling emergency situations.
1. Dev Multisig - The most critical
The buck stops here. The dev multisig maintains contract upgradability rights, can set key parameters to all products, controls the treasury, and manages all permissions. We propose to add a timelock shortly after the transition to phase 1. At first the timelock will be upgradable for safety, but this ability will be burned after launch.
- Expand the number of signers required from 3/5 to a 5/7.
- Make all signers public. (will announce those people if this proposal is approved). Will be a mix of community members, core team members and industry leaders.
- Add a 24 hour timelock that will increase over time to 48 hours.
2. Operational Multisig - To run the business
The operational multisig handles the day to day operations that require trust, but also speed and have a capped value lost. This multisig is restricted around what it can do compared to the dev multisig with a majority of rights removed. A variety of these functions will need technical expertise and deep understanding of the Badger system. Permissions for this address will be given by the Dev Multisig.
- Requires 2/3 Ops Members to sign off on transactions.
Rights:
- Verifying and pushing rewards weekly based on emissions proposals approved by community governance.
- Unpausing of contracts. In an emergency scenario where contracts must be paused, this gives the ability to unpause to resume functionality. Doing this without upgrading contracts (which would go through the dev multisig + timelock) will be reserved for scenarios where an upgrade is not necessary.
- Timelock Veto. The ability to cancel pending actions if an issue or mistake was discovered. The intention here is for this to be temporary as we transition to phase 1 and then we would remove this right.
3. Limited Treasury Multisig - To operate effectively
Separating payments is an important step to allow for the core development team to operate effectively. Members of the operations team who for many reasons wouldn’t be on the dev or operational multisig can perform functions necessary to operate the business like day to day payments.
- Requires to 2 of 5 signers for transactions. These signers are Ops Members.
- Allocated a budget by Dev Multsig every quarter.
War Room Multisig - Emergency situations
The war room consists of a dedicated technical group whose sole responsibility is to be prepared for an emergency situation and respond quickly. This war room will have 24/7 coverage following the sun, multiple encrypted channels of communication, deep understanding of the Badger systems, and defined roles within the group. These signers will primarily be trusted industry participants along with a few core team members.
- The only right this war room has is to execute an emergency contract pause. Nothing else, including unpausing. The purpose of this is to be able to stop any vulnerability as quickly as possible. Without this either the dev or operational multisig signers would need to be available to execute this function. In some scenarios that will be the case, but as we have seen in recent exploits in DeFi, due to inability for signers to be reached, more damage was done that could have been preventable.
- This would be a 1/N meaning any 1 person on this multisig will be able to pause without the need for multisig members to sign off.
Implementation:
If this proposal is approved by the community the core development team will implement all parameters outlined in phase 1 and share all relevant information with the community including new multisignature addresses. The intention would be to complete this transition shortly after the official snapshot vote if this proposal gets to that point.
If you are FOR this proposal vote FOR.
If you are NOT FOR this proposal vote AGAINST.
- For
- Against
0 voters
