Vote 27: Approve configuration of the emergency multi-sig, and define its powers

Summary

In its transition to on-chain governance, Gro DAO needs an emergency multi-sig, a type of smart contract wallet controlled by an approved committee of signers (the Emergency Multi-Sig Committee), to be able to quickly perform certain approved actions to safeguard the DAO’s interests.

If Vote 27 is passed, an Emergency Multi-Sig Committee will be elected to include 3 non-pod contributors and 1 contributor from each pod; and its multi-sig wallet will accordingly be configured to a 4-of-7 (m-of-n). An in-depth description of this proposal can be found in its RFC Forum Post.

Applications to be part of the Emergency Multi-Sig Committee are currently open, and committee member elections will take place if and after Vote 27 passes. See this separate RFC Forum Post for details on how to apply for a committee position.

DAO members can either vote:

• FOR: approve the proposal
• AGAINST: reject the proposal
• ABSTAIN: no opinion on this proposal

Implementation

The emergency multi-sig (Safe) will be configured to a 4-of-7 (m-of-n), with 3 non-pod signers and 1 signer from each pod. This is in line with similar emergency multi-sigs within other DAOs.

If a selected committee member is not performing as expected, as detailed in the ‘Requirements & Responsibilities’ section in this separate RFC Forum Post; they can be voted out by the Emergency Multi-Sig Committee or by the DAO through a Snapshot vote, and replaced through a Snapshot vote.

The emergency multi-sig will be assigned (as a ‘keeper’) to limited, DAO-approved smart contract functions for emergencies over time, specifically:

• Convex Strategy contracts’ functions:
  • setEmergencyMode → to pull assets out of a protocol strategy
  • runHarvest → to run harvests
  • stopLoss → to execute stop loss
• Guard contract’s functions:
  • setStopLossPrimer → to set stop loss
  • endStopLossPrimer → to end stop loss
  • executeStopLoss → to execute stop loss
  • harvest → to run harvests
• Governor contract’s functions (if on-chain governance is approved by the DAO)
  • cancel → to cancel on-chain governance proposals

Pros

• As Gro DAO progressively adopts on-chain governance, the emergency multi-sig will be configured to protect the DAO against governance attacks (i.e. cancelling malicious on-chain governance proposals).
• The emergency multi-sig can also conduct a range of emergency protocol functions in rare instances which may require immediate action (e.g. running harvests, executing stop losses, and withdrawing from failing protocol strategies in case of emergency or automation failures).
• To clarify, as agreed in Vote 26 and further detailed in the What is Governed by Who guide; the DAO will make all key treasury, meta-governance, tokenomic, and protocol- related decisions following the standard governance process (taking up to 11 days); while the objective of the Emergency Multi-Sig is to serve as a safety precaution in rare instances where a quicker turnaround is required.
• By being composed of elected non-pod and unique pod contributors, as well as having a 4-of-7 pool of signers, the emergency multi-sig distributes its power across Gro DAO to minimise any chance of collusion.

Cons

• Signers may not be able to act as swiftly as desired in all situations, though this should be mitigated by having DAO-approved signers spread across time zones and meeting a high standard of responsibilities (explained in this separate RFC Forum Post).
• The setup of the emergency multi-sig is a safety precaution, and must therefore prioritise efficiency over complete decentralisation. As Gro DAO matures, removing some of (or adding to) the emergency multi-sig’s powers is something the DAO can choose to pursue.

Next Steps

This vote will run for 5 days on a simple majority basis.

If Vote 27 is passed, a proposal to elect the Emergency Multi-Sig Committee members will be set up (see this separate RFC Forum Post for further details), and the respective multi-sig wallet will be configured as described in this proposal.

If Vote 27 is not passed, the People Pod will carefully review the proposal and engage in a thorough dialogue with the community to incorporate any further feedback received.