Update RPIP-71#382
Conversation
- add oDAO-trusted design for minipools with rationale - move tracking ETH fully to RPIP-80 - Open Questions: new idea for distribution delay - Open Questions: Restitution for exited NOs - minor tweaks
- new `withdrawal_hysteresis` parameter - reentry queue - permissionless distribution of minipools - removed open questions section - refined language
| - Redemption of rETH outside the queue SHALL be prevented to the extent possible. | ||
| - The protocol SHALL allow the Withdrawal Queue to burn rETH. | ||
| - `network.reth.collateral.target` SHALL be set to 0 and a new buffer for withdrawals SHALL be implemented in the deposit pool, reserving up to `deposit_pool_collateral_target` percent of ETH backing rETH for rETH burns. | ||
| - When megapools distribute rewards, they SHALL send ETH to the deposit pool rather than rETH. |
There was a problem hiding this comment.
Hmmm... clear to me, but maybe more explicit like: rather than the rETH token address or rather than the rETH contract
|
|
||
| #### If `megapool_exit_phase = false` | ||
|
|
||
| - The protocol SHALL allow the oDAO, by majority vote, to request minipools to exit as specified in RPIP-80. The amount necessary to cover the withdrawal shortfall minus `exit_hysteresis` SHALL act as a hard cap on the possible exit requests. |
There was a problem hiding this comment.
minus
exit_hysteresis
typo double space
| - ETH held by the rETH contract, and | ||
| - ETH held by the deposit pool. | ||
|
|
||
| If the withdrawal shortfall is at least `exit_hysteresis` ETH, additional megapool validators MUST be selected and added to the exit list as defined in this section. |
There was a problem hiding this comment.
For author consideration: Would another way to handle this be based on request age? I think that would allow more intuitive statements (eg, enough ETH to service your request will be exited after x days), and it would also be an easier pdao knob to set (eg, we are comfortable with folks waiting y days [beyond queues] in order to avoid churn).
I have not been following closely, so this may have been considered and discarded.
There was a problem hiding this comment.
I think it's also a bit stronger against the "Repeated Minting and Withdrawing" scenario, though I don't really think further strength there is critical
There was a problem hiding this comment.
I'll have to think on that.
| - the eligible megapool validator set is non‑empty. | ||
|
|
||
| 1. The protocol MUST sample `k` distinct validators uniformly at random without replacement from the eligible megapool validator set. | ||
| 2. For each sampled validator, the protocol MUST compute an exit score according to the chosen Exit Criterion. |
There was a problem hiding this comment.
Is Exit Criterion defined somewhere? It should either be defined, or responsibility for defining should be given to an entity
There was a problem hiding this comment.
Good point. Earlier versions had an "open questions" section that made it clear that exit criterion still needs to be figured out. That got dropped and now it's not clear at all where exit criterion is going to come from. Adding a section to Rationale.
My expectation right now is that we'll have pDAO vote on it and update the specification section based on outcome of the vote. Maybe the RPIP should reflect that directly in the specification?
|
|
||
| We also considered a trustless design for minipools. This would increase complexity and incur additional gas costs that the protocol or pDAO would either have to fund in some way or add to oDAO's duties. The trusted oDAO duty appears preferable because of its temporary nature, limited risk, reduced complexity and lower gas cost. | ||
|
|
||
| The `megapool_exit_phase` toggle allows the pDAO to switch to the second phase once minipools are largely exited or known to be unresponsive. This choice is left to the pDAO because we cannot precisely define it in advance. |
There was a problem hiding this comment.
If they are known unresponsive, shouldn't they be getting tried on cooldown and penalized if appropriate? I'm wondering if the megapool exit phase should include requesting exits on any remaining minipool every did_not_exit_cooldown or something.
There was a problem hiding this comment.
I was thinking that the pDAO at that point could come up with a plan for any remaining minipools. I'm not sure it would make sense to keep going with small penalties over time, but we could vote to have oDAO apply one (bigger) penalty, leaving some bond left over so that those NOs still have an incentive to exit. We could definitely come up with a plan now as well, I just figured this isn't a big priority and we may have a better idea in the future.
2 participants
No description provided.