Rocket Pool Governance

[coopahtroopa]

Summary

This post proposes the first steps towards Rocket Pool’s path to ‘minimal viable decentralization’, starting with governance weight, key parameters, and the Trusted Node DAO.

These topics are an extension to RPIP003, further detailing how the system may be upgraded and changed in the future through RPL governance.

Governance Weight

Governance weight in Rocket Pool is earned by:

• Node operators staking RPL against their validators.
• Reserve Pool liquidity providers staking their LP tokens.

Governance takes the form of a ‘Rocket Pool DAO’ defined by a contract that has ownership over (at genesis) a set number of key parameters (defined below).

Genesis governance will give different stakeholders voting power relative to their contribution to the network. This means:

• Governance weight is directly correlated to the amount of RPL staked in the system.
• Node operator weight is assigned relative to the amount of RPL staked across validators, including a max collateralization ratio of 150% worth of RPL for each 16 ETH deposit.
• Reserve Pool weight will be assigned relative to the amount of LP tokens staked in the protocol, with the Reserve Pool weight capped at 90% of the total RPL staked by node operators.
• The total governance weight of the Reserve Pool cannot outweigh the governance weight of node operators. See Reserve Pool post.

This design ensures that validators hold the majority of governance weight at any given time, so Rocket Pool governance cannot be captured by non-validators passively staking RPL.

Key Parameters

Node operators and RPL stakers will have the ability to vote on Rocket Pool protocol changes. These parameters will continue to be updated and expanded in the future based on the community’s sentiment.

At genesis, the primary governable parameters will include the allocation of RPL inflation, ownership of Rocket Pool DAO treasury and community/development incentives. This means governance will be able to adjust:

• Validator Commission Fee Parameters - The minimum and maximum parameters for validator commission fees to ensure Rocket Pool can react to economic factors in real time.
• RPL Staking Rewards - The parameters for Node Operator and passive RPL stakers voting weight and reward distribution.
• Community/Development Incentives - The allocation of inflation to support the growth and development of the protocol in order to stay competitive within the market landscape.
• Liquidity Incentives - Rewards for RPL and rETH liquidity to help node operators acquire collateral and allow rETH to play a viable role in DeFi and the broader Ethereum ecosystem.

Over a longer time frame, Rocket Pool governance may elect to govern:

• RPL Inflation - RPIP003 proposes to implement a fixed 5% inflation rate for the first year, starting at mainnet launch. Rocket Pool Governance will be able to elect a long-term programmatic issuance schedule upon analyzing the data and feedback from the initial period.
• Protocol Fees - While not activated at launch, the Rocket Pool community may elect to introduce protocol fees from staking. The community can adjust the fee rate with the hope of having it stabilize over the long term.
• Protocol Upgrades - In the future, all Rocket Pool protocol upgrades will be owned and executed through governance.

Trusted Node DAO

This DAO governs the group of ‘Trusted nodes’ that act as an oracle from the ETH2 beacon chain.

The Trusted Node DAO is a permissioned group of known actors governing:

• Admission - Vetting new trusted node operators who have passed identify verification and been championed by an existing Trusted Node operator.
• Requirements - Determining RPL stake (10,000 RPL), maximum validators and technical requirements.
• DAO Parameters - Solidifying and adjusting quorum (66%) and majority (75%) of the Trusted Node DAO as the number of members expands.
• Disputes - Establishing standards for slashing in the event of malicious behaviour and grounds for trusted nodes removal.

Conclusion

All together, this blueprint for governance marks the first step in decentralizing ownership of the Rocket Pool protocol to the community of RPL holders. The topics presented in this post should be finalized in line with community feedback, and implemented as a part of RPIP003.

As a group heavily involved in governance across many DeFi protocols, we have taken the best practices to offer a minimum viable path to decentralization, rather than proposing a full fledged DAO out of the gate.

We look forward to hearing feedback from the community and setting a precedent for community-owned staking using Rocket Pool as the standard.

[Tristannn]

Are Trusted Nodes necessary after Phase 1.5? I understand the existence of an oracle is important while the eth1 and eth2 chains are separated, but once they’ve merged I don’t see their purpose.

The whitepaper adds that “Trusted Node Operators are a backup; they ensure the network can continue to onboard new users if there is no capacity with Untrusted Node Operators” however, this seems like an unnecessary role when node operator commission rates could just be increased to balance the supply and demand of operators to users.

[Tristannn]

Also, I’m assuming that “LP tokens” are referring to the RPL tokens staked by liquidity providers, and not a new token being introduced?

[Tristannn]

Also, I’d be interested in adding into the spec immutable limits on the DAO’s power, particularly to slow down potential changes. For example, maybe a limit on the amount that commission fees may change by over a 30 day period. Or clamp the range within where commission fees are allowed to fluctuate. These sorts of limits would both offer a security to rETH stakers and DAO members alike, such that the community has time to become aware of unpopular changes occurring and react.

[coopahtroopa]

