We have had conversations recently with the community about the pDAO guardian. Thank you particularly to @Valdorff , @knoshua, and @Wander for championing it.
The pDAO is currently controlled by the pDAO guardian. The pDAO guardian is very powerful as it controls settings that could damage the protocol, if used unwisely or maliciously. The team have retained control of the pDAO guardian but it is time to devolve that power.
The ideal situation would be a mature, robust, and Sybil-resistant pDAO on-chain governance structure with a revised set of abilities and scope. The current phase 0 governance structure is our sandpit for, finding out what works, so that the ideal solution can be developed. This is going to take time though.
For now, we intend to make a multisig with core team members, selected oDAO members, and a community representative. The community member can serve as a liaison, which we acknowledge is limited community power.
It would be great if the community can help with the following:
selecting a community member for the seat mentioned
working a charter for the pDAO Governance Multisig (PGM) to follow, both in the described interim state and ideally moving forward - as started by @Valdorff here: pDAO guardian multisig charter
assessing how to limit guardian powers so that this can be incorporated into the roadmap
Perhaps instead of a community member, the selected oDAO members could include a Rocket Scientist to act as liaison.
That still doesnât solve how to select that member exactly, but it does avoid the need for a round of nominations + vote for what is essentially still a team / oDAO controlled interim solution.
For clarity of discussions, shall we use this topic for the interim solution, and Valdorffâs existing thread for the long-term desired solution?
Itâs not really clear to me how this indermediate state relates to the conversation started by Valdorff in September. We talked about letting the community vote on multisig members. Can we move forward with that?
In several posts, as well as the poll in Valdorffâs thread (pDAO guardian multisig charter - #17 by Valdorff) people expressed hesitation with the proposed âcommunity vote, no reserved team / oDAO seatsâ pDAO multisig, even though the poll majority was in favor of that variant.
My interpretation of @langersâ post above, please correct me if Iâm wrong, is that the team wishes to move the pDAO multisig to a team + oDAO controlled wallet in the short term (a further restricted version of the 3rd poll option), while being open to different, more community-inclusive governance (like the 1st poll option) in the longer term, once we further redesign/limit pDAO guardian powers.
My personal opinion is that this is a good, stepwise approach to enhance pDAO guardian security with a multisig in the short term, while still having a plan to decentralize the guardian later on, once we minimize protocol risks involved.
Perhaps we should consider bringing this choice to snapshot, so the original âno-limit community multisig voteâ vs. the âphased team planâ described above? In either case bundled with an interim pDAO charter. Unless the team is unwilling to go with the first option at this time anyway, in which case a vote would be moot.
We have to do a fair amount of testing on Goerli. Atlas is keeping us busy in the short term but once we have gotten the first audit out the way we will be able to proceed with the testing and then mainnet migration. My estimate would be mid Jan.
That is up to the community. I think getting nominations and a vote would be appropriate.
This is exactly it. The pDAO powers need to be redesigned/limited for us to move to a more community-inclusive governance model. Also, even limited, we would like to explore alternatives to a multisig to facilitate permissionless governance. @knoshua
So is the thinking that the community would elect people to the multisig that are not trustworthy enough and thus we need to limit pDAO guardian powers first? Itâs not like the team is vetoing a concrete selection here, they are vetoing the idea that the community is able to make a sensible choice given the security risks.
I donât think thatâs the case and I donât think the team is more qualified to make this selection. I think it would go a long way towards legitimizing governance if we focused on educating the community about the guardian role and making the case for why this multisig should consist of high reputation individuals instead.
@knoshua The problem, in my view, is more with the nature of the pDAO guardian powers itself. As it stands, a captive pDAO guardian could brick the protocol with a single transaction. No one should have that power really, it merely existing already is an existential risk to Rocket Pool. This is fundamentally different to for example a captive GMC or IMC, where the possible scope is a limited amount of financial damage.
So with these destructive powers still existing, and the crypto landscape being what it is, Iâm putting on my most adversarial thinking hat possible. We have an excellent community, but I think even âhigh reputation individualsâ donât cut it here:
Possibility of âlong conâ attacks where one more more community members work to gain trust and attack once the opportunity arises.
Possibility of sybil attacks where multiple community members share an identity (or are under the influence of a single identity)
Possibility of initially honest community members being bribed / influenced by an attacker seeking to destroy the protocol.
The team and oDAO members have a large financial and reputational (also representing their organisation) vested interest in remaining honest, which is a more effective mitigation against these attacks than high reputation individuals offer.
So yes, Iâm saying I donât see a community-controlled pDAO multisig as appropriate governance at this stage. We donât need to go from 0 to 100 in decentralizing RPâs governance. I do see a team/oDAO multisig as an improvement over the status quo, as it mitigates the single-point-of-failure risk.
Itâs a short term improvement while we work on redesigning the pDAO powers for the long term. Maybe we can even find a better alternative than a multisig like langers said, but if not, at least limit the harm that can be done through the pDAO guardian.
That being said, I donât think having a single community member on a team/oDAO controlled multisig is of much value here (echoing @Uisceâs comment.) While I appreciate it as a sign of good will / intent from the team, weâd have the overhead of nominations and a community vote for near to no actual influence. In a sense, doing it that way feels more like governance theater than a legitimate process. Iâd actually prefer just a team/oDAO multisig as a clear-cut interim solution.
@Pieter you seem to think about this as a choice between the community electing community members or the team sharing the power with some odao members (and maybe one community member). But thatâs not what we are actually talking about. The community would be able to choose team members or odao members as part of the multisig. A community elected multisig can be just as secure as the teamâs proposal because the community can elect the same entities.
Vetoing this process before it even starts is very different than vetoing a concrete selection of members. You can not argue in terms of security in the former case, unless you are convinced that the community is incompetent and unable to make a sensible selection.
I think this is besides the point for this discussion, but just to be clear, what would that transaction be and how would it brick the protocol? I donât see it.
Unless you limit the acceptable bounds of the vote in advance, you canât say the security will be the same, just because the selected entities can be the same. You could also end up with a multisig consisting of a community member majority. You donât need to assume incompetence for that. It could just happen unintendedly because of the way the votes fall. Also, the community cannot know in advance whether elected community members will go rogue in the future. So Iâd say that, given the risk profile of the pDAO guardian, there just isnât enough information to make an adequate choice that allows for the outcome of a community majority guardian.
Do you agree that a pDAO multisig with a community majority should be avoided at this point? In any case, I donât really see the point of doing an unbounded vote where such an outcome is a possibility, as the team would still veto it after the fact.
Iâd be totally fine with for example a bounded vote where the community can vote for specific team members (or x team slots), specific oDAO members and a single (or maybe a minority few) community members. This wasnât the leading poll option in Valdorffâs thread, though.
I meant for example setting oDAO consensus quorum to an impossible value, disabling deposits altogether, setting the fee for new nodes to 100%, etc.
Depending on how you define community majority, I agree. The point is to show that the community is capable of making smart choices. Itâs to show that it is not necessary for the team to patronize the community. Itâs to show the community that it has a role to play in the protocol. Of course if you think that possibility is a foregone conclusion, then you wonât see the point. I expect the community to select a sensible multisig and I am wondering what the point is of not letting it play out and setting a precedent of vetoing here.
Not sure what you mean by âodao consensus quorumâ. The pdao only controls the threshold for price updates. The threshold for proposals like contract upgrades is controlled by the odao itself.
This means that basically anything a compromised guardian does is only temporary and can be undone by the odao through contract upgrades. Specifically:
the guardian could stop reth and rpl price from updating temporarily
the guardian could disable deposits temporarily
the guardian could set the fee for new nodes to 100% temporarily
I donât consider any of these things bricking the protocol.
The only thing the guardian could do with permanent impact is setting the max penalty rate.
The pDAO could still steal the reserve fund, which would hurt but also be overcomeable. Arenât there still other attack vectors with long term damage, like changing RPL inflation to a huge value just before a new period?
These are worthy goals, and I definitely donât think any specific outcome is a foregone conclusion. Still, the context here is an intermediate, temporary step to improve security of the pDAO guardian so I wonder if this is the right place to showcase such community ability. Being not as existential a risk as I had thought, Iâm more inclined to agree though.
Maybe the team could weigh in with the specific risks vectors they see with an open vote pDAO guardian, @langers ?
Yep - I think I misread it and @knoshua is right. There are separate quorums for proposals and for oracle duties, with a proposal required to change the former. Iâm sorry for this (highly relevant) error.
That does dramatically change the risks of a rogue guardian imo, and keeps it to a timeboxed period of damage. It would still suck, donât get me wrong, but maybe not instant death.
Set the deposit fee to 100% so that the protocol steals rETH deposits
Set RPL inflation to very high number
Set a new reward claimer contract or set it all to the pDAO and steal rewards for the period
Steal the RPL reserve fund
Disable balance submission so that rETH does not increase in value
Disable reward submission
Yes, the ODAO can deploy a change to override the effect but the protocol would be exposed for at least 7 days, causing massive financial and market damage to the protocol, which it may not be able to recover from.
I do agree with the sentiment here and the community are progressively getting more agency and power. I agree that it is highly likely that the community would select a sensible multisig but we take our social contract very seriously. If we cannot fully commit to handing power to the community then there is no point in pretending that we are. In this instance, the stakes are too high and we cannot fully commit to having an open vote until the guardian has been limited and solutions explored.
If this seems like the core team is patronising the community then I apologise, that is certainly not the intention. We respect the community deeply and have been working very hard to devolve power responsibly.
Thank you for the explanation. I disagree with putting the veto on the vote instead of a dangerous result, but letâs move on.
Rpip-4 calls for a veto explanation document when a vote is vetoed. I think weâve gotten enough of an explanation in this thread now, just something to keep in mind for the future.
I agree with uisce and pieter, in that voting on a single member of the multisig seems unnecessary.
What are you looking for here? It seems like the team has already identified the attack scenarios. There are already some pdao settings that come with guardrails that limit them to a certain range. So for example we would want to limit inflation to a somewhat sane maximum value. Besides that, we could explore putting a time lock on some settings, but that also limits the ability to of the guardian to react to bugs and exploits. Do we want guardian to be able to stop deposits if someone finds a way to break things or are we more worried about malicious guardian temporarily disrupting deposits?