GRFC: Approve configuration of emergency multi-sig and define its powers (Meta-governance update, sub-proposal 2)

[raambo]

Title

[GRFC] Sub-Proposal 2: Approve the configuration of the emergency multi-sig and ratify its scope

Author(s) & acknowledgements:

Raambo, Graadient, Jaypow, Bernard, SHAKOTN, KD

Related discussion(s)

• What is governed by who?
• Vote 26
• Forum post about Gro DAO’s new structure in October 2022
• Study of Emergency Multi-Sigs

Proposed Changes

A) ratify the configuration of the emergency multi-sig:

• To 4-of-7 (m-of-n), with 3 non-pod contributors and 1 representative from each pod

B) ratify the scope of the emergency multi-sig by assigning it as a ‘keeper’ for the following smart contract functions:

• 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

Voting Options

For these jointly proposed changes, DAO members can either vote:

• FOR: approve the sub-proposal
• AGAINST: do not approve the sub-proposal
• ABSTAIN: no opinion on this sub-proposal

Summary

While establishing on-chain governance, the DAO still needs an emergency multi-sig. This is a type of smart contract wallet controlled by approved DAO members (the Emergency Multi-Sig Committee). This committee can quickly perform certain approved actions to safeguard the DAO’s interests. The selection of these committee members will take place in sub-proposal 3.

Rationale

A) Ratify the configuration of the emergency multi-sig
To enable quick transaction execution, the emergency multi-sig should have a lower percentage quorum, represented by ‘m’ (the number of required signatures to execute a transaction) divided by ‘n’ (pool of signers); and a higher value of ‘m’ and ‘n’; when compared to the DAO’s other operational multi-sigs.

It is proposed that the emergency multi-sig is configured to a 4-of-7 (m-of-n), with 3 non-pod contributors and 1 representative from each pod. This is in line with similar emergency multi-sigs within other DAOs. Here are some considerations when configuring the m-of-n parameters:

• A larger ‘n’ (pool of signers) and including non-pod contributors can make the system more decentralized, reduce reliance on certain key people, and provide faster response times (aiming for 24/7 coverage).
• A larger ‘m’ (more required signatures) reduces the risk of governance attacks or inside collusion.
• A lower percentage quorum can help speed up response times, aiming for actions within 1 hour and 24/7 coverage.

Because of the critical nature of the emergency multi-sig, those applying for the committee must illustrate their qualifications and availability, and agree to the specific outlined responsibilities. If a selected committee member is not performing as expected; 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.

B) Emergency Multi-Sig Scope
As decided in Vote 26 and as further detailed here, the emergency multi-sig will be given limited, approved tasks for emergencies over time, such as cancelling on-chain governance (in case of governance attacks if on-chain governance is approved by the DAO) and conducting emergency protocol functions (such as withdrawing from failing protocol strategies in case of emergency or automation failures).

At the smart contract level, these aforementioned actions translate to the emergency multi-sig being assigned as a ‘keeper’ for the functions illustrated in the table below; while contracts such as the OpenZeppelin Governor (if on-chain governance is approved by the DAO), Timelock, and existing DAO multi-sig (which will gradually hand over ownership of smart contract functions over time) would be responsible for the rest. The ‘keeper’ can be thought of as a low-level admin role that has limited smart contract functionality, as assigned by a high-level admin role (the ‘owner’).

*These are the functions for which the emergency multi-sig should be initially assigned as the ‘keeper’. Over time, emergency multi-sig could be given ‘keeper’ status for more functions, (if and) when DAO progresses to on-chain governance. See full Ownership of Smart Contract Functions and Roles table for further details.

Edits

Based on discussion below, the proposed emergency multi-sig configuration was changed from a 4-of-8 to a 4-of-7 (m-of-n).

Submission date and next steps

• Date of Submission: 2023-06-13T00:00:00Z
• Move proposal to Snapshot if RFC feedback is implemented and there is sufficient support: 2023-06-19T00:00:00Z (at the earliest)

