RPIP-71: rETH Withdrawal Liquidity

[knoshua]

This is the official discussion thread for RPIP-70: rETH Withdrawal liquidity via EIP-7002. Discussion has been going on for a while in the research thread.

This proposal is about exiting validators for withdrawal liquidity. There is another RPIP about exits for underperformance. Both of them use exit requests, defined in a third RPIP. The idea is to have all three of them in Saturn 2 and looking at all of them may be helpful to understand the design.

There has already been quite a bit of discussion on the technical side of this proposal in discord and at the same time there are still quite a few open questions with the design. Some of these are quite high level and I am hoping to get engagement from the pDAO at large on them.

Megapool Exit Criterion

We could simply do random selection or pick any criterion that can be checked on-chain, candidates include:

• lower RPL stake first
• first in, first out
• together with increasing bond requirement, exiting from megapools the furthest below bond requirement

Restitution for Exited NOs

In contrast to RPIP-73, where node operators are exited for bad performance, under this RPIP we are exiting people that may have been doing a perfectly fine job and we may be choosing them with at least some level of randomness. So one question that has come up is if we should offer some kind of restitution for exited validators. Ideas that have been brought up so far include:

• Giving express tickets for exited validators. This seems quite easy to do, but may not be all that impactful.
• Some way for exited node operators to skip ahead of people already in queue.
• A direct ETH payment, financed from rETH in the withdrawal queue that stops earning rewards.

Withdrawal Queue: NFT and Partial Filling

A position in the Withdrawal Queue could be represented by an NFT. Since the specification does not allow users to leave the Withdrawal Queue by canceling a request, they could instead sell their NFT to liquidate their position immediately.
On the other hand, people that don’t want to wait through the Withdrawal Queue already have the option to sell rETH instead. It may be more difficult to find buyers for a non-fungible queue position, and implementing the NFT would create extra gas overhead (~100k gas?) for everyone.

Another question is if users in queue should be able to do partial withdrawals as ETH becomes available. It may increase implementation complexity, especially in combination with NFTs.
Without partial filling, users would be able to achieve similar behavior with splitting withdrawal requests into multiple smaller ones. Without partial filling, it may also make sense to limit the ETH per request to avoid users having to wait a long time for their request to be completely filled.

Liquidity Buffer and Exiting to Fill Buffer

In order to ensure that the Withdrawal Queue can be serviced before rETH redemptions outside the queue, we need to set the liquidity buffer (rETH collateral target) to 0. The current proposal replaces it with a new buffer at the deposit pool level.
A buffer contributes to peg stability and it protects against the validator churn griefing discussed in Security Considerations, but unproductive ETH sitting in it hurts rETH yield. Arguably a buffer is less necessary with a proper withdrawal mechanism.

A related question is if we should exit to fill the Withdrawal Queue or exit to fill the liquidity buffer. Exiting to fill the buffer would lead to a nicer UX for rETH stakers: as long as demand for withdrawals is low, people could instantly redeem rETH at the protocol rate, at the cost of reduced rETH APR.

Distribution Delay

Minipools don’t immediately make ETH available for rETH burns. ETH first needs to be distributed, which initially is exclusive to the node operator and very delayed for others (currently 90 days after starting the distribution window). Therefore, if we are exiting minipools to fill the Withdrawal Queue, it is possible that queue wait time is unexpectedly long.
Because minipool delegate upgrades are opt-in, this can’t be reliably addressed with a delegate upgrade. Potential options include:

• Lowering the delay before permissionless distribution. Security implications would need to be considered.
• Automate distribution in smartnode and introduce a penalty for failing to distribute. Unclear how this could work for Allnodes.
• Allow user distributions with a final validator balance proof without the delay. This could be implemented by lowering the delay, distributing, and setting the delay back in one call.

[Darkmessage]

Oh boy, here comes the big one.

As strongly as I am for exiting underperforming validators aggressively, as strongly I am totally against exiting well-behaving validators.

