Retry catch up spring2024-tokenomics before draft8 merge to main

RPIPs/RPIP-49.md

@@ -29,6 +29,14 @@ The following explainers are being maintained by the community to help make the
 
 ## Contents
 
+### [RPIP-42: Bond curves](RPIP-42.md)
+
+The changes to bond curves allow Node Operators to provide smaller ETH bonds while maintaining the security of the Rocket Pool protocol. 
+* This gives Node Operators the option of dramatically increasing their capital efficiency.
+* This allows the Rocket Pool Protocol to support a greater amount of rETH. 
+
+For bonds to be lowered securely for the protocol, an initial set of bonds for a node must be larger than the minimum bond. 
+
 ### [RPIP-43: Megapools](RPIP-43.md)
 
 A Megapool is a single contract that can be used as an Ethereum withdrawal address for multiple validators.
@@ -38,13 +46,13 @@ A Megapool is a single contract that can be used as an Ethereum withdrawal addre
 
 Additionally, Megapools are required to facilitate the bond curve changes described in RPIP-42.
 
-### [RPIP-42: Bond curves](RPIP-42.md)
+### [RPIP-44: Forced exits](RPIP-44.md)
 
-The changes to bond curves allow Node Operators to provide smaller ETH bonds while maintaining the security of the Rocket Pool protocol. 
-* This gives Node Operators the option of dramatically increasing their capital efficiency.
-* This allows the Rocket Pool Protocol to support a greater amount of rETH. 
+This change, planned for Saturn 2, allows the Rocket Pool protocol to force-exit Node Operators under certain circumstances. It relies on the adoption of [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) by the Ethereum protocol. 
+* This allows Node Operators to exit their validators easily.
+* This allows the Rocket Pool protocol to exit malicious validators.
 
-For bonds to be lowered securely for the protocol, an initial set of bonds for a node must be larger than the minimum bond. 
+The ability to force-exit misbehaving validators is a requirement for [RPIP-44](RPIP-44.md).
 
 ### [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md)
 
@@ -58,23 +66,6 @@ Aspects of the split are managed by the pDAO, the security council, and automati
 
 This RPIP also includes the reduction of RPL issuance from 5% to 1.5%, as RPL rewards to Node Operators have been replaced by UARS.
 
-### RPL Value Capture
-
-Some form of value capture method will be included in the tokenomics rework package. Three options are being actively debated:
-* [RPL Burn](RPIP-45.md) - Use the surplus share to buy and burn RPL.
-* [RPL Buy & LP](RPIP-50.md) - Use the surplus share to buy RPL and deposit it in a liquidity pool. 
-* Direct the surplus share to vote-eligible Node Operators, proportional to their share of vote-eligible RPL.
-
-For Saturn 1, the share will be directed based on vote-eligible RPL staked in megapools. There will be a vote prior to Saturn 1 going live to determine the preferred strategy starting at Saturn 2.
-
-### [RPIP-44: Forced exits](RPIP-44.md)
-
-This change, planned for Saturn 2, allows the Rocket Pool protocol to force-exit Node Operators under certain circumstances. It relies on the adoption of [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) by the Ethereum protocol. 
-* This allows Node Operators to exit their validators easily.
-* This allows the Rocket Pool protocol to exit malicious validators.
-
-The ability to force-exit misbehaving validators is a requirement for [RPIP-44](RPIP-44.md).
-
 ### [RPIP-47: Forced delegate upgrades](RPIP-47.md)
 
 This change allows the Rocket Pool protocol to force-upgrade Node Operators minipool delegate contracts after a grace period has expired. 
@@ -91,41 +82,47 @@ Here we describe the mechanics of Node Operator deposits and validator creation,
 ### [RPIP-60: Protocol Upgrade Guardrails](RPIP-60.md)
 
 This RPIP introduces a delay after protocol upgrades have been confirmed but prior to them coming into effect, and allows the security council to veto the upgrade during that delay. The veto is justified if the upgrade meets one of the following criteria:
-* It was subject to vote manipulation
-* It is a malicious action
-* It causes clear damage to the Rocket Pool project
+* It was subject to vote manipulation.
+* It is a malicious action.
+* It causes clear damage to the Rocket Pool project.
+
+### RPL Value Capture
+
+Some form of value capture method will be included in the tokenomics rework package. Three options are being actively debated:
+* [RPL Burn](RPIP-45.md) - Use the surplus share to buy and burn RPL.
+* [RPL Buy & LP](RPIP-50.md) - Use the surplus share to buy RPL and deposit it in a liquidity pool. 
+* Direct the surplus share to vote-eligible Node Operators, proportional to their share of vote-eligible RP.
+
+For Saturn 1, the share will be directed based on vote-eligible RPL staked in megapools. There will be a vote prior to Saturn 1 going live to determine the preferred strategy starting at Saturn 2.
+
 
 ## Deployment Plan
 
 The tokenomics rework package will likely be split between two protocol upgrades: Saturn 1 and Saturn 2.
 
 ### Saturn 1