That’s correct. LP tokens are a representation of liquidity deposited to an AMM like Balancer. Still TBD exactly what this LP token will consist of but the key thing here is that just providing liquidity does not earn governance weight, only those staked within the system.

[Pieter]

Great to see some info on the vision for Rocket Pool governance! I must say the ‘minimum viable governance’ already contains quite a few parameters, more than I was expecting. Which brings me to my first question…

Is all the ‘minimum viable DAO governance’ considered essential / blocking for the Rocket Pool launch?
The Rocket Pool team can only implement so much functionality in a given time, and audits will be needed as well. DAO Governance is very important to Rocket Pool’s long term vision, but time-to-market is critical as well. Already users are expressing frustration of not being able to stake with Rocket Pool for the genesis of the beacon chain. You could imagine the reactions if a competitor beats Rocket Pool to launch.

What are the liquidity incentives, exactly?
Are the mentioned liquidity incentives for RPL separate from the rewards from staking RPL in the overflow pool? And where would incentives for rETH liquidity originate? The overflow pool is a RPL/ETH pool, so not there, obviously.

What will be the mechanisms for governance?

• A LP token for staked RPL is mentioned. When a vote comes up, is this token to be ‘delegated’ a la UNI governance? But node operators do not have LP tokens, so how will voting work with the RPL staked on their node?
• Will there be a quorum for governance votes? And if so, will it be a single quorum, or separate ones for node operator and RPL staker participation?
• Voter participation is always an issue for governance. If not enough node operators participate (and depending on quorums, if any) non-validators could still push through governance decisions. Will there be additional incentives for participating in governance?
• Will there be timelocking or snapshot-like functionality to prevent actors from buying a large share of RPL to vote and immediately divesting it afterwards?
• Will there be automation for governance, e.g. for adjusting the predefined parameters? Or will any and all proposals need to be ‘coded up’ like with Uniswap governance?

What is meant by ‘protocol fees’?
Would this be a share of staking gains that goes to passive RPL holders?
If so, I’m not a fan. If not - you can disregard the rest of this post

The current rewards for staking RPL as a node operato or overflow pool staker have a certain elegance - you don’t get something for nothing, you’re providing a service to the Rocket Pool network. Passive protocol fees go against that. The only plus I see is that it will increase demand for the RPL token.
But will this attract the right actors to the ecosystem? The danger I see is that such investors are mostly interested in guarding and increasing their RPL monetary value, rather than fostering a productive community in a broad sense (if again Uniswap governance is any example).
Another aspect is that this ‘rent-seeking’ could decrease Rocket Pool’s competitiveness vs. other staking pools.

I suppose there will be public demand for this and it’s good to put it on the table for discussion now, because when governance is completely opened up in the long term, it would surely come up then.

[Callum]

10/10 agree with this! We’re looking at implementing:

• A limit on the amount commission fee bounds can move in one ‘voting period’.
• A delay function on changes implemented by governance votes.
• A fairly long voting period to ensure that all governors have time to react and vote.

A combination of some/all of these mechanics plus others makes a lot of sense! We’ll take these into account as we continue to map out the finer details of both genesis and longer term governance.

[Callum]

Timeline of MVP governance and wider rollout:

The ability to set ownership of the Rocket Pool deposit contract to a smart contract (this is something that’s essential to the rETH based Rocket Pool system) is planned in an upcoming upgrade and as such, the team has decided to hold off until this upgrade to avoid rolling out with a pretty big point of centralisation (setting ownership to a custodian) plus the variety of other headaches that this would introduce! The genesis governance implementation is expected to be completed in the next few weeks, then on to audits, etc.

As a side note, the Rocket Pool team ships code at an astounding rate, we’ve been hugely impressed in this regard!

What are the liquidity incentives, exactly?

Are the mentioned liquidity incentives for RPL separate from the rewards from staking RPL in the overflow pool? And where would incentives for rETH liquidity originate? The overflow pool is a RPL/ETH pool, so not there, obviously.

Incentives for native RPL/ETH liquidity within the Reserve Pool come from the specific Reserve Pool allocation. We’re also looking to incentivize both RPL/ETH and rETH/ETH liquidity on external AMMs such as Uniswap and Balancer as required, these incentives will come from the ‘Ecosystem Incentives’ allocation of inflation.

What will be the mechanisms for governance?

A LP token for staked RPL is mentioned. When a vote comes up, is this token to be ‘delegated’ a la UNI governance? But node operators do not have LP tokens, so how will voting work with the RPL staked on their node?

As the Reserve Pool will be implemented as a native liquidity pool, LP tokens acquired by users depositing into the Reserve Pool will be staked into the system and used to calculate governance weight. Node operators on the other hand, will have their governance weight calculated directly from the RPL staked to their validators (+ liveness post-genesis).

Will there be a quorum for governance votes? And if so, will it be a single quorum, or separate ones for node operator and RPL staker participation?

