pDAO guardian multisig charter

Hi folks,

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).

Guiding principles

  • 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.

8 Likes

Looks good to me.

I think there are many ways to make guardian safer through contract changes, including limiting settings to reasonable ranges and adding time locks to changes. But I consider that a separate issue from moving guardian from a regular wallet to a multisig. The latter adds security independently and shouldn’t have to wait on contract changes, which we may or may not be able to fit into Atlas.

1 Like

I’d like to either remove that power or effectively limit it to a max of N-1 members and some sensible minimum too.

I think this power is important for the pDAO to keep. Ideally, the future of Rocketpool sees even more decentralization and an abatement of the power, influence, and trust held by the current core team. That said, defining obvious bounds for an important property like this seems reasonable.

In general, I’m very supportive but feel the specifics can be improved. Thank you Val and everyone else who’s contributed to the discussion on this so far! Here’s my thoughts on what’s been proposed so far.


As is, I would vote against the proposed RPIP-10 extension as a selection mechanism for the pDAO guardian due to security concerns with our current, very nascent government process.

Sybil-resistance is the only answer for fair governance since linear voting brings plutocracy, and even that’s preferable to the gameable vote we have now – which, it could be argued, is not even secure enough for accurate signaling. I say all of this as the author of RPIP-4, of course, so it’s not like I’m against the current process, but I do think we need to be realistic about it’s limitations.

All the legalese about veto powers and when it’s ok to use them will only protect the protocol from good actors, and I’m more worried about bad actors exploiting the process to gain control of the millions in the pDAO budget. I don’t think it’s worth gambling the entire protocol on the hope that we’ll be fine with anonymous multi-sig participants and the current voting process when there are easy, big wins for security upgrades if we’re just a little more patient.

As an example, I also support the pDAO contract changes referred to above (timelocks, parameter limitations, etc). Contract changes require audits, however, and audits take time. Studying governance risks and passing proposals which mitigate the risks with our current system (i.e. improved sybil resistance for voting) will also take time. Doing this right takes time, and rushing is very dangerous since a malicious pDAO guardian can easily and quickly destroy the protocol.

That said, the current situation with the dev team as the pDAO guardian is also risky, as noted by Sigma Prime in their audit for redstone. Therefore, while we develop the pDAO to be more resilient against governance attacks, I prefer to temporarily move the pDAO guardian to the oDAO (i.e. RPIP-14) to increase security while we work on pDAO contract security upgrades and design other mitigations to social attacks.


Re: multi-sig types, I have no preference for a specific size, but to help with this decision, maybe we can consider specific goals like “X-hour response time”.


Also, a suggestion for the future, regardless of how the pDAO guardian ends up, I think we should work towards separating the wallet that receives pDAO inflation from the wallet which can change protocol parameters. For the first, it should be possible to use a splitter contact for automating regular transfers to MCs, which would be safer vs manual transactions, and then the only responsibility for treasury management is the regular signing drills. For the second, we could even institute a completely different multi-sig with even more security precautions.

We should always remember that the ideal state of the protocol is the one where there is no need for governance and everything is automated, so let’s work towards that future whenever possible!

1 Like

The principles say that “proposals that would result in clear damage to the Rocket Pool project” should be vetoed, but also says that " * Votes that pDAO members disagree with, or even have security concerns about" shall be executed.

I would think that a security issue would result in clear damage to the Rocket Pool project? Is there a contradiction here? Or maybe I’m just overthinking this and the intent is to discouraging vetoes over minor security issues as opposed to major ones?

@knoshua
I agree - this can move forward regardless of powers. It’s just very front of mind and I think makes a good time to discuss.

@sam
Fair enough. If this was reduced to a “make it hard/easy” lever then it wouldn’t make me queasy like “make it impossible” does.

@Wander
The X hour response time is interesting. It could certainly get written as a recommend. I do like that it somewhat hits on the value of time zone diversity as well as having some way to “make the phone ring” in an emergency. 2 or 3 hours sounds like a good goal to me.

Re the multisig members: remember that the community can vote for what they deem safest or otherwise best. They could vote to make it the oDAO, or the current team plus a couple of doxxed oDAO members if they wish.