Signalling Vote

Please indicate below whether you are FOR, AGAINST; or have no opinion (ABSTAIN); on this sub-proposal.

• FOR: approve the sub-proposal
• AGAINST: do not approve the sub-proposal
• ABSTAIN: no opinion on this proposal

This RFC will be open for comments over at least the next [6 days]. If no substantial changes are required, it will then be open for voting for another [5 days].

[Bernard]

Great stuff! On the configuration, just to challenge.
Why don’t we make it 4/7 with 3 non-pod contributors? Then we’d solve the risk of non-pod members being able to execute tx fully on their own + would be aligned with the timezone set-up. Would be curious to hear other peoples views on this.

[infinitehomie.eth]

It’s risky to have a less than majority type situation for multi sig. you run the risk of a split vote if yon have a equal number of signers. As well, I didn’t know you could potentially do something even for multi sig signers?

I’d vote for 4/7 also

[infinitehomie.eth]

I would venture it to beneficial to have an option in the poll that states

“I have questions before I can vote/state opinion”.

As you are asking for feedback.

1. How are you deciding on pod members for the multi sig?

2. How are you going to decide on non pod members for the multi sig?

3. How is the emergency multi sig committee chosen?

4. You said that the members can be removed if they are not performing, what are the considerations of “non performance”?

That’s what i have, for now.

[raambo]

Thanks for your comments @Bernard and @infinitehomie.eth.

I do see your points that having a majority quorum (m/n) would prevent any potential disputes and reduce the chances of any potential collusionRegarding the multi-sig config.

The only trade-off with reducing the pool of signers (n) is a potentially slower response time.

Would love to hear others’ opinions on the matter, and will happily change the proposed quorum to 4/7 if the general sentiment is to do so

[raambo]

We have drafted a parallel proposal for DAO members to apply for the committee (we wanted to give people some time to digest this proposal before posted the next one). Both pod and non-pod applications will need to be elected in by the DAO.

Here is the proposed list of criteria for committee members (deviation from this criteria would be considered non-performance):

1. Aligned with the long-term interests of Gro DAO (by having, for example, over [40,000+ vesting GRO tokens] or have continuously contributed to the DAO for over 1 year)
2. Knowledgeable about Gro Protocol and its smart contracts
3. Up-to-date with the latest news in DeFi
4. Have good OpSec practices (e.g. having a hardware wallet)
5. Committed to learning the expected behaviors of this role and how multi-sig transactions work (ideally already having experience participating in a multi-sig)
6. Available to respond within 24 hours, except in rare circumstances
7. Willing to attend war room calls and signer meetings
8. Prepared to alert other signers in advance about periods of unavailability (e.g., holidays) and/or changing time zones
9. Possessing the self-awareness to step down from the position if unable to perform duties to a suitable standard
10. Able to have face-to-face video meetings with other signers and demonstrate public ownership of your signer address in the application process (see template below).

Signers who are inactive (i.e. if they do not sign transactions on multiple occasions nor respond to alerts or messages on Discord/Telegram/Email within 24h on multiple occasions) or are unable to meet the minimum requirements can be voted out by the emergency multi-sig committee or have their proposed termination determined by a DAO Snapshot vote, with a by-election on Snapshot conducted thereafter to establish a new signer.

[raambo]

would also love to hear any initial feedback on these criteria

[jaypow]

Following on the 4/7 vs. 4/8 discussion and the topic of compensation, I would encourage anyone interested to read the Study of Emergency Multi-Sigs that the People Pod put together while researching this topic. There are some links to similar discussions that occurred within other DAOs at the time. In particular, this post by an mStable DAO contributor has some relevant analysis of 4/6 vs. 4/7 vs. 5/8 configurations. 4/8 configurations are less common, but not unheard of (I believe Axelar and Olympus have or had such multi-sigs).

