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
I support increasing to 5k
1 Like
Whatâs preventing us from taking this to a Snapshot today?
7 Likes
Or today?
Iâm also in strong support. PleaseâŚletâs do this.
4 Likes
Today would be great too.
7 Likes
Is there anything we as simple community members could do to speed this up?
5 Likes
My fortune cookie said today would be full of important decisions. Which might suggest today is a good day for Snapshot?
5 Likes
@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.
9 Likes
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.
17 Likes
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.
grazie!
1 Like
Update and request for comment on #2, which I put in a design PR for at https://github.com/rocket-pool/rocketpool/pull/251.
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).
8 Likes
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.)
2 Likes
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 
When Ethereum allows withdrawals do you think we will get refunded?
assuming Reth demand stays low and there is still a queue