Hey everyone,
This week the team held a Saturn workshop to break down the work and start planning out milestones.
As we worked through that process, several questions arose that we’d like to open up for discussion. We’ve only begun to consider these issues, so some may be straightforward to resolve, but we’d still like to get the community’s input.
Happy to discuss here or in the tokenomics thread (in Discord). Either way I will repost consensus here for posterity/visibility.
RPIP-30
I think I have raised this before so apologies but it is good to consensus anyway.
The RPIP says:
“Unstaking” RPL SHALL be defined as RPL that is locked within the protocol but not counted by the protocol for usage
Since RPIP-30 applies to legacy RPL staking, does this exclude slashing usage? Slashing is still applicable to legacy minipools in the event of a black swan scenario where they lose more than the 8 ETH they have bonded. While such an occurrence is unlikely, slashing is still part of the protocol for legacy minipools. I don’t see an issue either way, as they can only withdraw down to the withdrawal limit. However, it does allow for the possibility that a node operator could withdraw RPL beyond that limit before any slashing occurs. Either way, I wanted to make sure that we clarify expectations.
Also I assume that Unstaking RPL is not counted for bonding for proposals and challenges? This may mean that they cannot unstake RPL if it is bonded to a proposal or challenge.
RPIP-43
We noticed that in the “claim unclaimed node operator funds” function specification, there is a last ditch attempt at retrieving outstanding debt:
If
debtexists, unclaimed node operator funds SHALL first be used to pay offdebt
Just bear in mind, that at that point, if they do have outstanding debt they could block rETH holders from receiving it, by not calling that function. Obviously in cases they would also be blocking access to their own funds but we raise it because in other places, attention has been given, to ensure the node operator cannot block funds being returned to rETH holders.
RPIP-58: MEV Penalty Guardrail
We are raising early that there may be an implementation limitation to enforcing exactly 50,400 slots - it is likely that we will have to use a close approximation. @knoshua - Kane is happy to discuss the issue further.
RPIP-46: Universal Adjustable Revenue Split
Voter share timing
We are very early in thinking about this, so bear with us, but we see a potential timing issue with voter_share. Essentially all ETH rewards (consensus and non-smoothing pool EL rewards) go to the megapool contract, which is then divided up into the shares on node operator distribution. This includes the voter_share which will most likely will be sent to a pool contract on distribution and then dispersed by the reward treegen process. The voter share ETH will flow at the timing will of node operators not a regular cadence.
Allow list controller - commission controller address
node_operator_commission_share,node_operator_commission_share_council_adder, andvoter_shareSHALL be updateable by any address in theallowlisted_controllersarray
We noticed that there were no specific safeguards on this power except that reth_commission <= 100%. For the pDAO, that may be ok but for a single address or committee that is a great deal of power. Do we want to apply safe guards to this? Even if the pDAO trust that address it is more unchecked power than we have afforded other roles in Saturn.
RPIP-59: Deposit Mechanics
Scrub period
In the megapool RPIP, I raised that on staking it is likely we will use a state proof that negates the need for a scrub period. Unfortunately, I did not make the same comment on the deposit mechanic RPIP. Essentially, it is likely the scrub period will be removed and the oDAO scrub process will not be necessary.
Dissolving is still necessary though.
Deposit actions required
The RPIP says:
A node operator MUST take 2 actions to start a validator:
depositandstake
This is probably a small nitpick but although I expect this to be true most of the time, it isn’t technically true all the time. It would be best to say that up to 3 actions are necessary but assignment maybe done by a third-party (if GMC funds it).
We will continue to break down the work and I suspect this will not be the only post I make but the team and I are excited to be working through and clarifying the future with the community.