Specifics around the implementation and operation of genesis governance are being worked on internally and will be shared with the community as they become clearer and more finalised. Separate quorum requirements for node operators and reserve pool stakers is an interesting idea, we’ll have a think about how this would work, plus follow-on positive/negative effects if we were to implement this kind of quorum system.

Voter participation is always an issue for governance. If not enough node operators participate (and depending on quorums, if any) non-validators could still push through governance decisions. Will there be additional incentives for participating in governance?

Node operators will be required to participate in governance in order to collect their RPL rewards. As mentioned above, the idea of separate quorums is something we’ll explore to potentially mitigate this issue. Governance participation incentives is something we’re incredibly excited about in a broader context but will likely be introduced further down the line as opposed to with the genesis rollout.

Will there be timelocking or snapshot-like functionality to prevent actors from buying a large share of RPL to vote and immediately divesting it afterwards?

As mentioned in a reply to @ghosts_in_the_code over in the RPIP #003 thread, governance will require some level of timelock/cooldown period in order to prevent potential attack vectors using flash loans or similar tactics. On the node operator side, this is taken care of by the withdrawal cooldown function. On the Reserve Pool side, we’re currently working on mechanisms to protect against this kind of attack!

Will there be automation for governance, e.g. for adjusting the predefined parameters? Or will any and all proposals need to be ‘coded up’ like with Uniswap governance?

There will be a contract which holds all governable parameters, this contract will be proxied by the governance contract which will be able to change parameters as necessary. For predefined parameters there will be ‘some’ level of automation, for the introduction of new governable parameters and similar changes, there will be some manual work involved.

What is meant by ‘protocol fees’?

‘Protocol fees’ is essentially a blanket term for the possibility that the community decides to introduce a fee somewhere within the system in order to drive revenue to the Rocket Pool DAO and/or RPL. This isn’t something that will be implemented at genesis, more that we’re acknowledging the fact that once governance is in the hands of the community, this is something that could happen!

[Pieter]

Thank you for the in-depth reply! I’m getting more and more excited with all these details coming out. Great work!

Requiring node operators to participate in governance to claim their rewards is a nice touch, this will already help improve governance participation from operators a lot. We’ll need clear lines of communication when proposals are introduced so operator’s don’t accidentally miss one. Maybe even a built-in alert from the Rocket Pool node software.
And there will need to be some limitations on the creation of governance proposals, so the workload to evaluate them all remains reasonable for node operators. It isn’t a day job, after all

[Tristannn]

I propose that there are three groups of stakeholders in the RocketPool ecosystem:

1. Stakers - Customers of RocketPool.
2. Operators - Earn rewards for Stakers.
3. Investors - RPL holders.

And that each of these stakeholders control a “House” within the DAO. The House of Stakers would vote with staked rETH, the House of Investors would vote with staked RPL, and the House of Operators would vote by some measure of the earnings they’ve made for the pool as a whole. Proposals that pass one house are then sent to the two other houses for a vote. Proposals that pass 2/3 of houses become binding.

This does a few things I think are important:

• Gives a voice to stakers.
• Positions investors to settle disputes between Operators and Stakers.
• Facilitates the will of a house to be heard even if a proposal doesn’t pass the other two houses.
• Offers an opportunity to simplify the discussion and design of the ecosystem by organizing the mechanics and relationships around fundamental roles.

[Pieter]

Those three groups of stakeholders are quite accurate, I think. (Perhaps Trusted Node Operators are a fourth separate group since they have additional responsibilities.)

There is some overlap between Operators and Investors in the current model, since Operators’ governance weight is decided by their RPL stake. In effect, both Stakers and Operators need to make additional investments (effectively becoming part of 3, Investors) to have a say in governance.

Your suggestion decouples 1 and 2 from the need to buy RPL for governance and gives them a voice just for being involved as an actor in the ecosystem. There’s certainly something to be said for that, but it does reduce the overall use-cases and demand for RPL.

[Tristannn]

@Pieter

it does reduce the overall use-cases and demand for RPL.

It does upend some current ideas for it, but it also gives us an opportunity to discuss the value and role they have:

• Investors are fundamentally concerned with the growth of the ecosystem. This means funding improvements, adding features, marketing, etc.
• and are incentivized by future profits, dividends, and their investment is fundamentally backed by the book value of the assets.

There’s a good argument that fees should be taken from Stakers and Operators to fund future development of the ecosystem, and that it’s the investors who “own” these fees.

Without thinking about it too hard, I’m just going to assume that the insurance pool and fees are the same pool… call it the treasury. And that proposals that pass the DAO can pull from the treasury. RPL holders then should be able to burn their RPL for a relative portion of the treasury, as you would in a Moloch DAO.

I don’t think I’ve described everything we need to justify the value of RPL here. There’s probably an argument in here somewhere that trusted nodes are either run by investors or “owned” by investors? Not sure that fixes anything, and I personally don’t want to give trusted nodes a reason to keep existing beyond phase 1.5.

But, discussing the value of RPL on these terms helps to keep the Staker and Operator roles simple, which I think is important to convincing Stakers and Operators to sign up.