We’ve talked about the need for a pDAO guardian multisig. I’ll be writing up an RPIP for it soon, and wanted to get some thoughts on “Guiding Principles” (similar to the section the IMC has).
- The primary role of the pDAO guardian multisig (PGM) SHALL be to safeguard the long-term integrity of the protocol. This includes:
- The PGM membership SHALL routinely check that all members are able to sign and responsive; if this is not the case, they SHALL publicly say so and ask the pDAO for a new membership vote
- In votes with vote manipulation, malicious action, or proposals that would result in clear damage to the Rocket Pool project, if the results of a vote would need PGM action to execute, the PGM SHALL use its veto power per RPIP-4. The PGM MUST NOT use its veto power in other situations.
- In case of a critical exploit, the PGM SHALL take immediate action to lock the relevant portions of the protocol (eg, disable user deposits). The PGM MUST NOT unilaterally change a setting in any case other than a critical exploit. The PGM SHALL immediately write a report on the exploit, the action taken, and a recommended path for the pDAO to vote on.
- The secondary role of the PGM SHALL be to faithfully execute the will of the pDAO as shown via snapshot votes. This explicitly includes:
- Votes that limit or remove pDAO guardianship powers
- Votes that change PGM membership
- Votes that PGM members disagree with, or even have security concerns about
- Votes that require repeated actions, such as desired budget disbursements
Some other thoughts…
I was thinking something like: 7/12, 8/13, 8/14. I thought about 55% or maybe “at least 50% + 1 member” as the minimum signers needed. This is a tough balance as the guardian both needs to be quite safe and be able to take quick action.
I think the procedure from https://github.com/rocket-pool/RPIPs/pull/23 will be a good one to follow. My first leaning is that it can be followed verbatim, making clear to the voting public how powerful the PGM is.
Are there any powers we’d like to strip or limit from the pDAO guardianship? One particular one that makes me feel a bit queasy is the ability to set the oDAO consensus needed. It’s kinda nice as a check on the oDAO if many keys are compromised at once; however, being able to set it above 100% is protocol breaking itself. I’d like to either remove that power or effectively limit it to a max of N-1 members and some sensible minimum too.