Moving the pDAO guardianship to the care of a pDAO selected group has been a key milestone for me for a while, and I’m not comfortable waiting on a dev release before acting on this.

Re splitter contract: it can certainly be done, and I agree it’s nicer. That said, this is low prio in my head b/c I don’t think there’s much of a difference in practice - transfers are very easy to review and the signatures should be easy to get in less than a day.

@raybsolomon
Yeah - the intent was to have “clear damage” and “critical exploit” be lines in the sand as opposed to security imperfections, tradeoffs that get discussed, etc.

2 Likes

I am supportive of this.

In regards to discussion of moving guardian to oDAO vs. a new pDAO multisig, I prefer Valdorff’s multisig proposal:

  • The signaling is clearer (keeping pDAO and oDAO as separate instances) which reduces some worries I would have about how “temporary” a direct oDAO transfer would be.
  • As Valdorff mentions, the pDAO multisig could be made up of oDAO members and personally, there are some I would like on there including, for example, members of the team, phiz, and beaconcha.in (butta) if they wish to serve. However, many oDAO members show little interaction and involvement with Rocket Pool and as such I worry that their votes would not be independent but more so following recommendations of other members. This more general pDAO multisig allows active, trusted community members to take those spots instead.
  • Finally, while I understand the worry about how our quadratic voting system is gameable, due to the freshness of governance, this appears to not be an issue at the current state and the lack of withdrawals and rETH bottlenecks limit the impact a bad actor can have in the immediate future. Thus, I believe now may be the safest time to hold this vote. Additionally, as it currently stands, the team still holds the ultimate veto of and pDAO multisig vote, so if it was manipulated to include harmful members, it can be stopped.

Per that last point, I think this is something important to go forward with quickly and I think the procedure outlined in the RPIP-10 revision is a good approach for it.

As for multisig size, I don’t have a strong preference, but lean towards starting a little smaller with 7/12 which will help with keeping some agility in these early days while still being significantly better than the current wallet-guardian.

2 Likes

Some questions on specifics of Guiding Principles:

  • What is referenced by “pDAO membership” is this referring to the PGM?
  • Similar questions for “Votes that pDAO members disagree with…”; I’m assuming “pDAO members” here refers to PGM members?

Since just the “pDAO” can be a nebulous refence (is it referring to committees, guardian, MCs?), if the intent is to refer to the PGM, I would swap the term to specify that. (“Votes that change PGM membership”, “Votes that PGM members disagree with”)

1 Like

Thanks - edited those two to say PGM for clarity.

We need to proceed very carefully here, precisely because of the power the pDAO guardian wields over the RP protocol. We cannot treat pDAO guardianship as just another ‘management committee’, for that reason. As is evident from the larger proposed multisig size and the need for safety vs. quickness of action.
My initial reaction was to be in support of this proposal, but after further consideration I think there are fundamental issues with this approach.

In my view there are two distinct roles for the PGM that should be separated:
a) management / disbursement of pDAO treasury
b) control over protocol settings

The treasury management role would ideally be automated / smart contract managed (as per the MC charter) but would realistically still likely require a multisig to confirm the MC addresses for disbursements (absent on-chain voting.)

As for the protocol settings, the main question that Dave’s discord post raised for me is: which of these powers do we need the pDAO to have anyway? (as in, the ability to change quickly without relying on the oDAO to vote them in via SC upgrade OR as a check on oDAO powers). And isn’t both on-chain voting or a large multisig PGM incompatible with quick action anyway?

Which brings me to my next point: PGM membership. Who would be qualified for it?
From a separation of powers point of view, you’d want no overlap with either oDAO (which includes the team…) or other management committees. But this is obviously problematic, in terms of the number of qualified trusted people available. These would be expected to shoulder a big responsibility towards the protocol + able to react fast to threats to the protocol, all without financial compensation. I don’t see this as realistically achievable.