Here’s why:

I am doing my job!

Having validators is work:

• Buy/setup/maintain hardware
• Setup/maintain operating system
• Setup/maintain Smart Node and EL/CL clients
• Be informed about changes to Smart Node and Hard Forks on Ethereum

Having validators thus costs:

• Expertise to operate the hardware/software stack
• Time to read up about important changes
• Money to pay the increased electical bill
• Money to lock up your part of the stake

My first validator was activated in December 2021 and beaconcha.in tells me it has:

• Blocks (Proposed: 14, Missed: 0, Orphaned: 0, Scheduled: 0) → 100%
• Attestation Assignments (Executed: 365’723, Missed: (545)) → 99.85%
• Sync Participations (Participated: 0, Missed: 0, Orphaned: 0, Scheduled: 0)

Over 4.5 years, I have only missed 550 attestations as a hobby-validator.

And now you wanna come and reward me by kicking me out? Just because of some rETH premium? That is not ok!

There was/is a clear contract!

When spinning up my validator, I knew that I would lock away my Ether. I will not be able to daytrade and will not know how long it will take until I can get it back. In fact, that was even before the Merge, so getting back your stake wasn’t even technically possible at the time. As a current example, I would really like to migrate my minipools to megapools now, but the entry queue if 60 days right now. The same could happen with the exit queue in the future, in fact, end of 2025 had the exit queue at 40 days.

And the people who gave/give the other portion of the stake by buying rETH also know how the system works. They know they can trade with it but maybe at a premium. So, they are not as locked in as me with my validator, but there is still some friction. And of course there is, because the nature of staking is that Ether is locked away! They participate in the system and the system locks currency for the duration of the validator-operations.

So, there is a clear understanding how the system works:

• Validator
  • gets more rewards
  • has to do more
  • is not liquid
  • can decide when to stop
• Staker
  • gets less rewards
  • is liquid
  • can decide when to sell but pays more or less premium depending on the validators

And now you wanna come and break that contract? Just because of some rETH premium? That is not ok!

Supply and demand is normal economics!

• I am purchasing 250 shares from NVIDIA for 10$ each. It’s great, nobody wants them, I can get them relatively cheap!
• A year later I purchase another 250 but have to pay 1’000$ per share now because it’s in high demand lately.
• A year later I sell 250 shares at a price of 2000$ each, because everybody still wants them.
• Another year later I sell my remaining 250 shares at a price of 1$ each, because nobody wants them anymore, they’re trash.

What you just read is simple economics. There’s an equilibrium where demand meets supply and that defines the price point for it.

If there is little rETH demand and you want to sell, well, you must sell at a low price. If rETH demand is high, you can sell for a very nice price. And low supply drives the price up while abundant supply drives it down.

At the moment, we have low ETH supply for rETH withdrawal because validators don’t exit. But instead of just accepting economics, this proposal reads to me like the moaning of some finance bro.

• Finance bros always tell you you’re stupid not investing when they make bank. “What, you’re not investing in MemeCoin1337? Haha, I’m making millions with it!”
• Finance bros then cry when their investments crash and demand help from other people. “Elon Musk tweeted shit about MemeCoin1337 and the price crashed. Now the government needs to give me 2 Millions because I’m so fucked now.”

No, you wanted rETH, so you purchased rETH for the price that was at that time appropriate. Now you don’t want it anymore, so you can sell it for whatever price is appropriate now. You don’t get to tell me that I have to exit my validator for you. You also can’t force anybody to sell NVIDIA stock if they don’t want! You get the price you get, you can take it or leave it.

And now you wanna come and rig the market? Just because of some rETH premium? That is not ok!

Ethereum also doesn’t do this

Ethereum also doesn’t want a bazillion validators. Ethereum also doesn’t want only 1 validator. Ethereum wants a nice amount of validators to ensure security and resiliency.

