Merge pull request #318 from Valdorff/saturn_followup_votes

Saturn followup votes #1

Author: htimsk

RPIPs/RPIP-46.md

@@ -47,7 +47,7 @@ This specification introduces the following pDAO protocol parameters:
 
 1. There SHALL be the following defined revenues:
    1. `node_operator_commission_share + node_operator_commission_share_council_adder`: each node operator receives this percentage of the commission from the borrowed ETH on validators they run. Unlike the remainder of the shares, this is _not_ a protocol revenue (ie, it is not socialized).
-   2. `voter_share -  node_operator_commission_share_council_adder`: each node operator receives a share of revenue based on the vote-eligible RPL staked to their megapool. The overall voter share of revenue is based on the setting, and each node operator receives a proportion of that based on `vote_eligible_RPL_in_their_megapool / total_vote_eligible_RPL_in_megapools`.
+   2. `voter_share -  node_operator_commission_share_council_adder`: each node operator receives a share of revenue based on the vote-eligible RPL staked to their megapool. The overall voter share of revenue is based on the setting, and each node operator receives a proportion of that based on `vote_eligible_RPL_in_their_megapool / total_vote_eligible_RPL_in_megapools`, where `vote_eligible_RPL_in_their_megapool` is defined as `min(1.5*RPL value of megapool bonded_eth, megapool staked rpl)`.
 2. `reth_commission` SHALL be defined as the sum of `node_operator_commission_share` and `voter_share`
 3. `reth_share` SHALL be defined as `100% - reth_commission`
 4. Distributions of revenue from borrowed ETH MUST respect the defined shares

RPIPs/RPIP-49.md

@@ -128,10 +128,15 @@ The tokenomics rework package will likely be split between two protocol upgrades
 * RPL Value Capture based on vote outcome - Probably one of: [RPL Burn](RPIP-45.md) / [RPL Buy & LP](RPIP-50.md) / Increased share to vote-eligible RPL staked in megapools
 
 ## Current Status
-Last Updated: October 4th
+Last Updated: February 16th
 
 Current efforts are primarily focused on:
-- Defining items in the "Still to Ratify" list below
+- Follow-up votes
+
+### Active Follow Up Votes
+- [RPIP-65](RPIP-65.md): a new suggestion to include in Saturn 1
+- [RPIP-66](RPIP-66.md): ratifies several items that are expected to be non-controversial
+- [RPIP-67](RPIP-67.md): a new suggestion to include in Saturn 1
 
 ### Still To Ratify Prior to Saturn 1
 These items are to be considered flexible until ratified explicitly, rather than ratified alongside the tokenomics rework package as a whole.

RPIPs/RPIP-59.md

@@ -32,6 +32,7 @@ This RPIP is part of a set of proposals motivated by a desire to rework Rocket P
 
 ### Deposit Queue Specification
 This specification introduces the following pDAO protocol parameters:
+
 | Name                                   | Type | Initial Value |
 |----------------------------------------|------|---------------|
 | `express_queue_rate`                   |      | `2`           |
@@ -52,10 +53,10 @@ ETH from the deposit pool SHALL be matched with validator deposits from queues a
 
 ### Deposit Mechanics Specification
 This specification introduces the following pDAO protocol parameters:
-| Name                   | Type  | Initial Value |
-|------------------------|-------|---------------|
-| `scrub_period`         | Hours | `12`          |
-| `time_before_dissolve` | Weeks | `2`           |
+
+| Name                   | Type  | Initial Value | Guardrail |
+|------------------------|-------|---------------|-----------|
+| `time_before_dissolve` | Days  | `14`          | `≥2`      |
 
 A node operator MUST take 2 actions to start a validator: `deposit` and `stake`
 
@@ -77,8 +78,6 @@ A node operator MUST take 2 actions to start a validator: `deposit` and `stake`
 - The assignment SHALL remove the validator from the queue
 
 #### `stake` Transaction
