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
Overview
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.
Proposed Change
Parameter: deposit.pool.maximum (uint256)
Current value: 18000000000000000000000
Proposed value: 6000000000000000000000000
No other protocol parameters or behaviors are affected.
Motivation
The proposed increase is intended to support upcoming protocol activity and reduce operational risk:
Saturn Readiness
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.
Avoiding RPIP-74 Threshold Effects
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.
Avoiding Rejection of Large Deposits
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.
Rationale
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.
Security or Other Considerations
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 to Participate in the Poll)
Require Minipools to Use Latest Delegate
!!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/vote, allow forced exits of underperforming minipools.
Introduction
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/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)