Powers and authorities informational rpip by prose11 · Pull Request #110 · rocket-pool/RPIPs

prose11 · 2023-11-07T15:31:07Z

Finally turned this into an informational RPIP any formatting or content comments and suggestions are most welcome @Valdorff

…onal-RPIP

Valdorff · 2023-11-11T19:54:14Z

+
+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.


I think the example here and in Power could be more concrete. Maybe the oDAO's power to report any rETH price and their authority to report an accurate blockchain price.

I like the power example a lot, I'm less sold on the authority side. I tried updating the language to convey it a little more clearly, not sure if you think this addresses this point however.

For authority the main thing I want to preserve is that it's based on shared understanding rather than physical access. I think using the same price setting bit could be confusing there and instead convey that authority is the responsibility to do something rather than the shared permission to take action.

Valdorff · 2023-11-11T20:08:29Z

+
+* The oDAO has the power to replace any contract (except RocketStorage) in the Rocket Pool protocol via the oDAO upgrade power.
+* The oDAO has the power to modify any non-protected parameter in the Rocket Pool protocol via the oDAO upgrade power.
+* The oDAO has the power to call core contract functions protected by the generic ‘onlyLatestNetworkContract’ required via the oDAO upgrade power. This has several implications, most notably:


These 3 sub-bullets are a bit weird...

The first one would require a contract upgrade with faked up contracts with appropriate names to fool the check in RocketVault require(etherBalances[contractName] >= _amount, "Insufficient contract ETH balance");. I don't believe they have immediate access unless I'm missing something.

The second bullet would also require a contract upgrade for arbitrary withdrawals... or they could fake up a merkle tree, which is probably a lot easier and has no dependence on onlyLatestNetworkContract

The third bullet is possible via RocketNetworkPenalties.submitPenalty. The critical check is onlyTrustedNode, not onlyLatestNetworkContract

Minor aside: why are we using front ticks ‘onlyLatestNetworkContract’ instead of backticks onlyLatestNetworkContract?

The oDAO has the power to replace any upgradeable contract (excludes RocketStorage and the token contracts) in the Rocket Pool protocol via the oDAO upgrade power, provided it is not vetoed by the Security Council and the required time delay has elapsed.

The oDAO has the power to modify any non-protected parameter in the Rocket Pool protocol via the oDAO upgrade power, provided it is not vetoed by the Security Council and the required time delay has elapsed.

The above has several implications, most notably:

Valdorff · 2023-11-11T20:12:21Z

