RPIP-42 The protocol SHALL be able to penalize stake at the node level I think this needs to be more specific. As is, this puts the burden of concrete implementation on the team/kane. If there is a node operator queue, base validators SHALL be given priority over satellite validators Do we have to worry about people being stuck in queue indefinitely as we saw with full minipools in the past? This is a sybil incentive. Why are base validators only allowed < base_num ? Similar logic to RPIP-28: Deposits Under the Minimum applies here, but with node level penalties we have increased interest to not create sock puppets. If we were to allow more base validators, do we want to enable base -> satelite migration?

Fraud Proofs have been suggested as a potential alternative for multiple oDAO duties. This section explores the security of optimistic fraud proofs and how it relates to the challenge period and other variables. The challenge period aims to protect against censorship attacks. The first type of censorship to consider is on the block builder level: An attacker can attempt to get builders to exclude the fraud proof transaction from their blocks. If they succeed for every block in the challenge period the fraud goes unreported. One could imagine an attacker using MEV boost relays for something like this, but then a single validator building a block locally during the challenge window could thwart the attack. The second type of censorship requires collusion with a majority of all validators. These validators would not only exclude the fraud proof, but would also fork out blocks from other validators that include it. This attack would require a high level of coordination since forking requires direct intervention of participants, but would be resilient against individuals building locally. Besides the high level of difficulty of both attacks, Ethereum is inherently censorship resilient: censorship creates a DoS vector that could cost validators priority fees while it lasts. It is also possible to detect forking censorship and the challenge period could increase when it is likely. Nevertheless, I believe it is possible to make censorship attacks crypto-economically not viable. These are the variables to consider in this context: The cost to exclude a transaction scales with the reward a challenger would receive for a successful fraud proof, because it determines the priority fee a challenger can pay for inclusion. The payment for censorship needs to make up for that lost reward. The cost also scales with the length of the challenge period or the number of blocks. Under block level censorship, the attacker needs to pay the reward every block, under forking censorship only for 51% of blocks.

This section looks at the potential of proving MEV stealing with the help of the beacon block root proposed in EIP4788. A relatively straight-forward approach would be to use merkle proofs against the beacon root to objectively determine when a node operator has stolen MEV according to some rule set and apply a penalty accordingly. However there are some challenges around what data the beacon root gives us access to and some limitations for what rules can be verified. State Proofs The beacon block root would give access to: The proposer_index contained in the BeaconBlock itself validators in BeaconState linking indices to pubkey and withdrawal_credentials fee_recipient, transactions, and state_root contained in the ExecutionPayload in BeaconBlockBody So unfortunately, a pure state proof approach doesn't appear to be possible with the beacon root alone. For example it would be possible to prove that:

Instead of the current challenge period that relies on trusted oracles to scrub, this design allows fraud proofs during a challenge period to prevent the withdrawal credential exploit described in [SCRUB CHECK -WITH CRED] in a trustless manner. Design The general flow is similar to what we have now: The node operator initiates a first deposit of 1 ETH to the beacon chain. During a scrub period, a fraud proof can be submitted. a) If no fraud proof is submitted, the remaining 31 ETH can be deposited. b) If a valid fraud proof is submitted, the minipool is scrubbed: ETH is returned to liquid stakers and RPL is slashed and awarded to the person providing the proof.

Immunefi Bug Bounty Impacts in scope look reasonable. Pays out $100k - $30k for critical findings, $15k for high, and $5k for medium. Payout are in their native token and vesting: All the rewards given will have a vesting schedule of 2 months, managed by a smart contract. This seems pretty annoying for whitehats and benefit to the protocol is unclear to me. Multisig There is a 5/8 multisig consisting of 4 team members and 4 people from the ecosystem (Byte Masons, Sphere Finance, Deus DAO, Equalizer). It appears that the entire team and 3 of 4 ecosystem members are anon. I could only find information about Blake Hooper, founder of Equalizer.