-
-* [RPIP-43: Megapools](RPIP-43.md)
-  * Including ETH-only validators.
-* [RPIP-42: Bond curves](RPIP-42.md)
-  * Framework
-  * 4ETH minimum bond
-* [RPIP-59: Deposit Mechanics](RPIP-59.md)
-  * Standard and express queues.
-* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md)
-  * Splits between rETH, node operators, and vote-eligible staked RPL staked in megapools
-  * RPL issuance rewards no longer have a minimum stake required
-* RPL Value Capture - Increased share to voting Node Operators.
+* [RPIP-42: Bond curves](RPIP-42.md) - Partial Inclusion
+  * 4 ETH bond per validator
+* [RPIP-43: Megapools](RPIP-43.md) (includes ETH-only validators)
+* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md) - Partial Inclusion
+  * UARS introduced with no_share, voter_share, and reth_commission
+  * RPL issuance rewards extended to all staked RPL (no minimum staking requirement)
 * [RPIP-47: Forced delegate upgrades](RPIP-47.md)
+* [RPIP-59: Deposit Mechanics](RPIP-59.md) (includes express queue)
 * [RPIP-60: Protocol Upgrade Guardrails](RPIP-60.md)
+* RPL Value Capture - Increased share to vote-eligible RPL staked in megapools
 
 ### Saturn 2
 
-* [RPIP-42: Bond curves](RPIP-42.md)
-  * 1.5ETH minimum bond. 
+* [RPIP-42: Bond curves](RPIP-42.md) - Remainder
+  * 1.5 ETH minimum bond
 * [RPIP-44: Forced exits](RPIP-44.md)
 * [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md)
   * Split may add a new share for all RPL, depending on outcome of Revenue Share vote
   * May add in a semi-automated system of controlling voter_share, depending on outcome of Revenue Share vote
   * RPL inflation reduced to 1.5%  (from 5%)
-  * No more RPL issuance rewards
-* RPL Value Capture based on vote outcome - [RPL Burn](RPIP-45.md) / [RPL Buy & LP](RPIP-50.md) / Increased share to vote-eligible RPL staked in megapools
+  * RPL issuance rewards to node operators end
+* 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: July 16th

RPIPs/RPIP-55.md

@@ -20,23 +20,18 @@ The intention of this Living Informational RPIP is to collate the release-releva
 
 ## Estimated Included RPIPs
 
-* [RPIP-30: RPL Staking Rework](RPIP-30.md) - Partial Inclusion
-  * Two-step RPL withdrawal process.
-
-
-### Tokenomics Rework Content
-The tokenomics upgrade has not yet been ratified by the Rocket Pool pDAO.
-* [RPIP-43: Megapools](RPIP-43.md) - Partial Inclusion
-  * Including ETH-only validators.
-* [RPIP-42: Bond curves](RPIP-42.md) - Partial Inclusion
-  * Framework
-  * 4ETH minimum bond
-* [RPIP-59: Deposit Mechanics](RPIP-59.md)
-  * Standard and express queues.
-* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md) - Partial Inclusion
-  * All but heuristic adjustments.
-* RPL Value Capture - One of: [RPIP-45: RPL Burn](RPIP-45.md) / [RPIP-50: RPL Buy & LP](RPIP-50.md) / Increased share to voting Node Operators.
+* [RPIP-30: RPL Staking Rework](RPIP-30.md) - Remainder
+* [RPIP-57: Node Distributor User Fund Unbundling](RPIP-57.md) - Not yet ratified.
+* [RPIP-58: MEV Penalty Guardrail](RPIP-58.md) - Not yet ratified.
+* [RPIP-61: Balance Submission Guardrail](RPIP-61.md) - Not yet ratified.
+
+### RPIP-49 Tokenomics Rework Content
+The RPIP-49 tokenomics rework has not yet been ratified by the Rocket Pool pDAO.
+* [RPIP-42: Bond curves](RPIP-42.md) - Partial
+* [RPIP-43: Megapools](RPIP-43.md)
+* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md) - Partial
 * [RPIP-47: Forced delegate upgrades](RPIP-47.md)
+* [RPIP-59: Deposit Mechanics](RPIP-59.md)
 * [RPIP-60: Protocol Upgrade Guardrails](RPIP-60.md)
 
 ## Key Links 

RPIPs/RPIP-56.md

@@ -20,13 +20,12 @@ The intention of this Living Informational RPIP is to collate the release-releva
 
 ## Estimated Included RPIPs
 
-### Tokenomics Rework Content
-The tokenomics upgrade has not yet been ratified by the Rocket Pool pDAO.
-* [RPIP-42: Bond curves](RPIP-42.md) - Partial Inclusion
-  * 1.5ETH minimum bond. 
+### RPIP-49 Tokenomics Rework Content
+The RPIP-49 tokenomics rework has not yet been ratified by the Rocket Pool pDAO.
+* [RPIP-42: Bond curves](RPIP-42.md) - Remainder
 * [RPIP-44: Forced exits](RPIP-44.md)
-* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md) - Partial Inclusion
-  * Heuristic adjustments.
+* [RPIP-46: Universal Adjustable Revenue Split](RPIP-46.md) - Remainder
+* RPL Value Capture based on vote outcome - Probably one of: [RPIP-45: RPL Burn](RPIP-45.md) / [RPIP-50: RPL Buy & LP](RPIP-50.md) / Increased share to voting Node Operators
 
 ## Key Links 
 TBC - Include Audits, Code Repositories, Release Blog Posts, Upgrade contract, etc once they are posted.

RPIPs/RPIP-57.md

@@ -4,7 +4,7 @@ title: Node Distributor User Fund Unbundling
 description: Guarantee that anyone can distribute ETH in Node Distributors.
 author: knoshua (@knoshua)
 discussions-to: https://dao.rocketpool.net/t/rpip-node-distributor-user-fund-unbundling/3008
-status: Review
+status: Final
 type: Protocol
 category: Core
 created: 2024-05-20
@@ -15,7 +15,7 @@ created: 2024-05-20
 A proposal to guarantee that anyone can distribute ETH in Node Distributors (where execution layer rewards for people not in the smoothing pool go). If a withdrawal address is not able to accept the share belonging to the node operator, the value is stored in their balance and only the share belonging to rETH is sent. The node operator can then claim an outstanding balance at a later time.
 
 ## Motivation
-Currently, anyone can call distribution on a Node Distributor. It attempts to send the node operator's share to their withdrawal address and if that fails the entire distribution including sending of rETH share fails. For example, a node operator could set their withdrawal address to a smart contract that doesn't accept ETH or only accepts it when they are personally initiating the distribution. A profit motive for node operators to do this exists when rETH is traded at a discount. Ensuring that everyone can distribute would help support the rETH peg through better arbitrage and better match expectation that anyone can distribute. 
+Currently, anyone can call distribution on a Node Distributor. It attempts to send the node operator's share to their withdrawal address, and if that fails, the entire distribution, including the sending of rETH share, fails. For example, a node operator could set their withdrawal address to a smart contract that doesn't accept ETH or only accepts it when they are personally initiating the distribution. A profit motive for node operators to do this exists when rETH is traded at a discount. Ensuring that everyone can distribute would help support the rETH peg through better arbitrage and better match expectation that anyone can distribute. 
 
 
 ## Specification

RPIPs/RPIP-58.md

@@ -4,7 +4,7 @@ title: MEV Penalty Guardrail
 description: This proposal introduces a limit on the total number of MEV penalties that the oDAO can apply to minipools in one week.
 author: knoshua (@knoshua)
 discussions-to: https://dao.rocketpool.net/t/rpip-mev-penalty-guardrail/3009
-status: Review
+status: Final
 type: Protocol 
 category: Core
 created: 2024-05-22
@@ -15,7 +15,7 @@ created: 2024-05-22
 This proposal introduces a global limit on the total number of MEV penalties that the oDAO can apply to minipools in one week. The limit is a protocol parameter controlled by the pDAO. The pDAO can't set it lower than a minimum value. The parameter can't be changed by the Security Council.
 
 ## Motivation
-Currently, the oDAO can apply an unlimited number of penalties without any delay. This exposes node operators: In the worst case, a compromised oDAO can penalize 100% of the ETH that node operators have in minipools. For legitimate use of the penalty system, this is overpowered. The number of proposals in a time interval are limited and therefore also the number of stealing incidents in a time interval are limited. This proposal aims to reduce oDAO trust by introducing a sensible limit that doesn't interfere with legitimate use of the penalty system and removes unnecessary risk from illegitimate use.
+Currently, the oDAO can apply an unlimited number of penalties without any delay. This exposes node operators: In the worst case, a compromised oDAO can penalize 100% of the ETH that node operators have in minipools. For legitimate use of the penalty system, this is overpowered. The number of proposals in a time interval is limited, and therefore the number of stealing incidents in a time interval is also limited. This proposal aims to reduce oDAO trust by introducing a sensible limit that doesn't interfere with legitimate use of the penalty system and removes unnecessary risk from illegitimate use.
 
 ## Specification
 
