Rocket Pool Powers and Authorities

Governance
1

Rocket Pool Powers and Authorities

Abstract

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.

Introduction

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.

Definitions

There are a number of terms used in this document that are worth defining explicitly to avoid misunderstanding and ambiguity.

Principal

An individual or entity that can be said to ‘own’ the protocol.

Agent

An individual or entity that provides some service to the principals, or holds power delegated by the principals.

Power

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

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?’

Principals and Agents

oDAO governance

Description

OracleDAO governance, defined as successful on-chain governance proposals voted on by oDAO members running oDAO nodes.

Powers

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

Authorities

  • 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]:
    • Malicious
    • 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]

Guardian

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 time of writing.

The guardian address is likely controlled by Rocket Pool Pty Ltd.

Powers

  • 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]

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.

pDAO governance

Description

ProtocolDAO governance, defined as successful governance proposals voted on by Rocket Pool community members running Registered Nodes.

Powers

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

Authorities

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.

Individual Registered Nodes (oDAO or pDAO)

Description

Any individual Rocket Pool Registered Node. All Trusted Nodes are also Registered Nodes.

Powers

  • 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]

Authorities

There are no protocol-affecting authorities held by individual Registered Nodes.

Rocket Pool Pty Ltd

Description

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.

Powers

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

Authorities

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:

Software Pipeline

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

Description

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]

Powers

  • RPIP Editors have the power to modify RPIPs.
  • RPIP Editors have the power to determine RPIP status.

Authorities

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

GMC

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

Powers

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

Authorities

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

GMC Administrator

Description

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.

Powers

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

Authorities

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

IMC

Description

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]

Powers

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

Authorities

  • 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

Description

pDAO Treasurer is a position appointed by [RPIP-10] that is responsible for reporting on pDAO expenditures.

Powers

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

Authorities

  • 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]

Next Steps

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.

Acknowledgements

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.

Appendices

Appendix 1: Technical Design of Governance

Details

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

1886×1013 225 KB

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.

Appendix 2: pDAO Settings

Details

Settings modifiable by the pDAO (currently controlled by the Guardian address) through the settings pathway, as defined by the following ProtocolSettings contracts.

  • rocketDAOProtocolSettingsAuction
  • rocketDAOProtocolSettingsDeposit
  • rocketDAOProtocolSettingsInflation
  • rocketDAOProtocolSettingsMinipool
  • rocketDAOProtocolSettingsNetwork
  • rocketDAOProtocolSettingsNode
  • rocketDAOProtocolSettingsRewards

Note, the namespace for protocol settings is ‘dao.protocol.setting’ which replaces the * below.

rocketDAOProtocolSettingsAuction

  • *.auction.lot.create.enabled
  • *.auction.lot.bidding.enabled
  • *.auction.lot.value.minimum
  • *.auction.lot.value.maximum
  • *.auction.lot.duration
  • *.auction.price.start
  • *.auction.price.reserve

rocketDAOProtocolSettingsDeposit

  • *.deposit.enabled
  • *.deposit.assign.enabled
  • *.deposit.minimum
  • *.deposit.pool.maximum
  • *.deposit.assign.maximum
  • *.deposit.assign.socialised.maximum
  • *.deposit.fee

rocketDAOProtocolSettingsInflation

  • *.rpl.inflation.interval.rate
  • *.rpl.inflation.interval.start

rocketDAOProtocolSettingsMinipool

  • *.minipool.submit.withdrawable.enabled
  • *.minipool.bond.reduction.enabled
  • *.minipool.launch.timeout
  • *.minipool.maximum.count
  • *.minipool.user.distribute.window.start
  • *.minipool.user.distribute.window.length

rocketDAOProtocolSettingsNetwork

  • *.network.consensus.threshold
  • *.network.submit.balances.enabled
  • *.network.submit.balances.frequency
  • *.network.submit.prices.enabled
  • *.network.submit.prices.frequency
  • *.network.node.fee.minimum
  • *.network.node.fee.target
  • *.network.node.fee.maximum
  • *.network.node.fee.demand.range
  • *.network.reth.collateral.target
  • *.network.penalty.threshold
  • *.network.penalty.per.rate
  • *.network.submit.rewards.enabled

rocketDAOProtocolSettingsNode

  • *.node.registration.enabled
  • *.node.smoothing.pool.registration.enabled
  • *.node.deposit.enabled
  • *.node.vacant.minipools.enabled
  • *.node.per.minipool.stake.minimum
  • *.node.per.minipool.stake.maximum

rocketDAOProtocolSettingsRewards

$ is used to denote reward recipient contract. There is a settings entry for each rewards recipient.

  • *.rpl.rewards.claim.period.time
  • *.rpl.rewards.claims.group.totalPerc
  • *.rpl.rewards.claims.group.amount.$
  • *.rpl.rewards.claims.group.amount.updated.time.$

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

Appendix 3: oDAO Settings

Details

Settings modifiable by the oDAO through the settings pathway, as defined by the following NodeTrustedSettings contracts.

  • rocketDAONodeTrustedSettingsMembers
  • rocketDAONodeTrustedSettingsMinipool
  • rocketDAONodeTrustedSettingsProposals
  • rocketDAONodeTrustedSettingsRewards

Note, the namespace for Trusted Node (oDAO) settings is ‘dao.trustednodes.setting’ which replaces the * below.

rocketDAONodeTrustedSettingsMembers

  • *.members.quorum:
  • *.members.rplbond
  • *.members.minipool.unbonded.max
  • *.members.minipool.unbonded.min.fee
  • *.members.challenge.cooldown
  • *.members.challenge.window
  • *.members.challenge.cost

rocketDAONodeTrustedSettingsMinipool

  • *.minipool.scrub.period
  • *.minipool.promotion.scrub.period
  • *.minipool.scrub.quorum
  • *.minipool.scrub.penalty.enabled
  • *.minipool.bond.reduction.window.start
  • *.minipool.bond.reduction.window.length
  • *.minipool.cancel.bond.reduction.quorum

rocketDAONodeTrustedSettingsProposals

  • *.proposal.cooldown.time
  • *.proposal.vote.time
  • *.proposal.vote.delay.time
  • *.proposal.execute.time
  • *.proposal.action.time

rocketDAONodeTrustedSettingsRewards

  • *.rewards.network.enabled

[Source - Knoshua’s oDAO Gitbook]

Appendix 4: Snapshot

Details

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.

References

oDAO Upgrade Power

Details

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.

oDAO Internal Actions

Details

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.

pDAO Bootstrapping

Details

The pDAO (currently controlled by the Guardian address) has access to a number of bootstrapping functions in the RocketDAOProtocol contract that allows it to:

  • Modify which contracts receive what percentage of RPL inflation distributions - [Etherscan]
  • Spend the pDAO treasury - [Etherscan]

This report was produced by the GovAlpha team, @LongForWisdom, @prose11, and @Patrick_J.

10 Likes
2

First: this is fantastic! :heart: :heart: :heart:

Quibble: I disagree with pDAO having authority over all RP DAOs. The example that comes to mind is that setting membership of the oDAO is reserved for the oDAO.

Next step:

I think this would be a great info RPIP. I’m not sure if I’d recommend Living or not. Living is nice to update, but also requires updating to avoid misleading. Doing it as a “State as of this date” would avoid that issue. I think I lean not-Living if we plan to update quarterly or less.

I love the detail here (even appendices) but think it’s too much too for our docs. Maybe there can be a companion blurb for documentation more along the lines of a high level block diagram and authorities - the distinction between power/authority can be noted and link out to info rpip for full details.

2 Likes
3

Already getting some useful feedback in various places. Thanks!

Feedback Received:

  • pDAO Authority (debatable how over-arching this is)
  • registeredNode powers (it’s an acceptance of an invite to oDAO, not a proposal to join oDAO)
  • SmartNode (Lack of specific info on node software pipeline + powers + authorities around that)
  • Other rocketpool.net domains. (Consider calling out, maybe try to get a full list.)
  • Better reference for pDAO settings. (constructors on the relevant contracts)
  • We missed inflation split pDAO settings. (might be this was intentional, I forget the reason if it was.)

We’ll address the above, and anything else that comes up in the meantime either via direct edits, or replies to the thread. Likely tomorrow.

On the meta-level stuff:

Agree Living implies updates are required. That said, I don’t think this will change too frequently. The one major upcoming change is the pDAO governance moving on-chain. I suspect we’ll still be around then, and if so, we’ll update the document at that time. Future on-going maintenance is for sure an issue, though.

Yeah. I mostly agree. The appendices largely represent information we discovered as part of writing the main document and/or were just a place to better explain some of the references. There is maybe the seed of some useful documentation there as well, but it would need more work / organization to make ready for inclusion anywhere, I think.

I would like to get the list of rocketStorage keys up somewhere, though. I was a little surprised that there wasn’t already an up-to-date list somewhere official.

4

Damn, this is pretty good. I will read in detail and try to find things Val is wrong about.

3 Likes
5

Hello! Sorry for the delay we have updated the document. In addition to a few spelling errors we missed (whoops), we have updated several sections based on feedback here and in Discord. The easiest way to view these is by clicking the edit icon on the top right of the post for a differential.

The team was a bit slit on this point and I think it might call for greater discussion. While we agree that the oDAO has a lot of autonomy, it was our read that pDAO governance has the authority to change directions for the greater organization. To the point on membership, we wondered what would happen if the pDAO put up a vote to modify oDAO membership rules?

From our reading, this vote would be valid and the outcome legitimate. But perhaps we are missing a cultural element here of respecting division between the different DAOs. Maybe @Valdorff or someone else could weigh in on how a proposal to change the governing membership of oDAO would be received.

6

The pDAO has no authority over the oDAO. That’s why the oDAO had to vote for their own charter and the pDAO vote was explicitly pure signaling. The oDAO is not a subdao, it is a separate DAO. This is important - for example in the role as a security council able to defend against a pDAO governance attack.

To your question about pDAO changing membership of the oDAO, that is explicitly addressed in the oDAO charter.

9i: The oDAO SHALL select its membership

9v: The pDAO MAY nominate a new member or suggest the kicking of an existing member via snapshot vote

Note that this doesn’t effect a change. It means the oDAO has to make a decision and post a statement.

I agree with this in almost all cases, because the oDAO explicitly “SHALL NOT actively govern the protocol”. That doesn’t represent authority over the oDAO though.

7

I think perhaps the core of our confusion here is our assumption that only the pDAO can ratify RPIPs.

Like this:

Is under pDAO only, currently.

But what you’re effectively saying is that the oDAO also has (had?) the authority to do this, because they ratified their own charter, which is now marked final, like any other RPIP.

But that seems like a strange and unintentional precedent to set. Is it valid for the oDAO to ratify other RPIPs? I feel like most would agree that no, they’re not supposed to do that.

So, was it the case that the oDAO did have the authority to add RPIPs, up until they passed the charter, which explicitly states they “SHALL NOT actively govern the protocol”?

RPIP-1 and RPIP-4 are explicitly no help here, neither of them state which DAOs (or combination of DAOs) hold the authority to finalize RPIPs.

8

Spoke to @Valdorff some on discord. I eventually came to the conclusion that he’s right, and that the oDAO charter clarifies the role, and was effectively ratified by both the pDAO and the oDAO.

Given it was ratified by both, the prior state of affairs (whatever it actually was or should have been) is replaced by the charter.

I still think there are some fairly large ambiguities still around authorities that have not been well-specified, but in practice it’s more correct to say something along the lines of:

“Authority over the protocol lies with the pDAO, with the exception of that related to the oDAO, which maintains authority over itself.”

We’ll see about updating the document on Monday.

2 Likes
9

very detailed, great job

1 Like
10

Just pushed another edit :slight_smile: Ideally we only have a couple more updates to this form before adapting it to something else, so please chime in if you notice anything is still wrong/missing/subpar.

If you’d like to see if your suggestion made it in, the easiest way is still probably checking the edit history on the top right of the post and looking at the difference checker!

11

Forgive the necromancy, but finally got this into an RPIP Draft. If anyone has time for comments and suggestions as we work toward getting this approved your feedback is welcomed and encouraged!