alpha
Uncover the building blocks of Rocket Pool
TL;DR:
Rocket Pool is considering a transition to an on-chain pDAO model to decentralize governance, which has sparked community discussions on security, gas costs, and the clarity of the RPIP wording. While the move is seen as positive for future-proofing governance, concerns about potential risks and increased complexity are being addressed, with a final sentiment poll on RPIP-33 underway and community feedback leading to proposal revisions.
The discussion is centered on transitioning Rocket Pool to an on-chain pDAO model to decentralize the current pDAO governance system. The aim is to remove the team as an executive middleman, which could lead to increased gas costs and added complexity. The community is evaluating various aspects of the model, such as voting power calculations, gas costs, security features, and the clarity of the RPIP wording. A draft RPIP has been posted, and a formal vote is expected. The conversation also touches on the impact of RPL collateral on voting power and the idea of removing the maximum RPL collateral limit to simplify the process and align voting power with reward distribution.
The community's response is a mix of support and concerns. Wander supports the design but suggests additional security features. Darkmessage and Umeku are concerned about the clarity of the RPIP wording and the specifics of the proposal execution process. LongForWisdom points out the absence of a proper time-lock mechanism. Valdorff and Knoshua discuss proposal criteria improvements and the role of delegations. Epineph and Langers advocate for removing the maximum RPL collateral limit, with Langers emphasizing the benefits of the pDAO replacement, such as its future-proof nature and the optimistic proving scheme26. RPIP-33 has been moved to Review, and Langers has called for any last community feedback before finalization27. Valdorff noted a typo in the documentation and raised concerns about a weak guardrail on rpl.inflation.interval.rate
28. Kane clarified the security.proposal.execute.time
parameter and agreed to update the RPIP to remove ambiguity29. Langers confirmed that Kane has raised a PR to correct the typo and update RPIP-33, including replacing vote time parameters with two-phase ones and updating the technical information link30. Valdorff discusses the impact of setting a parameter to 1e15, which would allow a single step to result in a 51% change, suggesting that even 1e14 would allow for a significant 4% change per vote. They express that while they are comfortable with the parameter being set to 1e16, it should be subject to discussion and review, especially since it could be off by several orders of magnitude, which could lead to various issues if proposals are not properly reviewed31.
rpl.inflation.interval.rate
parameter suggest that incorrect settings could lead to significant governance issues31.security.proposal.execute.time
parameter30.rpl.inflation.interval.rate
parameter setting, as highlighted by Valdorff31.Posted 5 months ago
Last reply 2 days ago
Summary updated 2 days ago
Last updated 04/12 00:28