In conclusion, I don’t think we should hastily move ahead with this just because the current security situation of the pDAO guardian wallet warrants action soon (with which I agree.)
I’d prefer a more limited interim solution for the pDAO guardian wallet such as a team multisig or a (variant of) the oDAO multisig. Meanwhile, we can take more time to further explore what pDAO settings powers are actually required (and limit these to useful ranges as discussed.) And as said, preferrably split the treasury / protocol settings roles to separate entities. I do still think it’s important to have the pDAO as a checks-and-balances system to the oDAO (and if possible as a replacement to the oDAO entirely at one point.)

3 Likes

I think you’re underestimating the damage the pDAO guardian can do. For example, it could set the inflation level for the pDAO to 100% and siphon all the funds away, which would completely eliminate all NO rewards. NOs would exit the system en masse and rush to sell RPL before the value goes to 0. This is a death spiral scenario.

EDIT: Actually this is incorrect since bootstrap mode is now disabled. A better description of potential attacks is described below.

1 Like

@Pieter

In my view there are two distinct roles for the PGM that should be separated
While I agree that ideally the treasury role is split out, I don’t think it’s a big issue.

Any group that I trust with the pDAO guardian’s current power, I certainly trust with disbursing funds. Actual disbursement is an easy transaction to check and execute, so this also doesn’t feel like too much of a burden.

which of these powers do we need the pDAO to have anyway

And with what limitations? I think this is a great discussion, but I believe we can select a trustworthy group even with the current powers. Eg, we could vote it to a team/oDAO multisig if that’s what we thought best (my personal preference includes members from both of those, but is not just them).

isn’t both on-chain voting or a large multisig PGM incompatible with quick action anyway?

Yes to the former, I don’t think so to the latter. We did 3 transactions in two days in the IMC as a 6 of 9 in our first active weekend. This was without any experience, without alerts (cell phone calls or equivalents that make something ring like telegram, whatsapp, etc), with one member unavailable to sign, and with one member initially traveling. I think the sizes I mentioned could respond quickly.

you’d want no overlap with either oDAO (which includes the team…) or other management committees

I only partly agree. Most obviously, if this is exactly the same list as the oDAO, then obviously they can’t be a check on oDAO power. On the other hand, imagine the PGM as a 7/12 with 2 IMC members on it. Where’s the additional attack vector? I’m not seeing one.

One possibility is to slighly modify selection a little, eg, rather than taking the top 12, we could take the top 12 ignoring:

  • oDAO members past the 4th selected
  • dev team members past the 4th selected
  • MC members past the 4th selected
    This could effectively make it so we have 0-4 from each of those categories and limit overlap. The downside is that it wouldn’t allow the community an opinion like “let’s just make it the oDAO”. While I think this type of limitation is interesting, I personally lean towards letting the community make this kind of choice freely.

I won’t speak for Daser, but for myself.

I am 100% aware that the pDAO guardian can, no questions asked, destroy the protocol. Because of that, I’d like it in what I consider the safest possible hands soon. That is what this charter is all about for me. I do not think the oDAO is a safer body to hold the pDAO guardian. If I did, I wouldn’t have bothered drafting this.

1 Like

I am very well aware of the damage the pDAO guardian can do and am very much in favor of restricting those elements (for example bounding parameter changes), but that’s for a different conversion.

I don’t see how the pDAO power is incongrent with my opinion; like Valdorff, I see this as a way of voting in a stronger group of members. As you’ll see in my opinion, I’m in favor of including team members and some oDAO members in this first round.

Most of the opposition to this seems to be assuming the worst case of members somehow being voted in, but I don’t think that’s something the community nor team would allow (since they still have veto power as of now).

This is the safest time to vote in a multisig as well, so perhaps we can add a condition that these members will serve until proper restrictions are placed on pDAO powers.

I’m general, I’m not fully against it being temporarily transferred to oDAO as it’s an improvement to now, but my preference is still strongly for voted PGM.

Ah it seems I should clarify further. There are two major concerns I have currently:

Attack Type 1: Bad actors are voted into power in a way which appears legitimate. Veto powers may not be used in this case as this could be highly subjective.

E.g. several anons with a short history of legitimate contributions are voted in, then it turns out these accounts are all controlled by the same person, who then initiates an attack.