Ethereum doesn’t just exit my validator though. If they would, that would no longer be decentralised staking because only the big operators with automatice re-entry scripts and money to do so would still participate. Instead, Ethereum just pays less rewards and then I can decide for my own if that’s still ok with me.

And now you wanna come and go against the ethos of Ethereum? Just because of some rETH premium? That is not ok!

Summary and proposal

In a normal market you have:

Supply	Demand	Price
1 asset	1 asset	Normal
1 asset	1000 asset	High
1000 asset	1 asset	Low
1000 asset	1000 asset	Normal

If the price is high, you can’t force somebody to sell their assets just because you want to buy them cheaper, that is improper.

In Rocket Pool:

• exiting a validator or buying rETH supplies ETH
• spinning up a validator or selling rETH demands ETH

We could force people to buy rETH, that would supply ETH for the one who wants to sell rETH! But no, we don’t do that, because it’s improper.
And so is forcing a well-perfoming validator to exit just because somebody wants to sell rETH.

Instead, tie the validator rewards to the demand for validators, for ETH and for rETH. We had this initially, that the validator share was determined based on if we needed more validators or not. The problem was, that it was fixed when the validator was created. So if you had 20% commission, you had it even in times when validators where aplenty.

But now we have:

• megapools
• “forced” automatic newest delegate
• parameters to dynamically adjust rewards splitting

So, I say: Let the market play and have validators’ rewards dynamically tied to current demand/supply. But don’t force me to appease the rETH overlords just because they now want to sell.

[drdoofus]

I don’t completely disagree with you. I will vote for this in some form, but it does bug me a little. Honestly, if all/many of my validators were force exited when I was doing fine work, I would probably leave RP. Having said that, I am not trying to convince you, but part of the argument is that rETH minting is really hampered (especially for large holders and institutions) by the fact that they cannot exit position on peg reliably. Even they don’t lose much more market selling, certain demographics really, really don’t like it and refuse to mint rETH because of it. The hope is that by making rETH more attractive, we attract so much more that we all benefit by being able to create many many more mega validators.

This does bring me slowly to two points:

1. I have to re-read the RPIP, but it would be nice if once a megapool/minipool had a validator force exited NOT for bad behavior, that that node would be exempt from more forced exits until every other node also had an exit. So, hopefully, you only ever get one validator exited if any.
2. I do like the restitution idea for those force exited. For PR purposes, I would both give them express tickets (one for each megaVal exited, largely symbolic) and give them the rETH payment from the rETH in the withdrawal queue that stops earning rewards.

[haloooloolo]

I strongly disagree with most parts of this.

First, the economic perspective. ETH is a speculative asset. Some of the dynamics you’ve mentioned do apply to that base asset. Staking is supposed be a source of fairly conservative yield on top of holding ETH. The issue is also not a premium, it is a discount. Relying on market dynamics for accurately pricing the LST results in no significant upside besides the fixed yield because the protocol can accept more deposits at peg, but very significant potential downside when there is high demand for withdrawals. No one wants to hold an asset like this.

rETH also doesn’t exist in a vacuum. Even if this kind of volatile pricing was acceptable to some depositors without an alternative, the fact is that every other staking protocol does offer guaranteed withdrawals so not having them puts RP at a fundamental disadvantage.

I also don’t get how this is against the ethos of Ethereum. rETH depositors get to decide when new node operators are dequeued already. Buying hardware and getting in line does not guarantee you will be able to run an RP validator. Why should the rETH depositors not be able to undo this action? It is not your validator. It is the protocol’s validator that you provided a bond for in order to be trusted with its keys. The whole proposition of a liquid staking protocol falls flat if we make our staking token less liquid than native staking. The current situation of allowing node operators to hold their matched stake hostage is more permissioned than forced exits. Currently, we need two parties to initiate a staking “contract” if you want to call it that, but then we only allow one side to terminate that contract. With forced exits, either side would be able to terminate it. Ethereum doesn’t currently do this because there is no need for it. Justin Drake has also brought up force exiting validators if they need a smaller set for fast finality and consolidation hasn’t done enough to get there in time.

The complaint about hardware cost also doesn’t seem like a big deal. The worst case for a node operator is that they might have to switch to solo staking (unless they have less than 32 ETH, in which case the hardware was likely not a good financial decision over solo staking in the first place). Hardware can also be resold. The worst case for an rETH depositor is that they lose most of the ETH they have staked when trying to withdraw. Which one of these seems worse?

Being exited is a symptom of low rETH demand. Blocking that path and hoping market liquidity will magically fix it or trying to lock in people that want out is not going to resolve the underlying issue. What will? Creating more rETH demand by making it more attractive to hold the damn thing. If we start seeing net growth, we also won’t have to exit many validators. The important thing is that we do have the ability when it happens.

[dendofuman]

Small volume home staker here…I’m supportive of the overall RPIP and like the mitigations drdoofus has proposed. I don’t like the possibility of my high performing validators being force-excited for liquidity, but I dislike the possibility of the protocol dying a slow death from lack of rETH demand significantly more.

[knoshua]

@Darkmessage

I am doing my job!

Having validators is work

Yes! And sometimes people lose their job, even if they did nothing wrong. Your job being there depends on the “business” remaining viable and generating enough demand for its product. Any expectation that a job exists independent of that is disconnected from reality. I think it’s quite telling that you start out like this and then your counter example is not a job.

@Darkmessage

So, there is a clear understanding how the system works:

• Validator
  • gets more rewards
  • has to do more
  • is not liquid
  • can decide when to stop
• Staker
  • gets less rewards
  • is liquid
  • can decide when to sell but pays more or less premium depending on the validators

And now you wanna come and break that contract? Just because of some rETH premium? That is not ok!

Not because of some rETH premium. We want to change the contract, because with how the system works today the business is not viable and we are on a path of all the “node operator jobs” going away. rETH supply is down 40% from its peak in early 2024:

The protocol is unsustainable without significantly more demand for rETH.

I think the reality today is that the node operator side is more liquid than the rETH side, especially at scale.

@Darkmessage

Instead, tie the validator rewards to the demand for validators, for ETH and for rETH. We had this initially, that the validator share was determined based on if we needed more validators or not. The problem was, that it was fixed when the validator was created. So if you had 20% commission, you had it even in times when validators where aplenty.

But now we have:

• megapools
• “forced” automatic newest delegate
• parameters to dynamically adjust rewards splitting

So, I say: Let the market play and have validators’ rewards dynamically tied to current demand/supply.

We have the majority of stake on minipools and we can not guarantee to upgrade and can not adjust commission on those. Even if it was true, this would not give a liquidity guarantee to rETH holders. Our LST competition does have withdrawals. I don’t see how a half measure like this has a chance to turn rETH demand around.

[Patches]

I’m in favor of these changes, and I’m sure I’ll come back to explain why at some point, but quickly working with the assumption that some sort of clawback mechanism for protocol eth is beneficial:

Megapool Exit Criterion

I think I’m most supportive of lower RPL stake first. Exiting megapools backed by RPL creates volatility in the voter share observed by the rest of the nodes in the network, and that makes me a little uncomfortable. People who stake RPL with their megapool have additional skin in the game. I think I would prefer a system where the RPL stake and the age are combined into a score, with some randomness, so that we don’t end up with people toying with their RPL stake to stay above some threshold.

If we’re going to do random selection, I think I’d prefer for it to be biased against recently selected node operators a bit.

Increasing bond requirements seems like a substantially larger change, and whatever technical mechanism is used to implement the ordering for liquidity exits should simply be upgradeable so it can take something like bond requirement changes into account at a later date.