My understanding is that the impetus behind the 4/8 configuration was to have equal representation of non-pod to pod contributors, but I understand the argument for 4/7 as well. Though collusion of non-pod members is unlikely, it is a non-zero chance. Gro DAO needs to decide what is best specifically for the “emergency” nature of this multi-sig.

@infinitehomie.eth - From a functional perspective, I don’t think a split vote is a concern due to the way this multi-sig would operate (anyone is welcome to correct me if I am wrong). It doesn’t tally up yes/no votes from all signers before determining an outcome (unless the multisig is configured to be n-of-n), all it requires is a minimum number of m-of-n signatures to authorize a transaction. If m is not reached, the transaction is not completed. So, in the case of a 4-of-8 multisig, if 4 signers authorize a transaction, then it can be executed even if the other 4 signers decide not to authorize.

If I had to create an oversimplified summary of the benefits and tradeoffs of three similar configurations:

4/7 (3 non-pod + 4 pod members)

• Benefits: No chance for non-pod collusion (+ Bernard says it “would be aligned with the timezone set-up, though I wasn’t sure what he meant - could you clarify this point @Bernard?).
• Tradeoffs: Potentially slower response time due to less signers.

4/8 (4 non-pod, 4 pod)

• Benefits: 8 signers means a potentially faster response time.
• Tradeoffs: Chance of collusion from non-pod signers, though low.

5/8 (4 non-pod, 4 pod)

• Benefits: More secure & requires at least one confirmation from a pod member.
• Tradeoffs: Potentially slower response time due to higher threshold (5)

I decided not to include representation from non-pod members as a benefit or a tradeoff, as this could be argued both ways. Same goes for the small amount of extra compensation needed for 8 signers compared to 7.

Fundamentally, the tension I see is between efficiency, security, and non-pod representation.

I tend to agree with the point made by Jeshli in his mStable forum analysis post: “Ultimately it boils down to the quality of the signers and whether we have 8 quality, engaged, and responsive signers…there are simple scenarios where you only have 7 quality candidates, then a 4/7 is better than 5/8.”

Conclusion: I view optimization of quality signers as a higher priority than the tradeoffs of 4/7 vs. 4/8, which I am neutral on. Therefore, I am equally okay with what others decide about 4/7 or 4/8.

[infinitehomie.eth]

@jaypow

@infinitehomie.eth - From a functional perspective, I don’t think a split vote is a concern due to the way this multi-sig would operate (anyone is welcome to correct me if I am wrong). It doesn’t tally up yes/no votes from all signers before determining an outcome (unless the multisig is configured to be n-of-n), all it requires is a minimum number of m-of-n signatures to authorize a transaction. If m is not reached, the transaction is not completed. So, in the case of a 4-of-8 multisig, if 4 signers authorize a transaction, then it can be executed even if the other 4 signers decide not to authorize.

So in my days as a multisig signer, I’ve personally seen splits with 4/8. It doesnt accurately represent a majority agreement. If we are looking to properly work with a majority of agreements on pretty major decisions, I would reflect on a majority take with multi sigs.

This is why people tend to just go with over 60 percent agreement

There are also tools to help wake signers up and make sure they sign.

When it all comes down to it, 4/8 vs 4/7 vs 5/8 is going to just be a matter of trying it out. Make it work for transparency sake. However.

[raambo]

Thank you for your comments @infinitehomie.eth and @jaypow! I understand both your points, despite a 4-of-8 being able to execute a transaction, I suppose it does make it possible for the other 4 signers to oppose the proposed action, therefore leading to potential committee dispute.

As we are all either prefer or are indifferent to 4-of-7, I will edit the proposal to suggest this configuration instead.

This change however, would also re-emphasise the importance of selecting high-quality members for the emergency multi-sig committee.

[raambo]

GRFC: Call for applications - Emergency multi-sig signers election (Meta-governance update, sub-proposal 3) see the RFC for signer applications here