Verifying 1.4 Contract Upgrade
By: Valdorff 11 Feb
11 Feb
Hi All,
As I’ve done other times, I wanted to take a look and publish it for folks that aren’t going to dig in themselves, or folks that want to follow along.
I used the team’s verification tool, after a quick skim into its functionality. Happy checkmarks across the board.
I then made specific changes to source to confirm that those specific changes were found by the tool.
**Note:** By default, the env example uses Hoodi network / rocketstorage. Set those to:
- Network: mainnet
- RocketStorage: 0x1d8f8f00cfa6758d7bE78336684788Fb0ee0Fa46
Make sure your RPC endpoint matches your chosen chain.
The 3 audits were:
- Cantina (56ea8976a5ccafb553b0eb613bd62fd19a8d5aa8)
- Bailsec (02621fa4f88af44b7e0475840b222b9aaba4a6dd)
- Sigma Prime (range from comparing 6f07f2a..269782f, starting from the last Sigma Prime audit for the Houston hotfix)
Increase Deposit Pool Max - Sentiment Poll
By: Dr Doofus Jan 8th
Increase Deposit Pool Maximum
Status: Sentiment Poll
Related: RPIP-33, RPIP-74
Discord Discussion: #increase DP pre-Saturn 1
RPIP Draft: RPIP-78
This post is to gauge pDAO support for increasing the Deposit Pool maximum from approximately 18,000 ETH to 6,000,000 ETH (nearly 20% of staked ETH for signaling purposes but effectively infinite for our purposes).
If sentiment is favorable, this would proceed to an on-chain vote in accordance with RPIP-33.
Parameter: deposit.pool.maximum (uint256)
Current value: 18000000000000000000000
Proposed value: 6000000000000000000000000
No other protocol parameters or behaviors are affected.
The proposed increase is intended to support upcoming protocol activity and reduce operational risk:
With the planned Saturn 1 launch and introduction of megapools (targeted for February 9), larger inflows are possible and in fact, have already been arriving. Increasing the Deposit Pool cap allows ETH to accumulate in advance, supporting smoother megapool onboarding.
The Deposit Pool could potentially cross the 80% utilization threshold defined in RPIP-74, which would trigger re-enabling of the minipool queue. This was fine when launch was months down the road, but is not needed weeks before launch.
If the Deposit Pool reaches its maximum capacity while no minipools are available to absorb additional ETH, the protocol may be forced to reject new deposits. This could discourage institutional or large-scale participants and negatively impact Rocket Pool’s reputation at a critical growth phase.
This is a capacity-only change — it simply allows more ETH if rETH demand exists.
The change is fully reversible via future governance if conditions change.
The maximum for the Deposit Pool primarily exists to limit drag on rETH yield. A large amount of ETH in the pool means a lot of rETH has been minted that gets rewards but the corresponding ETH is not matched to a validator that is earning rewards. Thus yield is reduced.
This is contrary to the protocol’s usual goals, however, in this case:
- The build up is temporary and potentially advantageous to Saturn 1 and megapool launch
- Capital efficiency is greater for megapools, so much so, that we do not expect to be Node Operator limited for a very long time
Having said that, the core team and pDAO must monitor the yield and the Deposit Pool and can decrease the maximum if the situation requires it.
(Use the title link above to participate in the poll)
Require Minipools to Use Latest Delegate
By:
!!Alert!!
Read this and ask questions if you don’t understand, here or in the Discord. This could be a contentious proposition and should be thoroughly vetted before proceeding to a sentiment poll.
Proposal: For a future Smartnode update, force minipools to use the latest delegate smart contract. The primary driver of this is to eventually, with community support and vote, allow forced exits of underperforming minipools.
**!!Alert!!**
**Proposal:** For a future Smartnode update, force minipools to use the latest delegate smart contract. The primary driver of this is to eventually, with community support and vote, allow forced exits of underperforming minipools.
A meaningful number of minipools are underperforming, dragging down rETH yield and thus potentially harming demand. This could contribute to the minipool queue not clearing in a timely manner, which threatens our ability to transition cleanly to the Saturn 1 architecture (megapools, RPL fee switch, alternative protocol funding schemes, etc.). Even if and when the queue eventually clears, this drag on yield could continue to slow rETH adoption and exacerbate the above mentioned issues.
A proposal is in development that would allow the Smartnode to force node operators to use the latest protocol deployed delegate smart contract. This effect would only be relevant after updating to that version of Smartnode. Currently, users can choose to use the latest delegate or remain on a previous delegate of their choosing, thus avoiding certain smart contract changes they do not want to partake in.
This proposal is a philosophical change in how Rocket Pool operates. It no longer allows node operators to avoid contract updates they do not want once they upgrade to this Smartnode version.
One likely consequence of this change will be to allow forced exits on underperforming minipools. This would be a separate vote or roadmap item, however.
This post:
Summarizes the problem and why use-latest-delegate matters
Outlines the proposed change: forcing use-latest-delegate = yes
Presents a governance path to proceed to a formal proposal / snapshot
(Continued at https://dao.rocketpool.net)
