Example:
This Baker has not been paying out rewards since cycle 405 and is still baking for over 145.000 tez. And they are not the only one. They announced that they were closing over a year ago. Not much else can be done for the people who aren’t paying attention.
But still I would say it is a bit of not good impression and some housekeeping on the chain would be good? - I cant find a better word for what I mean.
So… how can we prevent something like that?
What comes to my mind is the following. Once a baker stopped baking and closed shop nothing needs to be done on the bakers end or users end. Simply after some time from closing, lets say for example 60 days the Tezos protocol itself does some kind of “housekeeping” and clears those delegations by simply undelegating so the status of the delegation to this baker goes to 0 Tezos.
I see this as not invasive way to keep a clean way for dead “baker ghost accounts” with a significant amount of delegated tezos.
Thanks to Tezberry Pie for rasing this issue on Bakers Slack, since then I am thinking about possible solutions from time to time and I am curious about feedback from others please.
I am an empiricist, I want to see it in practice. Whatever theoretical ideas or models we come up with, in my opinion they should be socially tested on ghostnet / a dao structure first.
Lets have different structures compete and see which one is best.
One unintended consequence I can see of taking actions like the one proposed in the OP is that it allows the end user to ignore more and more of their individual interest and get used to someone else taking care of it.
That is not something I think is a good idea to cultivate. I’d be more in favor of some kind of opt in messaging mechanism so people could inform each other of whats going on an what they could do about it.
If someone is detached and does not care or follow up, their being diluted out of the ecosystem is a feature, not a bug.
I am all for it to test such ideas/models on a testnet before considering adding that to mainnet.
Well the end user would still need to care about baking rewards (that he do not receive in such cases anyway). So when we keep the current state the user should need to check and take care of the fact that he does not receive baking rewards. In this case the end user should take care of undelegating and delegating to a new baker.
In the proposed idea its the same, with the difference that the baker statistics on the chain are not “bloated” with “dead” bakers that have still a delegated tez amount. The end user still should take care of (in this case only delegating) to a new baker.
Ideally people should follow close and take action when a baker closes shop of course. Or when a baker adjusts the fee to e.g. 100% - in the fee case there would be still no change at all.
This Baker has not been paying out rewards since cycle 405 and is still baking for over 145.000 tez.
This baker clearly did not close shop, as the baker seems to be running:
Otherwise the baker, would have become inactive if it hadn’t participated in consensus for PRESERVED_CYCLES (5 on Mainnet), and eventually it would have stop being assigned endorsing/baking rights.
Did they close shop and then restart as a private baker/gave their keys up?
I stand with my original position. The risk of a complacent userbase and “nanny” development out weighs any supposed benefit. I actually don’t think there is any benefit at all.
To add to my point, it is best to let that which is solved by economic incentives do so.
Don’t get me wrong, I am all for making things easier and reducing “homework” for users, but not with methods like this.
Some king of notification, education / messaging is the way to go, imo.
To be clearer on my end I am referring to testing some social/economic theory. In that case the model just needs to be mapped close enough to get useful data.
As far as testing protocol changes on Ghostnet, it’s not super useful or possible ( tmu ) at this time, but that too could evolve.
“For the end user, delegating to an inactive baker or not delegating at all is financially equivalent isn’t it?”
Yes, and?
( In general sure. Not sure what legal/accounting implications they could possibly have depending on their jurisdiction. )
An alternative design, first proposed by Phil Champagne here if I am not mistaken, is to allow bakers to change the delegation of their delegators (for example because they want to change address, are closing shop and designating a successor, or are over-delegated).
For smart contracts it is already possible so it is just a matter of standardizing the way to do it. For implicit accounts, this would require a protocol change but, unless I am overlooking some aspect, it would be a very simple one.
this design is not about this issue at all
it’s not like these bakers want to stop being delegated, they just don’t wanna pay the rewards
that’s why they get delegations, at some point in time announce they are closing their baker and keep getting rewards from those who don’t follow their baker closely
Exactly, and that’s shitty behavior. “oh noes my delegators didn’t get the notice and now I’m earning 50% APY, what can I do I’m just going to keep on baking ¯\(ツ)/¯”
A solution is for other bakers to voluntarily blacklist them: don’t endorse such bakers’blocks, don’t include their endorsements in your blocks.
This requires no proto change, just a patch in the baker.
It’s not all good though. If you do this, you take a small performance hit yourself. And it can affect consensus if done too widely.
That’s shitty behavior indeed but generally I don’t like the idea of blacklisting anyone (unless they commit a crime or smth)
We had these convos on automated payments back in the day, i.e. a protocol forces you to pay to your delegators
it might be a solution
I would absolutely be against the protocol forcing baker payouts… leaving things to the market place is a feature, not a bug.
Discovering good / bad. competent / incompetent, diligent / negligent actors, be it bakers that don’t pay delegators, or delegators too lazy to maintain their investment / property… is a feature, not a bug.
I mean isnt it possible to track the recent payout % to delegators via an RPC endpoint?
One could track a possible change with a self made tool/bot or the Tezos Notifier thats tracks this via API (if thats possible). And when the baker changes to 100% you get a signal/message/mail whatever. And are notified.
