On-Chain pDAO Replacement

Some comments and questions regarding the draft:

  1. I suppose the lower (10%) bound should now be removed in the voting power function based on the RPIP-4 clarification vote we just had.
    E.g. have R_{n} = min(S_{n}, M_{n})

  2. If the sum of voting power of votes exceeds the quorum threshold […], the proposal SHALL be executed and its changes affected.

This part is a bit unclear to me. It could be interpreted as if the smart contract executes the proposal as soon as the quorum is reached. Or the proposer could execute it as soon as the threshold is reached. Is this the intention?

There are a couple of related parameters in the Parameter Table (proposal.vote.time and proposal.execute.time), but they are not mentioned in the Specification itself. I think these parameters should be clarified in the spec as to how they are used in the voting and execution of the proposals.

  1. Each node operator who has a non-zero voting power MAY vote […]

Non-zero voting power at the time of the vote or the block the proposal was submitted for? Based on the text below (Snapshotting and Rationale) it can be inferred it’s the latter, and the explanation in rocketpool-research confirms this. But maybe we should clarify the wording in this paragraph as well? (or maybe it’s completely clear to everyone idk)

EDIT: Is it even possible to have a node with zero voting power now, anyway?

  1. Any node with a non-zero voting power MAY raise a proposal at any time provided they have waited longer than the proposal cooldown period since their last proposal.

What’s the cooldown period specifically? Should that be a parameter in rocketDAOProtocolSettingsProposals?

  1. For some reason the rpips.rocketpool.net site does not render the % sign in the voting power function formula (tried different browsers too), while on github the percentage sign is shown. We should probably either fix the issue on the website, or we could write the formula as “× 1.5” instead of “× 150%”.

  2. It would seem there is no way to overrule a delegate’s vote under the proposed system. Are we pushing this out of the scope of the initial implementation?

Any node with a non-zero voting power MAY raise a proposal at any time provided they have waited longer than the proposal cooldown period since their last proposal. RPL equal to the proposal bond SHALL be locked for the duration of the proposal process. In order to be eligible to propose, node MUST have an effective RPL stake (minus any already locked RPL) greater than the proposal bond. Locked RPL SHALL act the same way as regular staked RPL for the purposes of rewards, voting and collateral requirements. Locked RPL SHALL NOT be counted towards thresholds for withdrawing RPL.

What is the reasoning for the bolded part, specifically the reference to effective RPL stake (I’m assuming this means at least 10% and less than 150% here). If a node operator is below the 10% treshold, but has enough RPL staked to cover the proposal bond, why are they excluded? If a NO doesn’t have enough effective RPL staked, but does have enough RPL staked, why can’t they propose?

Same question for requiring effective RPL stake for challengers.

1 Like

I tend to agree with knoshua here that this requirement isn’t necessary. I do think “have nonzero vote power” or “have an active minipool” would be reasonable to propose (but shouldn’t be needed to challenge, as we want the lowest possible barrier to entry to participants on that imo).

1 Like

What is the purpose of submitting delegations as part of the merkle tree for calculating total vote power? As far as I can tell, we only care about total vote power to calculate quorum and delegations do not change the sum. Wouldn’t it be simpler to just calculate sum of vote power regardless of delegations?

I had a go at fixing this on the portal, I couldn’t find a reason (in the half-hour I spent) for it requiring single slash escape rather than double slash escape (github requires the opposite). I would agree that it might be better to just use 1.5.

I did manage to fix the inline latex not working though. [PR]

Edit: I couldn’t let the stupid percent thing go, so I found a hacky fix that makes it work. Don’t love it, not sure if it’ll get merged in. [PR] if anyone is interested.


That’s correct. The design/RPIP was written before the RPIP-4 vote. We will update.

This area has changed a little due to some feedback already given. There will now be two voting periods: one for delegates, one for voters (so they can override their delegate). Once the proposal has gone through both voting periods, the result will be known: success, defeated, etc. If it is successful then the proposal can be executed by either the proposer or a any good samaritan who wants to pay the gas.

We will update the RPIP / design based on this information. We have a timeline and state diagram to help explain.

Yes it will be the block included in the proposal submission - the one that the voting power has been calculated for. The design was written before the RPIP-4 vote - we will update. A node can have zero voting power if they have no minipools.

Great question - the cooldown was originally a security feature but after review we determined it is not necessary, so we have removed it. I believe it was for spam protection but the bond and veto process solves this issue. We will update the RPIP to reflect.

Looks like @LongForWisdom has tenaciously updated.

Based on feedback, we have included a way to overrule a delegate’s vote in the scope.

1 Like

Good pickup. We agree it should not be effective RPL stake here.

To be honest, there isn’t a technical reason why proposers and challengers should be staking. We had the idea that those engaged in these governance activities should be active stakers but it does make it simpler from a code and operational aspect to not have that constraint

The only issue I see, is that it makes it marginally easier to launch a potential attack because they just have to stake RPL, rather than setup a minipool, but we do not rely on the minipool for security, we use the RPL bond so it makes little difference.

We will update to use RPL stake rather than effective RPL stake.

