GovAlpha produced a report describing the powers and authorities within Rocket Pool based on community documentation (like RPIPs, Github Repos, and forum posts) and smart contract code. We’ve broken these down into the principals and agents that have a role that impacts the Rocket Pool protocol.
Rocket Pool functions through a complex mix of duties, rights, and rules carried out by multiple principals and agents. We had a hard time piecing together some of the information we felt we needed to get our heads around Rocket Pool’s structure, so we broke it down into a single document that made sense to us.
In this document, we attempt to explain how Rocket Pool’s governance works by focusing on its powers and authorities. If you’re interested in a deeper dive, we’ve included references and links to more detailed information at the end.
Your feedback and suggestions for corrections are welcome and encouraged. We intend to update this document based on community feedback and hope it becomes a helpful resource for the broader ecosystem.
There are a number of terms used in this document that are worth defining explicitly to avoid misunderstanding and ambiguity.
An individual or entity that can be said to ‘own’ the protocol.
An individual or entity that provides some service to the principals, or holds power delegated by the principals.
Power in this document is used to refer to the raw capability to do something. This refers to explicit permissions granted in the protocol’s smart contracts, administrative access to software platforms, and so on.
A principal or agent has the power to perform action X when every limitation to their role in performing action X is self-applied, rather than being applied by another party.
To give an example, the oDAO has the power to make changes to the Rocket Pool Protocol due to the permissions trustedNodes (in aggregate) hold in the protocol contracts, and because the limitations to the oDAO ratified by the pDAO are self-applied by the oDAO.
Best expressed in the phrase: ‘Are we able to do X?’
Authority in this document is used to refer to the right to do something. This refers to the implicit and explicit decisions made by the community at large as to ‘who do we want to do X’.
A principal or agent has the authority to do X if the Rocket Pool community has explicitly or implicitly agreed that that principal or agent is allowed or supposed to be doing X.
To give an example, the pDAO has the authority to make changes to the Rocket Pool Protocol due to the shared understanding of the community that registeredNodes are the ‘principals’ of the Rocket Pool protocol.
Best expressed in the phrase: ‘Are we allowed to do X?’
OracleDAO governance, defined as successful on-chain governance proposals voted on by oDAO members running oDAO nodes.
- The oDAO has the power to replace any contract (except RocketStorage) in the Rocket Pool protocol via the oDAO upgrade power [Reference]
- The oDAO has the power to modify any non-protected parameter in the Rocket Pool protocol via the oDAO upgrade power. [Reference]
- The oDAO has the power to call core contract functions protected by the generic ‘onlyLatestNetworkContract’ required via the oDAO upgrade power. [Reference]. This has a number of implications, most notably:
- The ability to withdraw RPL and ether from the RocketVault contract.
- The ability to withdraw ether from the RocketSmoothingPool contract.
- The ability to set the Minipool penalty within the bounds of the maximum penalty.
- The oDAO has the power to modify oDAO settings via the oDAO settings pathway. [Reference]
- The oDAO has the power to take actions that modify the membership of the oDAO. [Reference]
- The oDAO has the power to determine the split of RPL inflation via consensus on a rewards merkle tree. [GitHub]
- The oDAO has the power to withdraw ETH at no cost from the deposit pool contract, via manipulation of the rETH exchange rate. [Etherscan]
- The oDAO has the power to withdraw ETH at no cost from the rETH token contract via manipulation of the rETH exchange rate. [Etherscan]
- The oDAO has the power to approve the canonical rewards Merkle tree at the end of each reward period. [Etherscan] This uses a separate governance pathway.
- oDAO has the authority to veto changes approved by the pDAO if they have reason to believe the changes meet any of the following criteria according to [RPIP-24]:
- Not voted by the pDAO
- A result of vote manipulation in the pDAO
- Would result in clear damage to the Rocket Pool project
- The oDAO has the authority to maintain its own membership. [RPIP-24]
The guardian address is an EOA defined in the RocketStorage contract (but outside the key-value mappings.) It was responsible for the initialization of the protocol. Some of its initial powers have been irrevocably disabled, while others are still active at time of writing.
The guardian address is likely controlled by Rocket Pool Pty Ltd.
- The Guardian address has the power to modify pDAO settings via the pDAO settings pathway. [Reference]
- The Guardian address has the power to modify the share of RPL inflation via the pDAO bootstrap pathway. [Reference]
- The Guardian address has the power to spend the RPL tokens allocated to the pDAO via the pDAO bootstrap pathway. [Reference]
- The Guardian address has the power to set the maximum penalty rate for minipools via the RocketMinipoolPenalty contract. [Reference]
No authorities have been assigned to the guardian address by the pDAO. Indirect authorities are inherited from the assumption that the guardian is controlled by Rocket Pool Pty Ltd and are listed in that section.
ProtocolDAO governance, defined as successful governance proposals voted on by Rocket Pool community members running Registered Nodes.
The pDAO currently has no direct, on-chain power over the Rocket Pool protocol.
The pDAO as a collective is considered the principal of the Rocket Pool protocol. When Authority over the Rocket Pool protocol lies with the pDAO, with the exception of that related to the oDAO, which maintains authority over itself. Changes to the protocol are only allowed be done through following pDAO’s governance process.
Its authorities include, but are not limited to:
- The authority to add, remove, replace or amend RPIPs.
- The authority to determine the membership of committees defined by RPIPs.
- The authority to add, remove, or upgrade the functionality of the Rocket Pool protocol.
- The authority to determine the distribution of RPL inflation.
- The authority to engage agents on its behalf.
- The authority to delegate specific authorities to separate governance processes.
Any individual Rocket Pool Registered Node. All Trusted Nodes are also Registered Nodes.
- Registered Nodes have the power to challenge an individual oDAO member to ensure they are fulfilling their responsibilities. [Etherscan]
- Registered Nodes have the power to become oDAO members unilaterally if there are less than 3 oDAO members. [Etherscan]
- Registered Nodes have the power to accept an invitation to the oDAO. [Etherscan]
There are no protocol-affecting authorities held by individual Registered Nodes.
Rocket Pool Pty Ltd is the legal entity that created and deployed the Rocket Pool Protocol. It retains the intellectual property and is currently acting as a conservator while powers and authorities are transferred to the less centralized DAO structures.
- Rocket Pool Pty Ltd has the power to moderate and modify the Rocket Pool Discord Server.
- Rocket Pool Pty Ltd has the power to moderate and modify the Discourse forum instance.
- Rocket Pool Pty Ltd has the power to add and remove documentation to the official documentation page.
- Rocket Pool Pty Ltd has the power to administer the Rocket Pool Github organization.
- Rocket Pool Pty Ltd has the power to administer and author polls on the Rocket Pool Snapshot instance. This includes the ability to select the voting strategy.
As founder of the protocol, Rocket Pool Pty Ltd has broad implied authority, in areas where the pDAO has not claimed or revoked them. This includes the authority to declare work by the community as officially associated with Rocket Pool. An example of this is the sanctioning of the bug bounty program.
While the full social authorities for the company are hard to capture due to the difference granted to the organization, the following categories are backed up by potential court proceedings:
- Domain names
The powers and authorities above can be quite broad-reaching but may cover up some important explicit procedures of trust carried by Rocket Pool Pty Ltd.
- Rocket Poll Pty Ltd verifies updates to the Smartnode Repository and releases them with the expectation that node operators will manually update to new releases.
- Following this guideline, Rocket Pool Pty Ltd can push changes for technical adoption that may or may not follow the standard process for RPIP Governance.
RPIP Editors are tasked with ensuring RPIP documents are finalized and correctly formatted prior to voting. The position is apolitical, with RPIP Editors not making value judgments in their duties, but rather evaluating based on completeness and format. [RPIP-1]
- RPIP Editors have the power to modify RPIPs.
- RPIP Editors have the power to determine RPIP status.
- RPIP Editors have the authority to determine when an RPIP is “sound and complete.”
- RPIP Editors have the authority to assign an RPIP number.
- RPIP Editors have the authority to require title changes to RPIPs.
- RPIP Editors have the authority to determine RPIP status.
- RPIP Editors have the authority to require updates to formatting, spelling, and markdown style.
The Grants Management Committee exists to distribute grants and bounties, retrospectively and prospectively, to further the goals of the Rocket Pool protocol. Bound by [RPIP-26], this committee must consist of nine members.
- The GMC has the power to use funds sent to the GMC’s multisig.
- The GMC has the power to add or remove an address from the GMC’s multisig.
- The GMC has the authority to distribute its share of the pDAO’s budget on a rolling basis, in the form of grants, bounties, and retrospective awards.
- The GMC has the authority to remove a GMC member with a vote of ⅔ of the committee so long as it does not violate the multisig requirements agreed by the pDAO [RPIP-10].
- The GMC has the authority to select a GMC Administrator for the committee, through a majority vote of current GMC members.
- The GMC has the authority to select an interim GMC Administrator in the event of a vacancy.
- The GMC has the authority to remove the GMC Administrator through a majority vote.
The Grants Management Council Administrator is responsible for overseeing and facilitating GMC operations, specifically the rolling awards process introduced by [RPIP-26]. The GMC Admin is expected to perform various tasks supporting the efficiency of the GMC such as meeting coordinator, awards facilitator, spokesperson, grants and bounties liaison, treasurer, and governance author.
- The GMC Administrator has no direct, on-chain power over the Rocket Pool protocol.
- The GMC Administrator has no power over funds sent to the GMC multisig.
- The GMC Administrator has the authority to coordinate the voting members of the GMC.
- The GMC Administrator has the authority to interact with parties external to the GMC on its behalf.
The Incentives Management Committee oversees funds and liquidity incentives for Rocket Pool. Primarily its goal is to support rETH liquidity with a secondary focus on RPL liquidity. [RPIP-20]
- The IMC has the power to use funds sent to the IMC’s multisig.
- The IMC has the power to add or remove addresses from the IMC’s multisig.
- The IMC has the authority to distribute funds for supporting rETH liquidity up to the annual allocation determined in [RPIP-20].
- The IMC has the authority to distribute funds for supporting RPL liquidity up to 10% of the annual allocation determined in [RPIP-20].
- The IMC has the authority to remove an IMC member with a vote of ⅔ of the committee so long as it does not violate the multisig requirements agreed by the pDAO. [RPIP-10]
pDAO Treasurer is a position appointed by [RPIP-10] that is responsible for reporting on pDAO expenditures.
The pDAO Treasurer has no direct, on-chain power over the Rocket Pool protocol.
- The pDAO Treasurer has the authority to classify expenditures to the greater community.
- The pDAO Treasurer has the authority to cast the tie-breaking vote in an interim GMC Administrator election. [RPIP-26]
- The pDAO Treasurer has the authority to randomly select from tied candidates in committee member elections. [RPIP-10]
How do we make this Scope of Governance document count? For starters, we want to make sure the information we have compiled is accurate and fully informed (most helpful in the Authorities sections). Please leave a comment on the thread or reach out to us on Discord if we’ve made any mistakes or glaring omissions.
Once we’ve had a chance to address any inaccuracies, we have a few ideas on how to move forward with this document:
- We could create an informational RPIP out of this content.
- We can adapt the format to better fit with the Rocket Pool documentation, and make a PR to add it to the official documentation repository.
- We can prepare an update to the oDAO and pDAO Charters to include the authorities sections for those groups.
- We could try to revise this document for publication to a wider audience (something easy to send around the ecosystem), some ideas include:
- Reword the document to make it less technical and more accessible.
- Make the document more visually appealing.
- Reduce the length of the document by focusing on critical information.
- Atomize the document into several documents to make each one more digestible e.g. focus on oDAO, focus on pDAO etc.
- We could adapt our document into an RPIP about the formal authorities of the protocol for ratification by the community. If ratified, this would make some version of these authorities prescriptive on those groups.
As we bring this document to a close, we would like to acknowledge the Rocket Pool community and all who have provided answers to questions that came up during the creation of this document. Thank you to all those who have helped us along the way.
On the technical side, governance of the Rocket Pool protocol is achieved via a number of main pathways:
- The pDAO settings pathway (change pDAO settings)
- The oDAO settings pathway (change oDAO settings)
- The oDAO upgrade pathway (add/remove/replace contracts)
- The Guardian initialization pathway (no longer usable)
At time of writing, the ‘owners’ of each pathway are:
- pDAO settings pathway - Guardian address
- oDAO settings pathway - oDAO
- oDAO upgrade pathway - oDAO
Usage of the oDAO pathways to do anything requires a majority vote from oDAO members. While a delay is imposed post-proposal-prior-to-vote, there is no post-vote-prior-to-execution time lock present in the Rocket Pool protocol at the time of writing.
The Guardian address has the power to use the pDAO settings pathway at will with no delay.
The settings referred to above are all entries in a key-value store found in the RocketStorage contract.
A list of all contracts considered part of the Rocket Pool protocol is stored in a key-value store in RocketStorage. Any contract within this list has write access to all key-value stores within RocketStorage. Protocol contracts read relevant keys from RocketStorage when executing their functions. Consequently, RocketStorage stores the canonical state of the Rocket Pool protocol.
Settings modifiable by the pDAO (currently controlled by the Guardian address) through the settings pathway, as defined by the following ProtocolSettings contracts.
Note, the namespace for protocol settings is ‘dao.protocol.setting’ which replaces the * below.
$ is used to denote reward recipient contract. There is a settings entry for each rewards recipient.
[Source - Kane’s (core developer) spreadsheet - Not sure if this is publicly uploaded anywhere.]
For an initial list in Github, please see the Rocket Pool pDAO Settings page.
Settings modifiable by the oDAO through the settings pathway, as defined by the following NodeTrustedSettings contracts.
Note, the namespace for Trusted Node (oDAO) settings is ‘dao.trustednodes.setting’ which replaces the * below.
[Source - Knoshua’s oDAO Gitbook]
Rocket Pool’s use of the Snapshot tool for pDAO governance votes is defined in RPIP4 - Community Resolutions and Voting.
The core voting strategy (how vote weight is calculated) for Rocket Pool is also defined in RPIP4, but can be summarized as:
The voting power of a Registered Node is equal to half of the square root of the RPL collateralizing said node. [Reference]
A delegated voting strategy is also in use, but the calculation of voting power for each individual node uses the same formula as the core strategy, just controlled by their chosen delegate. Voters who have delegated their voting power are still able to vote if they wish, this will reduce the voting power of their chosen delegate.
RPIP-4 does not mandate that a specific type of vote must be used for pDAO votes in the Rocket Pool protocol. The following vote-types have been used in the past, listed here in order of frequency:
- Basic Vote - For / Against / Abstain with quorum.
- Weighted Vote - Voter splits their voting power among multiple options.
- Approval Vote - Voter approves any number of options, which all receive their full voting power.
The Rocket Pool Snapshot instance is managed by two admin addresses, assumed to be controlled by Rocket Pool Pty Ltd. An additional address has author permissions, and is also assumed to be controlled by an employee of Rocket Pool Pty Ltd.
Only Admin or Author addresses are permitted to post Snapshot votes at this time. Rocket Pool Pty Ltd takes responsibility for posting votes publicly via the official Rocket Pool discord channel. When Rocket Pool Pty Ltd receives a request it considers valid from a member of the community, most often one of the RPIP Editors, it will post a vote to the Rocket Pool Snapshot.
The oDAO can register any arbitrary contract to RocketStorage via RocketDAONodeTrustedUpgrade, once a contract is registered in RocketStorage, it has permission to modify any non-protected value in RocketStorage. This means a newly added contract can replace any existing contract.
Further, it means that the oDAO can add any arbitrary contract to RocketStorage such that it will pass the onlyLatestNetworkContract requirement and can access other core contracts, most notably RocketVault.
This functionality has been used previously to perform protocol upgrades to Rocket Pool.
The oDAO can take a number of actions related to maintaining the oDAO membership. Settings related to this are controlled through the settings pathway, but actual membership changes go through the RocketDAONodeTrustedActions contract.
The pDAO (currently controlled by the Guardian address) has access to a number of bootstrapping functions in the RocketDAOProtocol contract that allows it to: