Merge pull request #269 from Valdorff/finalize_57_58_61

Finalize 57 58 61

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/.)