@@ -45,9 +45,9 @@ There are no backwards compatibility concerns with this proposal.
 ## Security Considerations
 Since the oDAO is also in control of contract upgrades, a compromised oDAO has the power to remove the guardrail introduced here. But contract upgrades are subject to a 7 day delay, which would give node operators an opportunity to react.
 
-This RPIP assumes that the oDAO is applying penalties shortly after they occur. Retroactively applying penalties for a long time period might become limited. However, the retroactive approach is already problematic, since there is no guarantee that MEV stealers will stick around to be penalized.
+This RPIP assumes that the oDAO is applying penalties shortly after they occur. Retroactively applying penalties covering a long time period might become bottlenecked. However, the retroactive approach is already problematic, because there is no guarantee that MEV thieves will stick around to be penalized.
 
-This RPIP assumes that the oDAO applies one penalty per infraction. If for example we wanted to get rid of the two free initial strikes per minipool, this should best be done through contract changes and not by applying multiple penalties per infraction. 
+This RPIP assumes that the oDAO applies one penalty per infraction. If, for example, we wanted to get rid of the two free initial strikes per minipool, this should best be done through contract changes and not by applying multiple penalties per infraction. 
 
 
 ## Copyright

RPIPs/RPIP-61.md

@@ -4,15 +4,15 @@ title: Balance Submission Guardrail
 description: This proposal limits how much the oDAO can change the rETH exhange rate.
 author: knoshua (@knoshua)
 discussions-to: https://dao.rocketpool.net/t/rpip-balance-submission-guardrail/3010
-status: Review
+status: Final
 type: Protocol
 category: Core
 created: 2024-05-27
 
 ---
 
 ## Abstract
-This proposal limits how much the oDAO can change the rETH exhange rate (used for minting or burning rETH against ETH) in a single update. The limit is a protocol parameter controlled by the pDAO. The pDAO can't set it lower than a minimum value. The parameter can't be changed by the Security Council.
+This proposal limits how much the oDAO can change the rETH exchange rate (used for minting or burning rETH against ETH) in a single update. The limit is a protocol parameter controlled by the pDAO. The pDAO can't set it lower than a minimum value. The parameter can't be changed by the Security Council.
 This proposal also limits how frequently updates can happen, using an existing protocol parameter that the pDAO controls. 
 
 ## Motivation
@@ -34,7 +34,7 @@ Currently, the oDAO can change rETH exchange rate arbitrarily within one block.
 ## Rationale
 The pDAO can change the limit to a sufficiently high value to effectively disable this guardrail. The minimum guarantees that normal operation of the protocol can not be interfered with through a parameter change.
 
-Limiting the change per update alone is not enough, since multiple updates in one block would be able to undermine it severely. Therefore update frequency is also limited.
+Limiting the change per update alone is not enough, since multiple updates in one block would be able to undermine it severely. Therefore, update frequency is also limited.
 
 A minimum for the Maximum rETH Delta parameter is necessary to make sure that regular updates are possible. I chose 1% as a round number that is large enough to allow for that, even with some volatility in updates because of big MEV blocks, and at the same time significantly reduce impact in the worst case scenario.
 
@@ -46,7 +46,7 @@ There are no backwards compatibility concerns with this proposal.
 ## Security Considerations
 Since the oDAO is also in control of contract upgrades, a compromised oDAO has the power to remove the guardrail introduced here. But contract upgrades are subject to a 7 day delay, which would give rETH holders an opportunity to react.
 
-In case of many slashings on the beacon chain that lead to correlation penalties, it is possible that an update of more than 2 percent would be appropriate. Note that there would be ~18 days delay between initial slashing and application of the correlation penalty. With RPIP-33, the pDAO could change the Maximum rETH Delta parameter within 21 days.
+In the case where many slashings on the beacon chain that lead to correlation penalties, it is possible that an update of more than 2 percent would be appropriate. Note that there would be ~18 days delay between initial slashing and application of the correlation penalty. With [RPIP-33](./RPIP-33.md), the pDAO could change the Maximum rETH Delta parameter within 21 days.
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/.)