While we’re on the topic of larger changes, I wonder also if fixed-term validators aren’t a relevant idea. They could offer economic advantages over regular validators that offset their ephemeral nature, and act as a liquidity backstop. This may help reduce node operator discontentment, as their regular validators are less likely to be called upon to exit, and their fixed term ones exit when expected.

Restitution for Exited NOs

This seems like it may add a lot of complexity, especially the eth payment option. I’m supportive of the express ticket / queue skip ideas as long as they are simple and secure.

Withdrawal Queue: NFT and Partial Filling

With gas getting cheaper, I’m fine with the NFT approach. I’m also in favor of partial filling if the complexity isn’t too bad. I think it shouldn’t be too complex, but foresight is 20/100 at best.

Liquidity Buffer and Exiting to Fill Buffer

I’m coming around on the exit-to-fill-buffer, since it helps with the griefing vector. I think we can size it so the impact on rETH apr is minimal.

Distribution Delay

I like the proof.

[knoshua]

@Patches

Restitution for Exited NOs

This seems like it may add a lot of complexity, especially the eth payment option. I’m supportive of the express ticket / queue skip ideas as long as they are simple and secure.

Queue Skipping: I guess it would be a third queue (in addition to normal and express) implemented with a “force exit ticket” that gets absolute priority over normal and express queue. That way, people don’t queue skip other people that already queue skipped ahead of them. And implementation wise this would probably allow reusing/generalizing existing queue and ticket logic.

ETH payment: Yes, I’m worried about complexity here too. Maybe if it’s just some fixed ETH amount per exited validator that is pretty much guaranteed to be accrued from the rETH in withdrawal queue. But that likely also ends up being quite low impact.

[drdoofus]

If ETH compensation is more complex than we would like, I do think the queue skipping (third queue) option is pretty good, too. You got exited, not your fault, when we have enough ETH you are first back in. Seems reasonable, enough, I think.

[epineph]

So i think we need liquidity exits

My (not so polished) thoughts:

1. I don’t think the compact with rETH involves forced exits at parity. I think that there should be some fee to rETH holders for withdrawal. If there is a discount of 0.1%, i don’t think we should be encouraging NOs to force burn instead of using the various dex options.

Reasoning: forced exits is a tax on NOs and other rETH holders (through inefficient churn). Fees generated could reimburse these two groups

2. I also don’t think instant withdrawals is part of the compact. I think going partway towards instant withdrawals would likely get us to a “good enough” state (eg, going from no forced withdrawals to several weeks expected wait)

Reasoning: a longer expected wait time gives more time to match mints and burns (coincidence of wants); this may actually get exit queue moving faster than waiting for distribution; fees from rETH forced exiters could be used here.

3. I wonder if instead of having a completely separate process, liquidity exits could function by ratcheting up the performance based exit thresholds. A downside is that these are generally node-correlated, so multi-validator nodes would likely be wiped out with the rising tide- but this is true of most verifiable criteria (not purely random).

Exiting lowest RPL bond first adds back a strong utility function to RPL, but also a centralization problem to the protocol. I like it, i’d probably vote for it, and it also feels kind of *ick*.

I don’t like first-in first-out, as the first-in have actual proof of not being exited for performance.
I think overall random is the least likely to adversely affect decentralization and least objectionable.

4. I think SUPEREXPRESS tickets for exited validators makes sense, 3rd queue. I don’t like the NFTs, I personally find them really cumbersome for lido and other protocols that use them.

[knoshua]

@Patches

I think I’m most supportive of lower RPL stake first. Exiting megapools backed by RPL creates volatility in the voter share observed by the rest of the nodes in the network, and that makes me a little uncomfortable. People who stake RPL with their megapool have additional skin in the game. I think I would prefer a system where the RPL stake and the age are combined into a score, with some randomness, so that we don’t end up with people toying with their RPL stake to stay above some threshold.

If we’re going to do random selection, I think I’d prefer for it to be biased against recently selected node operators a bit.

Increasing bond requirements seems like a substantially larger change, and whatever technical mechanism is used to implement the ordering for liquidity exits should simply be upgradeable so it can take something like bond requirement changes into account at a later date.

Exiting megapools not backed by RPL also creates volatility in the vote share for other nodes, I don’t really understand how that’s an argument for exiting lower RPL stake first. The tournament-based selection would add randomness, are you saying you think RPL stake with randomness is gameable but if we add age it is not?

Biasing against recently selected node operators is ambiguous and I don’t understand the goal. At the extreme end, we could not exit a second validator from a node operator until every node operator had a first validator exited. This would mean that relatively, small node operators get hit a lot more than bigger operators. (Having your only validator exited is relatively more significant than having one of your 1k validators exited). And that doesn’t seem to vibe with how rocket pool is about decentralization and a diverse operator set. We don’t need to go for the extreme end of course, but we need to be careful to not create a less extreme version of this kind of effect anyway.

Yes, increasing bond requirement would be a larger change that would have it’s own RPIP. I’m thinking we may actually want to have that in Saturn 2 as well, but if not clearly that option is off the table for now.

@epineph

I wonder if instead of having a completely separate process, liquidity exits could function by ratcheting up the performance based exit thresholds. A downside is that these are generally node-correlated, so multi-validator nodes would likely be wiped out with the rising tide- but this is true of most verifiable criteria (not purely random).

Exiting lowest RPL bond first adds back a strong utility function to RPL, but also a centralization problem to the protocol. I like it, i’d probably vote for it, and it also feels kind of ick.

I don’t like first-in first-out, as the first-in have actual proof of not being exited for performance.
I think overall random is the least likely to adversely affect decentralization and least objectionable

I don’t think it’s a good idea to combine performance metrics with liquidity exits. We should aim to exit node operators that have unacceptable performance independently. That then leaves node operators with varying levels of acceptable performance. If we further discriminate based on it, we then are creating incentives for people to use setups that are over-emphasizing performance metrics and risk creating a more centralized operator set.

It’s actually not the case that most criteria are node-correlated. RPL stake and bond improve with validators being exited.

I disagree that exiting based on RPL bond adds a strong utility function to RPL. With Saturn 1 we made a choice to allow megapools without RPL and make the value proposition for staking RPL very clear for node operators. Exiting on RPL stake would undermine that. Someone staking 0.01 RPL on their 100 validator megapool would protect them from exits over someone else with a single validator and 0 RPL. There is virtually no benefit for the protocol from this and it just makes the RPL staking decision more difficult for node operators.

[epineph]

playing devils advocate, re:RPL.

1. Re: node level correlation. if validator exits happen sequentially then you are correct for amounts above 0; I was thinking a 2000ETH withdrawal request would choose 70 validators simultaneously.

2. re:utility- Ie gamesmanship topping up to avoid exit for liquidity gives additional value to RPL (ie rewards + avoids exits). I’m not sure why you wouldn’t consider that utility, and obviously the utility to RPL is more people staking for less voter_share needed.

3). I wonder if an auction system would work, where rETH requesting exit bid (let’s say 0.2%) and validators can exit voluntarily to meet that demand. I worry without some sort of fee the benefits of the exit system will largely go to bot arbitrage rather than any of our stakeholders.

[Pieter]

Yes, we need this. Our LST competitors have it, and we know that not being able to exit on peg reliably is a blocker to minting rETH for large / institutional parties.

It is a change to the NO terms, yes, but these were flawed to begin with. It is untenable for NOs to be able to hold rETH holders’ stake hostage indefinitely.

Exit Criterion

My current thinking is mostly towards random selection for simplicity.

Other thoughts:

• We could also introduce some additional bias against large nodes, since small nodes are hit relatively harder by each exit. Psychologically discouraging or even knocking out small operators is undesirable. This does introduce a sybil incentive for large operators to split nodes - to be weighed against losing gas and operational advantages of a single node.
• Round robin system where nodes recently hit are exempt or lowered in weight. Probably complex to maintain and hard to combine with other biases.

