RPIP-31 - RPL Withdrawal Address

Node Operator Experience
1

This is a discussion thread for RPIP-31.

A proposal to add an additional withdrawal address that is the target for RPL bond withdrawals and RPL reward claims. Essentially there will be two withdrawal addresses: one for ETH; and one for RPL. The RPL withdrawal address will default to the ETH withdrawal address.

8 Likes
2

Great stuff, thanks @kane!

As a node operator, I MUST be able to confirm the RPL withdrawal address from the new target address before it takes effect, to ensure it is the correct address

Could this be an optional feature? Otherwise it adds an extra transaction for automated workflows like Constellation:

tx 1) Deploy node
tx 2) Set RPL withdrawal address to external contract
tx 3) Call external contract to request verification

Would be nice to remove step 3 via e.g. a parameter skipConfirm as true in step 2.

This is also the case for setting the current “primary” withdrawal address and it would be a nice little optimization to add in there, too. I don’t think this is really a security issue since the user would explicitly be requesting to skip confirmation. Another option for the sake of extra safety might be to just allow skipping confirmation on nodes with no minipools.

3

Yep, the intent was that it will be optional just like it currently is with the standard withdrawal address with the confirm argument.

The wording is “I MUST be able to confirm” not “I MUST confirm”. If you think that’s ambiguous, we can update the wording.

4

Makes sense! Thanks for clarifying. I was reading fast and didn’t notice those two little words that make all the difference :slight_smile:

1 Like
5

Any chance this code will work for the update? [Feature] Enable Node's Withdrawal Address to Withdraw RPL by mryamz · Pull Request #282 · rocket-pool/rocketpool · GitHub

It currently passes all existing tests and works within our own integration with RocketPool

6

I believe this is covered under these points or am I mistaken and there is something else you’re requesting?

  • As the controller of the RPL withdrawn from a node, I MUST be able to call RocketNodeStaking.withdrawRPL() to withdraw excess RPL
    • If a node’s RPL withdrawal address is unset, the call MUST come from one of: the node’s primary withdrawal address, or the node’s address
    • If a node’s RPL withdrawal address is set, the call MUST come from the current RPL withdrawal address
1 Like
7

RPIP LGTM. I note that this by the way solves an existing problem with the contracts, even if the new RPL withdrawal address is not used. Namely, after this change, if the RPL withdrawal address is unset, then the primary withdrawal address can withdraw RPL (not just the node account address). (Also any workflows depending on the node account’s ability to withdraw RPL will be thwarted once an RPL withdrawal address is set.)

8

Moving this to sentiment poll.

  • Support moving to vote; I think this proposal is great!
  • Support moving to vote; I think this is “good enough”
  • Undecided; I have a specific question I’d like clarified in the comments below
  • Undecided; other
  • Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
  • Oppose moving to vote; other
0 voters
9

This RPIP has been moved to Review in preparation for finalisation.

Please provide any last community feedback here.

10

Reviewed. Minor oddity to me was that, when RPL address is unset, modifying the allowlist for RPL staking has to come from the node address (and can’t come from the primary withdrawal address). Not a big enough deal that I’m pushing for an edit here.

11

We have just matched the current behaviour in this case. I do agree that it might be useful to be able to set it from the withdrawal address, but also like that it is locked down to the node.

As we haven’t had any strong feedback, in the time the feature has been live, that people want that I would like to leave it as it is.

1 Like
12

I’m voting in favor.

An optional separate withdrawal address improves the protocol’s composability without complicating anything for existing users.

1 Like