Proposal to Increase the Deposit Pool (dp) limit

Just wanted to chime in slightly in favor of #2 or simply delaying. #1 causes a (admittedly small) harm to the protocol and really just replaces one parameter vote every several months.

1 Like

Put in a PR with an attempt at #2:


I support increasing to 5k

1 Like

What’s preventing us from taking this to a Snapshot today?


Or today?

I’m also in strong support. Please…let’s do this.


Today would be great too.


Is there anything we as simple community members could do to speed this up?


My fortune cookie said today would be full of important decisions. Which might suggest today is a good day for Snapshot?


@BlytheK raised a good question, regarding whether we can increase the DP pool limit before the OP rETH incentives go live. Whilst it was suggested that this could be the first official snapshot vote, given there is broad support for this upgrade, perhaps it is worth considering whether it is worthwhile making this change without an official snapshot vote (if Snapshot will not be integrated prior to receiving and deploying the OP incentives).

I don’t believe we have a specific timeline regarding when we will receive the OP incentives, so it’s possible that Snapshot will be integrated prior to this anyway. However, if Snapshot will be a barrier to increasing the deposit pool, we should consider proceeding with this anyway, to help to maximally capture this potential rETH demand.


The OP incentives will be available within a couple of weeks but I have to confirm that.

We want to get the Delegate nomination page out just for completeness. We will push that live (pointing at mainnet) tomorrow and raise a call for delegates.

We will announce the vote today and point people to this discussion to get educated. Next Tuesday (our time) we will raise a snapshot vote to raise the DP limit to 5k. We will allow 1 week of voting and then, on a successful vote, the team will execute the change.


support this. also good for NOs who may be looking to add minipools and worry about the wait. This would also clear the 32ETH NOs who are waiting if more whales come along. Aware that the 32ETH full stake option is being phased out soon so hopefully will not be an issue going forward.

1 Like

Update and request for comment on #2, which I put in a design PR for at

Opinions and likes requested on the following
My variant also put in that the number of minipools assigned would scale with deposit size (ie max_assignments = 2 + (deposit//16) instead of max_assignments = 2). I think this is fair because the gas burden, as a percent of the transaction, is more evenly shared.

Right now we have a case of the minnows subsidizing the whale (because gas for 2 assignments for a 0.2 ETH deposit is a much bigger percentage than gas for 22 assignments in a 320). The other alternative, which we see regularly, is a good samaritan community member takes on the gas cost to assign personally.

As @kane pointed out, there’s an unfortunate limit due to gas available in a block, so we’d likely have to cap out at or before 98 deposits. Still, this is a big improvement in terms of (A) minnows and whales taking on a more similar percentage burden, (B) much rarer that a deposit won’t fully assign itself, (C) much cheaper to get the rest assigned (either via minnow deposits or good samaritans).


I support this and think that it does help equalize the cost of processing the deposit queue to all depositors. I also believe we should reserve a small portion of the pDAO budget for use as gas txn reimbursement to “clear the queue” if needed. (But that is a budget topic for another thread.)

1 Like

Good adjustment as long as it is flexible with our overall deposit pool size changes.

Agreed - that can be an incremental improvement, and the cost would be lower with something like this in place :slight_smile:

For cross reference a RPIP has been drafted here: RPIP-9 Increase Deposit Pool Limit