Restitution

Financial compensation raises many questions, like how much, paid from what budget, and will it be effective? Furthermore, what do we hope to achieve by providing restitution in any shape? To prevent NOs from getting discouraged and quitting completely?

I’m sympathetic to the idea of a third level of queue priority for liquidity exits. This provides NOs a route ‘back into the game’. Not sure if it should have absolute priority above the normal and express queues. In case of a large withdrawal / downtrend, this would remove all perspective of getting in for the other queues until the withdrawal is fully compensated with new deposits.

Minipools

We cannot force exit minipools without a delegate upgrade. But it’s essential that there are mechanism to include all minipools, as otherwise this becomes a discentive to migrate to megapools, or an incentive to manually stay on an old delegate. Probably needs a penalty system, not only for failing to distribute, but also for failing to exit a minipool when requested (maybe you already implied this, since of course you cannot distribute without exiting first.) The penalty should increase with duration of failure to comply. And exit requests should be very clearly communicated by the Smart Node or other means to prevent certain operators from discovering they’ve accrued a significant penalty long after the fact.

[knoshua]

I’ll have to think about your exit criterion ideas for a bit.

@Pieter

Financial compensation raises many questions, like how much, paid from what budget, and will it be effective? Furthermore, what do we hope to achieve by providing restitution in any shape? To prevent NOs from getting discouraged and quitting completely?

So we feel like that rETH should stop earning rewards as soon as holders put it in the withdrawal queue so that there is some opportunity cost to withdrawals and people aren’t constantly queuing for withdrawals and minting again, just to be more liquid. That means we have rewards that accrue while in withdrawal queue to distribute. As written right now, this simply goes to other rETH holders, but we could consider funding compensation for exited NOs from this.

We haven’t established clear goals for potential restitution yet. But yes, I think it should be based on making sure that being a NOs stays “attractive enough”. There’s a bit of tension here, since rETH wanting to exit indicates that we are in a state of too many NOs.

@Pieter

We cannot force exit minipools without a delegate upgrade. But it’s essential that there are mechanism to include all minipools, as otherwise this becomes a discentive to migrate to megapools, or an incentive to manually stay on an old delegate. Probably needs a penalty system, not only for failing to distribute, but also for failing to exit a minipool when requested (maybe you already implied this, since of course you cannot distribute without exiting first.) The penalty should increase with duration of failure to comply. And exit requests should be very clearly communicated by the Smart Node or other means to prevent certain operators from discovering they’ve accrued a significant penalty long after the fact.

Apologies, RPIP-71 and RPIP-80 are interconnected and that’s probably not very clear with the separate forum post and the numbering. So I’m guessing you hadn’t looked at RPIP-80 yet, but to give a rough summary:
Yes, we have to think about all minipools, including ones that won’t upgrade to a new delegate that supports triggered exits. Yes, the proposal is to have a penalty for failure to exit.

As far as smartnode, I think the idea would be that it automatically exits when it sees an exit request. Of course that requires people to upgrade to such a smartnode version and we do have node operators that don’t run smartnode at all (particularly Allnodes).

[Pieter]

@knoshua

Apologies, RPIP-71 and RPIP-80 are interconnected and that’s probably not very clear with the separate forum post and the numbering. So I’m guessing you hadn’t looked at RPIP-80 yet, but to give a rough summary:

You’re correct. I’ve been tracking protocol updates only in a cursory manner as of late, and hadn’t gotten to RPIP-80 yet (visiting the discussions in order of Langers’ Discord message, there’s quite a bit to go through . )
I’ve now read RPIP-80 and it makes perfect sense to me.
Thanks for researching and writing all of this by the way. Great job!

[knoshua]

No worries and thanks for all your feedback! It’s really valuable to get a fresh set of eyes on these.