+* The oDAO has the power to modify oDAO settings via the oDAO settings pathway.
+* The oDAO has the power to take actions that modify the membership of the oDAO.
+* The oDAO has the power to determine the split of RPL inflation via consensus on a rewards Merkle tree. [[GitHub](https://github.com/rocket-pool/rocketpool-research/blob/v6/Merkle%20Rewards%20System/rewards-calculation-spec.md)]
+* The oDAO has the power to withdraw ETH at no cost from the deposit pool contract, via manipulation of the rETH exchange rate. [[Etherscan](https://etherscan.io/address/0xDD3f50F8A6CafbE9b31a427582963f465E745AF8)]


I'd probably talk about the power to set the exchange rate, and have these as sub-bullets.

The oDAO has the power to set the protocols rETH exchange rate.

Note that manipulating this value would allow for withdrawing ETH at no cost (from both the deposit pool contract and rETH token contract).

The oDAO has the power to set the protocol's rETH exchange rate, up to the max 2% per day.

Note that manipulating this value would allow for withdrawing ETH at no cost (from both the deposit pool contract and rETH token contract).

Valdorff · 2023-11-11T20:17:43Z

+
+##### Description
+
+Any individual Rocket Pool Registered Node. All Trusted Nodes (oDAO) are also Registered Nodes (pDAO).


Minor technicality... A registered node running zero minipools has no pDAO vote power.

So it's more like "All pDAO members must have a Registered Node. All oDAO members must have a registered node, which is considered a Trusted Node."

Any individual Rocket Pool Registered Node. All pDAO members must have a Registered Node. All oDAO members must have a registered node.

LongForWisdom · 2023-11-13T14:59:44Z

See messages in discord here. Also screencapped.

…onal-RPIP

maverickrp

Proposed update to this draft to bring all sections up to date

maverickrp · 2026-08-17T22:20:55Z

+
+##### Description
+
+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 the time of writing.


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. Almost all of its initial powers have been irrevocably disabled.

maverickrp · 2026-08-17T22:21:44Z

+* The Guardian address has the power to modify pDAO settings via the pDAO settings pathway.
+* The Guardian address has the power to modify the share of RPL inflation via the pDAO bootstrap pathway.
+* The Guardian address has the power to spend the RPL tokens allocated to the pDAO via the pDAO bootstrap pathway.
+* The Guardian address has the power to set the maximum penalty rate for minipools via the RocketMinipoolPenalty contract.


The Guardian has the power to set the maximum penalty rate in the RocketMinipoolPenalty contract. This sets the maximum rate at which the oDAO can penalise minipools (megapool validators are excluded); it is currently set to zero.

maverickrp · 2026-08-17T22:22:08Z

+
+#### Authorities
+
+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.


The Guardian has the authority, as delegated from the oDAO, to set the maximum penalty rate in the RocketMinipoolPenalty contract

maverickrp · 2026-08-17T22:22:44Z

+
+##### Description
+
+ProtocolDAO governance is defined as successful governance proposals voted on by Rocket Pool community members running Registered Nodes.


ProtocolDAO governance is defined as successful governance proposals voted on by Rocket Pool community members running Registered Nodes using a trustless onchain fraud-proof voting system. A node’s voting power is a function of its staked RPL. Proposals require a bond, may be challenged by other node operators, and pass through a mandatory challenge period delay and two-phase voting process before execution.

maverickrp · 2026-08-17T22:23:12Z

+
+##### Powers
+
+The pDAO currently has no direct, on-chain power over the Rocket Pool protocol.


The pDAO has the power to change a defined table of protocol settings across deposit, inflation, minipool/megapool, network, node, rewards, proposal, auction, and security-council parameters, via successful onchain ‘Parameter Change’ proposals.

The pDAO has the power to spend treasury RPL, either as one-off ‘Treasury Spend’ proposals or as recurring ‘Treasury Contract’ payments

The pDAO has the power to invite and remove Security Council members and to set the council’s quorum, via ‘Security Council Change’ proposals

The pDAO has the power to veto a proposal it deems spam or malicious via a dedicated on-chain veto vote, with a successful veto burning the proposer’s bond

maverickrp · 2026-08-17T22:30:58Z

+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 (but not authority) to use the pDAO settings pathway at will with no delay.


Usage of the oDAO pathways to do anything requires a majority vote from oDAO members. There is an upgrade delay of 7 days of ODAO period, plus 7 days of veto before execution.

pDAO onchain proposals are subject to a bonded propose-and-challenge period, a mandatory pre-vote delay, and a two-phase vote before execution.

Security Council actions take effect immediately once quorum is reached, but only for the pre-approved, guardrailed parameter subset.

maverickrp · 2026-08-17T22:32:25Z

+
+* The oDAO has the power to replace any contract (except RocketStorage) in the Rocket Pool protocol via the oDAO upgrade power.
+* The oDAO has the power to modify any non-protected parameter in the Rocket Pool protocol via the oDAO upgrade power.
+* The oDAO has the power to call core contract functions protected by the generic ‘onlyLatestNetworkContract’ required via the oDAO upgrade power. This has several implications, most notably:


The oDAO has the power to replace any upgradeable contract (excludes RocketStorage and the token contracts) in the Rocket Pool protocol via the oDAO upgrade power, provided it is not vetoed by the Security Council and the required time delay has elapsed.

The oDAO has the power to modify any non-protected parameter in the Rocket Pool protocol via the oDAO upgrade power, provided it is not vetoed by the Security Council and the required time delay has elapsed.

The above has several implications, most notably:

maverickrp · 2026-08-17T22:33:10Z

+* The oDAO has the power to call core contract functions protected by the generic ‘onlyLatestNetworkContract’ required via the oDAO upgrade power. This has several 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 ability to set the Minipool penalty within the bounds of the maximum penalty. A pDAO-controlled guardrail caps how much can be penalised over time.

maverickrp · 2026-08-17T22:34:17Z

+* The oDAO has the power to modify oDAO settings via the oDAO settings pathway.
+* The oDAO has the power to take actions that modify the membership of the oDAO.
+* The oDAO has the power to determine the split of RPL inflation via consensus on a rewards Merkle tree. [[GitHub](https://github.com/rocket-pool/rocketpool-research/blob/v6/Merkle%20Rewards%20System/rewards-calculation-spec.md)]
+* The oDAO has the power to withdraw ETH at no cost from the deposit pool contract, via manipulation of the rETH exchange rate. [[Etherscan](https://etherscan.io/address/0xDD3f50F8A6CafbE9b31a427582963f465E745AF8)]


The oDAO has the power to set the protocol's rETH exchange rate, up to the max 2% per day.

Note that manipulating this value would allow for withdrawing ETH at no cost (from both the deposit pool contract and rETH token contract).

maverickrp · 2026-08-17T22:34:53Z

+* The oDAO has the power to approve the canonical rewards Merkle tree at the end of each reward period. [[Etherscan](https://etherscan.io/address/0xA805d68b61956BC92d556F2bE6d18747adAeEe82#code#F1#L165)] This uses a separate governance pathway. 
+
+##### Authorities
+


oDAO has the authority to replace any upgradeable contract (excludes RocketStorage and the token contracts) in the Rocket Pool protocol via the oDAO upgrade power, provided it is not vetoed by the Security Council and the required time delay has elapsed, and provided that the pDAO have first ratified the upgrade.

maverickrp · 2026-08-21T16:13:12Z

+
+##### Description
+
+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](RPIP-26.md)], this committee must consist of nine members.


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-40], this committee must consist of seven members.

maverickrp · 2026-08-21T16:13:15Z

+
+##### Description
+
+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](RPIP-26.md)], this committee must consist of nine members.


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-40], this committee must consist of seven members.

prose11 added 14 commits October 23, 2023 09:47

Create RPIP-X draft

71552c9

Merge branch 'rocket-pool:main' into Powers-and-Authorities-Informati…

9254113

…onal-RPIP

Adding copywrite

7dbd573

Converting to relative links

1025c3c

Create test.md

38b6b93

Adding diagram

9eacd94

removing item

9e7fd13

Adding relative graphic link

01c398c

incorporating feedback

c8e2677

Adding example

daca633

Updating Date

38eea25

Removing unnecessary abstract wording

c4472ff

Removing inaccurate example

d7b73d2

grammar

6948298

Valdorff reviewed Nov 11, 2023

View reviewed changes

prose11 added 4 commits November 16, 2023 09:47

Correcting typo

4393bb5

Updating phrasing and examples

74913ad

removing "via consensus"

b6c5481

Merge branch 'rocket-pool:main' into Powers-and-Authorities-Informati…

97960f8

…onal-RPIP

maverickrp suggested changes Aug 17, 2026

View reviewed changes

maverickrp reviewed Aug 21, 2026

View reviewed changes


		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.


		##### Description

		Any individual Rocket Pool Registered Node. All Trusted Nodes (oDAO) are also Registered Nodes (pDAO).


		#### Authorities

		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.


		##### Powers

		The pDAO currently has no direct, on-chain power over the Rocket Pool protocol.

		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 (but not authority) to use the pDAO settings pathway at will with no delay.

		* The oDAO has the power to approve the canonical rewards Merkle tree at the end of each reward period. [[Etherscan](https://etherscan.io/address/0xA805d68b61956BC92d556F2bE6d18747adAeEe82#code#F1#L165)] This uses a separate governance pathway.

		##### Authorities

Uh oh!

Conversation

prose11 commented Nov 7, 2023

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LongForWisdom commented Nov 13, 2023

Uh oh!

maverickrp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants