RPIP-47: Enable Forced Delegate Upgrades Source

Allows protocol governance to force upgrade Node Operators after a Rocket Pool protocol upgrade takes place, and a grace period has expired.
⚠️ This RPIP is not recommended for general use or implementation as it is likely to change.
RPIP47
AuthorValdorff
StatusDraft
TypeProtocol
CategoryCore
Requires 43
Created2024-03-08
DiscussionLink

RPIP-47: Enable Forced Delegate Upgrades Source

Allows protocol governance to force upgrade Node Operators after a Rocket Pool protocol upgrade takes place, and a grace period has expired.

Abstract

Currently, Node Operators can choose to upgrade (or not) for their minipool delegate (the contract at the Ethereum withdrawal address that governs how funds are disbursed, among other things). This (a) means the protocol can only effect change in ways that are in the interest of individual NOs, and (b) makes it more challenging to design the protocol as it must remain backwards compatible with every past minipool delegate.

This proposal suggests limiting that upgrade choice in the future. Users will be able to opt in to upgrade or use an “old” delegate for a defined period after a newer version. However, once the defined period has passed, they will no longer use the old delegate. To ensure timely availability of protocol funds, after the defined period, anyone may change the megapool’s delegate to a minimal ‘recovery delegate’ that is only capable of exiting validators and distributing funds.

Specification

Megapool delegates

  • Megapool delegate contracts SHALL have an expiration block (ie, execution layer block)
  • When a new megapool delegate is released, the contract upgrade SHALL include:
    • Setting the new megapool delegate’s expiration block to “no expiration”
    • Setting the previous megapool delegate’s expiration block to occur delegate_upgrade_buffer after the upgrade
  • A node operator SHALL be able to upgrade their active megapool delegate to the latest megapool delegate at any time (including after the active megapool delegate’s expiration block)
  • After the active megapool delegate’s expiration block:
    • The active megapool delegate SHALL NOT be usable by the node operator
    • The node operator SHALL NOT be able to claim any rewards
  • The initial setting of delegate_upgrade_buffer SHALL be 4 months.

Megapool recovery delegate

  • There SHALL be a single megapool recovery delegate contract that is used by all megapools in the protocol
  • The megapool recovery delegate for a megapool SHALL NOT be usable by anyone if the current block is less than or equal to the active megapool delegate’s expiration block
  • The megapool recovery delegate for a megapool SHALL be usable by any address if the current block is greater than the active megapool delegate’s expiration block
  • The megapool recovery delegate SHALL have the following capabilities:
    • Force exiting ALL validators under the megapool
      • In the Saturn 1 release, this MAY be a non-functional stub
    • Removal of any pending validators from the Rocket Pool queue
    • Processing of voluntary exit proofs
    • Collection of any penalties or deficits
    • Final distribution of rewards and capital
  • The megapool recovery delegate SHOULD be updated only rarely, and only to support changes to the Ethereum execution layer exit process, or major changes in the Rocket Pool protocol. Simultaneous upgrades to both the megapool recovery delegate and the latest megapool delegate SHOULD be avoided if possible.

Copyright and related rights waived via CC0.

Citation

Valdorff, "RPIP-47: Enable Forced Delegate Upgrades [DRAFT]," Rocket Pool Improvement Proposals, no. 47, March 2024. [Online serial]. Available: https://rpips.rocketpool.net/RPIPs/rpip-47.