We calculate the total vote power off-chain because we cannot sum the vote power on-chain. We have the same issue for delegates - we need to sum their delegated vote power. So we do it off-chain and include it in the tree. The delegates then submit a proof to their vote power when they vote.

There is a pretty big difference between summing over all nodes and summing over nodes with the same delegate. I think using the tree over the entire set for the delegate situation is unnecessary and inefficient. If it works for you guys though, not going to waste my breath here.

Final sentiment poll for RPIP-33 pDAO voting

  • 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
0 voters

Does the design in the RPIP still reflect what’s implemented? Specifically wondering about the merkle tree.

We removed implementation specific details from the RPIP per guidance from @Valdorff so the RPIP only describes the desired outcomes and these outcomes match the current implementation. The research doc referred to in the RPIP is a little bit out of date though as we ran into some limitations and made some improvements along the way.

This new document is much more detailed and correctly describes the implementation as it stands today: https://github.com/rocket-pool/rocketpool-research/blob/houston/Protocol%20DAO/pdao-prop-challenge-spec.md

I will submit a PR to update the RPIP to refer to this document instead.


So I hope that someone with more technical know-how can help me make (or dispute) this point, but here goes:

The linked explanation of on-chain voting suggests that because there is a max and min RPL collateral that non-linearly affect voting power, a significantly more complex scheme must be used to account for RPL(price). We have already voted to remove the minimum. I think we should seriously consider removing the maximum before taking this RPIP to completion, and thus completely eliminate RPL price from the calculation of vote power.

  1. the maximum increases complexity which (i think) makes trade offs for worse UX (ie the separate delegate/voter periods, increased complexity and collateral to propose a vote, need for checkers for fraud proofs, etc).
  1. The maximum, after the passage of RPIP 30, actually moves voting power farther away from reward distribution, rather than keeping it closer.

  2. The sqrt voting scheme significantly reduces (I would say eliminates) the gamability or attack surfaces of governance if unlimited RPL could be staked for voting. In fact, the addition of vote power over the current maximum acts as increases the vote power denominator and reduces the relative vote power of one major attack vector: sybil nodes. This calculus may have to be evaluated with LEB4, but it seems somewhat unlikely we will allow single LEB4 nodes to exist.

  3. Making vote power based on a simple function (sqrt staked RPL) is easy to understand/explain to NOs.

  4. (this is more my personal opinion) I think that people who stake RPL over the maximum are expressing a confidence in the protocol and and alignment with our goals, even at the expense of higher yields. I think that should be acknowledged formally by designating more vote power, even if sqrt voting makes the marginal gain small.

To me, this change does not seem controversial. As far as I can tell, the major downside is that it is not the status quo and would require a DAO vote for approval. The potential for single LEB1 or LEB2 nodes with unlimited RPL stake would be a concern, but it seems unlikely we would allow very-low ETH bonded minipools without some sort of bonding curve.

1 Like

Sorry for not replying to this earlier.

This is correct.

I agree that back when we posted the research article, if we thought that was even an option it would have been preferable.

That said, the pDAO replacement has the major benefit of being future-proof. We do not know how the voting system will evolve. The optimistic proving scheme approach provides an incredible amount of flexibility.

1 Like

This RPIP has been moved to Review in preparation for finalisation.

Please provide any last community feedback here.


“If security.members.quorum percent of members vote in favour of the proposal, it is immediately affected.”
Should be “effected”.

– And some minor ones —

It doesn’t look like this PR On-Chain pDAO Replacement - #24 by kane happened?
This is a a link to additional info, so doesn’t materially change the spec.

The guardrail on rpl.inflation.interval.rate is weak. An increase of 1e16 takes us from 5% per year to 3900% per year. This is fine for avoiding “infinite” inflation, but is quite extreme. Just checking intent.

For security.proposal.execute.time, it says “How long a proposal can be executed after its voting period is finished”. Does that also consider reaching quorum as the period being finished? My attempt at a read is: no - it’s simply the time when the vote starts + security.proposal.vote.time +security.proposal.execute.time. I think either is fine, but unambiguous would be nice.

1 Like

wrt security.proposal.execute.time, it’s the former. It’s this way as it reuses the same proposal system as the oDAO which is done this way. If there’s no strong feelings either way, I will update the RPIP to remove the ambiguity and define it the way it’s currently implemented.

1 Like

@kane has raised that PR now including “affected” - thank you for the reminder.

As you said, the intention was to avoid an infinite inflation (via fat fingers or exploit). We were conscious of not being too restrictive and being overly opinionated. However, i agree that the current value is too lax. What number would be better?

1e15 would allow an instantaneous step to 51%. I think I’m reading this as how much a single step can do, so that seems plenty generous (and not contentious). Even 1e14 would allow about 4% per vote – that seems about right to me, which probably means it would deserve discussion before getting set that small.

I’m ok with it being 1e16. I think it already serves an important purpose of being off by likely 3 or 6 orders of magnitude, and there will be review on proposals (else we have all sorts of issues).

1 Like

Voting in favor.

On-chain governance is an important step towards ossification.