Issue 5.10 in https://rocketpool.net/files/consensys-diligence-atlas-v1.2.pdf provides a potential for oDAO votes to pass without a proper consensus. While the timeline may have made fixing the issue untenable for Atlas, I believe this should be a priority for the next significant smart contract release.
Possible mitigations:
Track the source of each vote, so that if a member that already voted leaves during a vote, their voted can be subtracted
Record the number of oDAO members when a vote starts, do NOT decrement if an oDAO member leaves (but do increment if a new member joins)
Abandon ongoing votes if thereâs a change in oDAO membership (this has minor griefing potential)
The RPIP for this would have a copy of part of issue 5.10, would link to the full audit, and would say that we SHALL mitigate the issue in the next significant smart contract release.
Given that this seems to be a bug, Iâm not sure this needs a governance response or an RPIP proposal. It âjustâ needs to be fixed. Would there be any lack of legitimacy in fixing the issue without it going through governance? Is there concern that the team wonât prioritize fixing this?
We are aware of this limitation but the additional changes required to implement a fix outweigh the concern in our opinion
Compare with the response in 5.11:
We are aware of this limitation but making this change now with an existing deployment outweighs the concern in our opinion.
It seems like the latter is the team saying that itâs not worth making the change ânow with an existing deploymentâ, whereas the former seems to be a general outweigh. I am taking this at face value as the team stating that they do not believe this should be fixed. I disagree and think this is quite important.
To be honest, I believe the issue was raised in one of our first audits. We assessed and reassessed in this audit but felt that it would incur more risk to change than the benefit provided - it is an unlikely edge case with minimal impact.
We should have worded the response differently to make that clear.
This significantly decreases the cost of attack. In the current 19-member oDAO with 51% threshold, 7 members can take complete and permanent control. I donât think this is acceptable.
Fixing it seems like a good idea. Option two makes sense to me. Additionally I think proposals should have a window where they can be voted on and expire after that.
@knoshua brought a misunderstanding to light here, which I think should totally derail this effort. In particular, itâs only some votes that are impacted (network balances, network prices, mev penalties and scrubbing of minipools). I agree with @knoshuaâs assessment (and @kane has also confirmed now).
My current intention:
Abandon this vote effort, because it was based on a misunderstanding
Likely turn the RPIP into an Informational RPIP on this topic rather than an RPIP meant for voting on
If we do want to vote on the actual issue, it will be a new effort from scratch
