This is a proposal is to change the Balance (used in rETH exchange calculation) and RPL Price submissions to be time-based, rather than block-based.
The draft RPIP goes into the full rationale: RPIP-35
Here is a summary:
- Makes the prices and balance timings more consistent
- Aligns these timings with RPL reward intervals
- Supports node operators who want to top up before the end of a reward period
- Support moving to vote; I think this proposal is great!
- Support moving to vote; I think this is “good enough”
- Undecided; I have a specific question I’d like clarified in the comments below
- Undecided; other
- Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
- Oppose moving to vote; other
2 Likes
This shouldn’t go to vote. The team has implemented this change and decided to include it in the Houston upgrade before even writing the RPIP.
In reality there are two separate paths for protocol changes: RPIPs and team initiated. We shouldn’t muddy the water by voting on RPIPs that already made it though the second path.
There is a reason why RPIP-35 makes it into Houston while RPIP-30 doesn’t make it, despite being more impactful, having loads more community support, being of similar implementation difficulty, and being written multiple months earlier. It’s important that pDAO is clear about this to set realistic expectations for RPIP authors.
4 Likes
I disagree with @knoshua’s conclusion, but the sentiment absolutely resonates with me.
Given where we are now, I would prefer that this have an RPIP and get voted on by the pDAO. If it fails to get ratified by the pDAO, the feature should get removed from Houston.
I absolutely agree that it does feel like we currently have a 2-tier system. The component of RPIP-30 that needs a smart contract change has been largely unchanged since the initial draft merged September 3rd. If we’re proactively developing ahead of votes, that seems like it should have gotten attention. On the opposite end, the team have routinely talked about what the Houston upgrade is prior to vote; language matters and I really wish we were careful to have phrases reinforcing the pDAO as the decision maker such as “the team is hoping to include”, “pending ratification”, “if the pDAO accepts it” etc. One possible path that could help here is having high level votes (“let’s move the pDAO onchain”) and follow-up detailed votes that fully specify things.
For now, I’m chalking this up to “learning how to DAO effectively”, and hoping to see us get better over time.
5 Likes
Nothing wrong with having this as an RPIP. Just should be an informational one because that’s what it is.
I’m not sure the language you are suggesting would help anything. I think it’s pretty clear that the decision what goes into Houston was made by the team a while ago and there was no opportunity for pDAO to set different priorities. I don’t think this is only a communication issue, this is a process issue.
I’m all for learning and improving over time, but in my experience that begins with acknowledging what is wrong and calling a spade a spade. Treating the Houston RPIPs as regular RPIPs while we have zero acknowledgement that the 2-tier system exists feels like sweeping this under the rug.
3 Likes
The pDAO ratify everything that goes live. If they feel strongly that this or any RPIP should not go live we cannot release it and it would be removed.
I apologise if it feels like a 2-tier system. That is clearly not the intention. The team have been talking openly about these features for months. We didn’t expect to have push back on them.
From our perspective, RPIP-30 was not certain to be ratified - @Valdorff has done an excellent job of building consensus but we were not aware of how positive the sentiment was for the change. Clearly we need to pay more attention but even still we were not sure how the vote would go. Hence why we didn’t start development work on it. Also the audits for Houston had to be booked in and they are literally the monday after the vote is closed. We were already rushed to get feature complete we did not have time to include RPIP-30 as well. We will of course get RPIP-30 (and RPIP-28) into a release as early as we can.
I agree with both of you.
We try very hard to make sure our communication is mindful of the governance process but we haven’t always got it right. The process is evolving and feedback like this is extremely important. The team are dedicated to making this work, most of the friction is caused by assumptions and grey areas, which as the process improves will be resolved. It isn’t an easy process to get right. From our side, I will continue to work on a unified process with the community.
The most important thing is that we maintain this collaborative relationship. I see Rocket Pool as a whole. There are dynamics between the team and pDAO but I do believe we have made significant progress and will continue to do so.
3 Likes
I agree, but I think this might be the disconnect here. The implication is that you are sure how all four of the votes to ratify the team features will go.
Let me come at this a little differently – if the team said “we’ve already written the code for RPIP-30 and think it should go in Houston”, would you still have expected an uncertain vote? The certainty of the vote changes with team support itself.
This doesn’t match my perception. It’s certainly true for on-chain pDAO (which is the “headline” feature for Houston).
I don’t think I knew RPIP-31 and RPIP-32 were planned for Houston until they got posted as draft RPIPs in late September. I definitely didn’t know RPIP-35 was planned for Houston until that was posted about a week ago. I keep up well with discord and forum; there’s a possibility I missed it anyhow, or some of this was in Twitter Spaces or something. I should note, I have heard all of these features (or variations on them) get discussed informally much before that, but that’s also true for dozens of other features and is different than “targeted for inclusion”.
Worth being very explicit on that - cheers.
Strong agree. Our DAO is far from perfect, but I feel fairly positive about how we look vs the field in “current state plus trajectory”.
2 Likes
And what made you certain that the Houston RPIPs would? From my perspective, they are fine things to do, but there are other things that are more pressing. I haven’t had the opportunity to express that view and even at this point the only option that is given is to delay Houston RPIPs. So by inverting the process, you are influencing the outcome of votes pretty heavily.
6 Likes
Like many in the community, it took us a while to come around to RPIP-30. We have been lambasted for influencing votes before, so we are very careful with anything RPL related.
I acknowledge our influence but we do not want to be in a situation where we cannot author RPIPs because we open ourselves us to this sort of criticism. I accept that we need to start the RPIP process much sooner so that the RPIPs get enough community co-development and/or feedback.
I do believe that release planning is a current weakness or ambiguity in the process. Again starting the RPIP process earlier will help but any other feedback on that would be useful.
1 Like
Feedback taken onboard. We will start the RPIP process much earlier so that the community have plenty of time to co-develop and indicate a priority.
9 Likes
This RPIP has been moved to Review in preparation for finalisation.
Please provide any last community feedback here.
1 Like
I’m voting in favor.
Predictability in the time axis is an important attribute of oDAO duties- Not just for nodes that want to top up to minimum collateral before the end of an interval, but to make duties logic more consistent across the board.
The team has been, in my opinion, sufficiently informed of the reservations about process here, and I won’t let that stand in the way, this time.
1 Like
