I personally like the idea of giving rETH in return, then they can hold, or sell on the secondary market. At the very least, I think refunds should get inserted in the queue just like MP matches do. I think that is how most expect it to work. I understand this requires some protocol changes so would be a long term solution.
Short term id say remove it from the installer process, update the docs to say its an option and be very explicit about how it works and the risks. Perhaps find a whale that can clear the queue + the deposit refund backlog?
Agree - letâs do the âprevent further damageâ step (remove the option from smart nodes and ask allnodes to remove it from their setup) immediately, an only then figure out a next step.
Ok, weâve talked about this some more and based on the feedback here, Iâve decided to remove the 32 ETH deposit option from the CLI. You can still do it if youâre particularly determined by using the Go lib or the contracts directly, but for the average user, this will prevent them from making a mistake they didnât intend to make.
Iâll release this either in version 1.4.4 or 1.5.0, whichever ends up hitting mainnet first.
With that out of the way, I think we should discuss longer term visions for the 32 eth deposit option.
What is the reasoning behind the priority queue?
In my view, the 32e deposit is kind of useless:
If thereâs liquidity in the deposit pool, you donât need it, and would get instantly refunded
If thereâs no liquidity in the deposit pool, either the minipool queue is short OR
You want the 32e deposit to start staking immediately
but you donât want the 32e deposit, because thereâs no liquidity, and who knows if youâll ever get refunded
It doesnât make sense to me to process 32e minipools separately from 16e minipools- a 32e minipool doesnât provide the NO with enough benefit to punish them by locking up their eth. In fact, because the NO doesnât receive rewards on more than 16e + commission, they are effectively donating to rEth holders until they get their refund. You could even make the argument that 32e depositors should be rewarded somehow, eg, by being processed before 16e depositors- but I wonât make this argument, because it punishes 1-minipool operators, which is contrary to the raison dâĂȘtre of the platform.
I know it is a contract change and subject to audits, but I support @BLinc117.eth 's proposal to process minipools in order, regardless of deposit size.
Institutions do best with predictability. Being able to say âI pay 33.6 ETH and get 1 working minipool + 16 ETH of minted rETHâ is easier to model than either âI put in 33.6 ETH and get 1 working minipool and then 16 ETH someday I canât predictâ or âI put in 17.6 ETH and get 1 not-yet-working minipool, which will start producing at some point I canât predict.â
It allows folks to decide if/when they value skipping the queue based on all factors (number of pending minipools, rETH price on the market, etc). They can also opt into this flow whenever, not only if they decide to do so ahead. Eg, if they put in a 16 ETH deposit when the queue was 200 and 100 minipools were getting dequeued a week, and then something changed suddenly and only 10 minipools were getting dequeued a week, theyâd be able to decide to skip the queue at that time.
Early code
This is a first stab at step 3 in my link. I havenât done step 2 yet.
// Refund node by minting rETH instead of waiting for user deposited ETH
function reth_refund() override external onlyMinipoolOwnerOrWithdrawalAddress(msg.sender) onlyInitialised {
// Check refund balance
require(nodeRefundBalance == 0, "reth_refund should only be used when no user ETH has been assigned for the refund; please call refund()");
require(nodeDepositBalance == rocketDAOProtocolSettingsMinipool.getFullDepositNodeAmount(),
"reth_refund should only be used when a Full deposit was made and no refund has occurred");
require(msg.value == getFullDepositUserAmount(), "reth_refund should be for the full refund amount");
// Get node withdrawal address
address nodeWithdrawalAddress = rocketStorage.getNodeWithdrawalAddress(nodeAddress);
// Mint rETH to withdrawal address
RocketTokenRETHInterface rocketTokenRETH = RocketTokenRETHInterface(getContractAddress("rocketTokenRETH"));
rocketTokenRETH.mint(msg.value, nodeWithdrawalAddress);
// Update deposit balance to reflect refund
nodeDepositBalance = nodeDepositBalance(msg.value);
// This is equivalent to (1) receiving a deposit to mint rETH and (2) immediately withdrawing
// the same amount of ETH from the vault to assign to a minipool; we'll emit those events
emit DepositReceived(msg.sender, msg.value, block.timestamp);
emit EtherWithdrawn(nodeWithdrawalAddress, msg.value, block.timestamp);
}
Yeah, that makes sense to me. And note we can allow people to move along the steps - doesnât need to be decided ahead of time (though you can only move down the list).
What is the latest thoughts on how to clear the queue for the existing 32 ETH minipools that are not advancing in the queue? Do we have to close the queue to clear them?
It offers the node operator the ability to start effectively staking their RPL and earning RPL rewards. They also start to stake on ETH on the beacon chain early (without having to wait in the queue). But both come at the cost of the risk of not advancing in the minipool queue for a refund.
@knoshua pointed out a pretty big issue with the rEth-minting deposit on discord and I wanted to summarize it here so it doesnât get lost.
Post-withdrawals, rEth will be redeemable for eth from the vault. Providing an NO the ability to mint rEth on deposit means they can immediately begin staking, then immediately redeem their rEth for Eth, and repeat the process, effectively creating a path to convert vaulted eth to staked eth, and eliminating liquidity for redemptions. I see this as a pretty major flaw in the approach.
That point is fair, though it only applies in the narrow circumstance where:
rETH supply > rETH demand
rETH supply - available rewards < rETH demand
If the former isnât true, then folks arenât looking to exit. If the latter isnât true, then weâll trade at a discount in any case. If we are in the middle ground, then yes - folks could effectively burn rETH to skip the queue for free and effectively use liquidity meant for rETH burning for minipool matching instead.
That said, @knoshua brought up a different point, which I find more challenging. If this path is available, will nearly everyone with enough capital take it? If so, that could make the half pool depositors wait indefinitely. This assumes that the people that get refunds choose to sell their rETH before full repeg is achieved, which thus delays full repeg, dis-incentivizes directly minting rETH, and thus delays when thereâs ETH available for matching with the half deposits.
If this narrative is accurate, weâre pretty much swapping from the current state (16 ETH pools are the norm, 32 ETH pools wait a long time for peg) to a similar state (rETH refunds are the norm, 16 ETH pools wait a long time for peg).
I havenât yet decided whether (A) I buy that narrative entirely, or (B) which of those 2 choices sounds better.
Reasons this narrative might not be true:
People may actually like being partly liquid; the narrative is less true insofar as people donât sell before repeg.
Taxes - potentially major; in some jurisdictions the swap to rETH is considered taxable but staking ETH isnât.
Taxes - minor; in some jurisdictions the rETH sale is treated preferentially if you wait a year - ie, if we have a 2% discount you may be better off waiting a year (and full repeg) rather than selling when it gets near full repeg but itâs been less than a year.
I think all of the above apply even more so to institutions than to people.
Now that itâs disabled are there plans to update the queue to push the Full deposits to the front of the queue? Iâm not sure how hard that would be but it would resolve the last open issue. Otherwise the 30 or so full deposits in the queue may wait months and months more to get their refund.
I guess though if you go with this approach youâll need to also disable the ability to do the full deposit even manually through the CLI otherwise people will use it to skip the queue on new minipools.
Edit: just saw Kaneâs comment that thereâs no way without a contract upgrade to disable full deposits. In that case moving full node deposits to the front of the queue could be abused. Unless that would also require a contract upgrade anyway in which case could do them both at the same time.