This bug report was produced by @rileyholterhus and knoshua, submitted via Immunefi and addressed in commit 63f718e and commit f657846 before the Atlas upgrade. Summary If a group of attackers directly transfers their ETH to a minipool, they can cause a node operator to lose up to 16 ETH. In this exploit, rETH holders receive both the transferred funds and the 16 ETH the node operator loses, so there is an incentive for rETH holders to collude for a profit. This collusion can occur in a trustless manner, which increases the likelihood of it happening. The attackers will profit by holding 33% of the rETH supply, and they can use unclaimed partial withdrawals to offset the exploit cost (slightly lowering this percentage). There also exist theoretical ways to make the exploit more efficient/profitable . We believe that a few relatively simple changes can make this attack impossible. Main Idea In Rocket Pool's upcoming Atlas upgrade, the distributeBalance function has logic that depends on the minipool's balance (which we will refer to as $b$). If $b \geq 8$ ETH, the minipool assumes that the node operator (NO) has completed a full withdrawal from the beacon chain. Since the NO only provides 8 of the 32 validator ETH, $b < 24$ ETH is considered a net loss of funds, resulting in a slashing of the NO's RPL collateral. This logic creates two potential attack vectors for malicious actors seeking to exploit the accounting system: By frontrunning a victim NO's distributeBalance call with a manual transfer, an attacker can cause the NO to inadvertently trigger a slashing of their RPL collateral. This is possible if the NO uses the public mempool for their transaction (which most Ethereum users do). By manually transferring ETH and calling beginUserDistribute themselves, an attacker can trigger an RPL slashing after the user distribution wait time has passed (currently set to 14 days). This method does not work if the NO completes a full withdrawal during this period, but there are realistic scenarios (see below) where the user distribution wait time is shorter than the validator full-withdrawal wait time. This is especially true if Atlas is deployed prior to the Shanghai/Capella hard-fork.

Auction Settings [TODO] Deposit Settings deposit.enabled Controls whether or not the deposit pools accepts deposits (allows minting of new rETH). deposit.assign.enabled deposit.minimum deposit.pool.maximum

Orignal design at https://drive.google.com/file/d/1h8qqNlTDR_4et-3BZrGxE8r1-1WLgAzb/view Thanks to Valdorff for providing early feedback on this document. Modifications The role of the Supernode smart contract is split into three parts: NOA Vault, NOA Node and Node Delegate Multiple NOA Node instances can be used in parallel. NOA Vault can not be upgraded and is responsible for holding value in the system as well as splitting rewards. It is set as the withdrawal address for each NOA Node instance. Each NOA Node instance can be upgraded through the Node Delegate. NOA Governance is responsible for deploying and setting Node Delegate.

What can the Guardian do in Bootstrap Mode? Explicit: RocketDAONodeTrusted.sol can add oDAO members can change oDAO settings can upgrade existing rocket pool contracts (excluding non-upgradeable contracts) and add new contracts to rocket pool can disable bootstrap mode Explicit: RocketDAOProtocol.sol

A minipool is funded with 16 ETH from the node operator and 16 ETH from rETH stakers. Upon withdrawal any incurred losses are taken out of the node operator's share first. If a minipool ends up with a balance below 16 ETH, an appropriate part of the node operators RPL collateral is supposed to be sold to make up for the shortfall and protect rETH stakers. This report outlines how a flawed auction mechanism can be exploited to enrich the exploiter and cause the loss of rETH staker funds in this scenario. When a slashing of RPL happens the amount of RPL tokens slashed is based on the shortfall of the minipool balance compared to the user deposit balance (see here and here). The slashed tokens are assigned to the RocketAuctionManager by slashRPL(). Whenever it has at least 1 ETH worth of RPL anyone can call createLot() to start an auction. According to the settings, the price starts at 100% of the RPL price and decreases every block until it reaches 50% of the starting price (see getLotPriceAtBlock()).After an auction was started anyone can call placeBid()

Proposal On Ethereum, adapt the ankrETH Curve Pool to rETH and deploy it. Then start a proposal for the Curve DAO to add a gauge. Research how to get a rETH price oracle on L2s to start these Curve pools on Arbitrum and potentially Optimism. I think one way would be to partially copy the protocol smart contracts so that oDAO members can be registered, submit balance updates and reach consensus on the rate. Why focus on LPs now Liquidity at the fair rate is fundamental to the value proposition of rETH. Based on the stETH Curve Pool (see also stETH Deposits) we should expect supply/demand to fluctuate more than the native Rocket Pool deposit pool can handle and that we will need liquidity on secondary markets. The gas cost to mint rETH represents a barrier to entry for smaller and medium sized stakers. A effecient liquidity pool can enable cheaper swaps both on Layer 1 and Layer 2s.