-- `stake` SHALL revert unless at least `scrub_period` time has passed since ETH was assigned to the validator, to allow for validating the prestake
-- If the beacon chain stake is invalid, the validator SHALL be scrubbed
 - `stake` SHALL stake the remaining 31 ETH to the beacon chain to make a complete validator
 - If `stake` is not called within `time_before_dissolve` after the ETH was assigned, the validator SHALL be dissolved, returning the unstaked balance to the deposit pool
   - If a validator is dissolved the bonded value SHALL be recoverable. This MAY require further action from the node operator. This MAY temporarily require additional ETH from the node operator.

RPIPs/RPIP-65.md

@@ -0,0 +1,36 @@
+---
+rpip: 65
+title: Prioritize rETH withdrawal buffer
+description: Direct ETH from new mints to the rETH contract to prioritize withdrawal liquidity
+author: Valdorff (@Valdorff)
+discussions-to: 
+status: Draft
+type: Protocol
+category: Core
+created: 2025-02-03
+requires: 
+vote-to:
+vote-date:
+vote-result:
+---
+
+## Abstract
+This RPIP proposes a small change to hopefully be included in Saturn 1.
+
+Currently, there are 2 different flows for ETH in the protocol: ETH from rewards and exits goes to the rETH contract, while ETH from new rETH mints and new minipool deposits goes to the deposit pool (in the latter case after 1 ETH is put on the beacon chain). This RPIP proposes to switch ETH from rETH mints to the former flow, where they go to the rETH contract first. Note that excess ETH can go from the rETH contract to the deposit pool if there is more than a buffer threshold, currently set to 1% of rETH TVL, or 5090 ETH.
+
+## Specification
+- ETH from new rETH mints SHALL go to the rETH contract 
+
+## Rationale
+We currently have a rETH discount. This represents an imbalance between supply and demand where supply is too high relative to demand (or, equivalently, demand is too low relative to supply). In this state, we should (a) strive to avoid creating additional supply and (b) allow rETH burns to better reflect demand.
+
+To measure the impact of the proposed solution, a [simple model](https://dune.com/queries/4660050) was used:
+- From 2024-10-30 to the present, find every rETH mint
+- Track how much ETH went into those, but cap the contribution of any one mint to 5090 ETH (which is the size of the buffer before we overflow into the deposit pool)
+  - Note, we can find the buffer size as 1% of rETH TVL in ETH, which comes from rethTargetCollateral*getEthValue(totalSupply) using the following functions: https://etherscan.io/address/0x89682e5F9bf69C909FC5E21a06495ac35E3671Ab#readContract#F17, https://etherscan.io/address/0xae78736cd615f374d3085123a210448e74fc6393#readContract#F11, and https://etherscan.io/address/0xae78736cd615f374d3085123a210448e74fc6393#readContract#F5 
+
+From 2024-10-30 to 2025-02-07, we found that 17,921 ETH had gone to the deposit pool, which could've instead gone to the rETH contract. Using 1-inch on 2025-02-03, we estimated that there were ~7350 discounted ETH worth of rETH available in on-chain liquidity. 17.9k may have been enough to avoid this depeg, or quite close. Further, voting in favor of something like this also serves to communicate that the pDAO is serious about prioritizing rETH.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

RPIPs/RPIP-66.md

@@ -0,0 +1,52 @@
+---
+rpip: 66
+title: Saturn Follow-up Vote No. 1
+description: Follow-up vote to tie up loose ends in the Saturn specification
+author: Valdorff (@Valdorff)
+discussions-to: 
+status: Draft
+type: Protocol
+category: Core
+created: 2025-02-03
+requires: 46, 59
+vote-to:
+vote-date:
+vote-result:
+tags: tokenomics-2024, tokenomics-content
+---
+
+## Abstract
+This RPIP supports a follow-up vote ratifying plans to tie up loose ends in the Saturn specification. It also provides a platform for community members to raise and discuss any as-yet-unnoticed problems in those plans.
+
+## Specification
+- Megapools SHALL use a 2-transaction deposit strategy
+  - This is already how RPIP-59 is written. This vote will ratify that decision and make no change to the existing text.
+- RPIP-46 SHALL define `vote_eligible_RPL_in_their_megapool` as `min(1.5*RPL value of megapool bonded_eth, megapool staked rpl)`
+  - This results in a small change in text to RPIP-46 (which is currently in the Living state)
+- RPIP-59 SHALL remove scrubbing and `scrub_period` 
+- RPIP-59 SHALL add a minimum value to `time_before_disolve` of 2 days
+
+## Rationale
+
+### 2 Tx deposit strategy
+
+Kane had been the strongest voice towards 3 Tx. In Discord he recently said:
+> knoshua's post [here](https://discord.com/channels/405159462932971535/1215788197842255972/1261344716394463392) removed the weak preference i held for the 3 tx option so i don't have any strong desire to argue in favour of it. i no longer think the benefit of removing all assignments from user deposits outweighs the increased simplicity of the 2 tx approach. and the removal of socialised assignments assuage my main concern in that regard anyway.
+
+
+### vote_eligible_RPL_in_their_megapool
+This tweak is needed to avoid ambiguity. Full discord discussion is [here](https://discord.com/channels/405159462932971535/1215788197842255972/1333479516244410471), with an excerpt provided:
+> Hmm... so RPIP-43 seems unambiguous about vote_eligible_rpl. For your example: min(1.5*(80+4), 150+24) = 126.
+> 
+> The RPIP-46 bit does seem insufficient: vote_eligible_RPL_in_their_megapool doesn't define how to count the specific subsets of RPL.
+
+Thanks to @sckuzzle for finding this issue.
+
+### time_before_dissolve guardrail
+This dev team suggestion prevents setting the parameter so low that Node Operators can't effectively make deposits.
+
+### scrubbing removal
+Per the dev team, there is no need for a scrub process in Saturn due to stake proofs -- as a result, we can simplify this away.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

RPIPs/RPIP-67.md

@@ -0,0 +1,37 @@
+---
+rpip: 67
+title: Permissionless Dissolves
+description: Remove a current oDAO duty by making it permissionless
+author: Valdorff (@Valdorff)
+discussions-to: 
+status: Draft
+type: Protocol
+category: Core
+created: 2025-02-05
+requires: 59
+vote-to:
+vote-date:
+vote-result:
+---
+
+## Abstract
+This RPIP supports a followup vote ratifying plans to tie up loose ends in the Saturn specification. It also provides a platform for community members to raise and discuss any as-yet-unnoticed problems in those plans.
+
+## Specification
+- The "`stake` Transaction" section of RPIP-59 SHALL be replaced with the following:
+```md
+#### `stake` Transaction
+- `stake` SHALL stake the remaining 31 ETH to the beacon chain to make a complete validator
+- After ETH is assigned to a validator, the Node Operator SHALL be able to call a function to dissolve that validator
+- If `stake` has not been called within `time_before_dissolve` after the ETH was assigned to a validator, any user SHALL be able to call a function to dissolve that validator. The user calling this function SHALL receive `dissolve_reward`.
+- When a validator is dissolved:
+  - Unstaked balance SHALL be returned to the deposit pool
+  - The bonded value SHALL be recoverable. This MAY require further action from the node operator. This MAY temporarily require additional ETH from the node operator.
+```
+- The parameter table in the `Deposit Mechanics Specification` section of RPIP-59 SHALL get a new parameter called `dissolve_reward` with an initial value of 0.01 ETH and a guardrail of ≤0.2 ETH
+
+## Rationale
+Per the pDAO charter, we prioritize permissionlessness and decentralization where possible. Per the oDAO charter, the oDAO seeks to minimize its role where possible. This seems to be a case where we can fairly painlessly move from oDAO reliance to relying on any user eventually acting.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).