Avoid oDAO vote edge case

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.

Community sentiment poll time :bar_chart:

  • I support this
  • I don’t support this
  • Undecided on the general concept
  • Waiting on a concrete RPIP

0 voters

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?

2 Likes

The team responded to 5.10:

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.

Draft RPIP - feedback welcome: RPIPs/RPIP-draft.md at feature/avoid_odao_edge_case ¡ Valdorff/RPIPs ¡ GitHub

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.

1 Like

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.

PR is in review status - last call for feedback before it gets finalized

Hi All,

@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

See discussion here for more: Discord

1 Like

Proposals do have a window where they can be voted on and expire after that. It’s currently set to 4 weeks.