This type of attack is less likely than the second type, but still worth considering.

Attack Type 2: Good actors who are voted into power become bad actors due to incentives.

E.g. The pDAO wallet is drained and split between members. This attack is hugely profitable no matter who is on the multi-sig, since the only limitation is RPL market liquidity and existing pDAO inflation.

This type of attack is actually quite easy to do. We are currently trusting the dev team not to do this.

The only way to prevent Attack Type 2 is to upgrade the pDAO contracts to include sensible limits like timelocks on transactions. These contracts are currently marked explicitly as placeholders. Even if you’re not technically savvy, I suggest everyone read the comments in these contracts: rocketpool/contracts/contract/dao/protocol at master · rocket-pool/rocketpool · GitHub

This is the directory where much of the code for the pDAO lives. Note that many of these contracts have notes at the top: “This is a placeholder for the network DAO to come” or “Placeholder contracts until DAO is implemented”


What is this based on? I think it may be the least safe time to vote in a multi-sig since we expect security to improve.

1 Like

Per the last point, this is based on the dev team holding ultimate veto power and the quadratic voting system not being very gameable right now (as in voting would be the most equitable it will be for a long time since sybil resistance is an extremely complicated problem). The solution to the voting has been to just go linear so that benevolent whales can help counter malicious ones; but that’s not very secure and more so something we just have to live with.

I’ll agree it’s not the safest in terms of what restrictions there are on pDAO powers, but safest as far as getting a trusted multisig on control. I think this lends itself to why we need to enhance the guardian ownership security now, as this proposal attempts to do.

This proposal doesn’t exclude team or oDAO members btw, for example, the breakdown of the multisig could be 4 dev team, 4 active oDAO members, 4 trusted community for example.


Attack 1 will not happen while dev team has veto power. It’s unlikely to happen anyways, especial with the quadratic system right now.

Like you said for attack 2, it’s profitable no matter who is on the multisig, be it team, oDAO, or voted multisig.

Hi all,

I’ve drafted an RPIP now, see https://github.com/Valdorff/RPIPs/blob/pgm-charter/RPIPs/RPIP-draft.md. I made it a 7 of 12, and added some other little details as I went.

I would also like some feedback, so please vote in the poll below:

  • I’m comfortable with this charter as written
  • I’d be comfortable if there were 4-6 slots reserved for the current dev team and/or oDAO
  • I’d be comfortable if there were 7+ slots reserved for the current dev team and/or oDAO (ie, these reserved slots could act without further help from the rest of the PGM)
  • I’m not ok with this charter for some other reason (please write something in the forum thread explaining)

0 voters

These were planned votes though. Unexpected incident mitigation will have a longer response time the larger the multisig becomes. But we do have to weigh this risk against the existing risk of a) complete loss of the pDAO guardian keys (bad, but mostly manageable I think) and b) pDAO guardian keys compromised by a malicious actor (catastrophic.) Both these risks decrease with multisig size. All in all I do think it’s worth it to sacrifice some potential reaction speed for security on this front.

When introducing community members (“anons”) to the multisig there’s also the risk of sybil or collusion attacks on governance. Having a number of ‘reserved seats’ each for team / oDAO / community looks like a good mitigation to me. So, for now I’d go with the variant where team + oDAO hold a majority of the multisig, with the intent to shift more towards community if and when pDAO guardian powers are further limited.

One last concern I have is that we should make it abundantly clear that the PGM, in whichever composition, is still considered bootstrap mode for the pDAO. There could be a danger it’s regarded as ‘good enough’, losing impetus on further research for limiting pDAO controls and designing the definitive pDAO structure as a whole.

1 Like

This is a good point. I’ll make sure to add words to this effect before this heads to snapshot.

1 Like

Supportive of a variant with a majority of slots reserved for team nominated signers (including but not limited to oDAO members) with language indicating this is not a permanent solution.

Votes that PGM members disagree with, or even have security concerns about

I follow the intent here but suggest this be rephrased to be a little softer, eg. "…disagree with, including non-critical security concerns.

3 Likes