overdelegation protection

[nicolasochem]

Problem

A tezos private baker with 100% uptime will normally get rewards equal to the inflation of tezos.

A tezos public baker collects fees on top of that. So in theory, a public baker's gains are superior to tezos inflation.

But in case of overdelegation, this may no longer be true.

Since ithaca, the overdelegation calculation is very simple. Let's take an example.

• a baker charging 15% fee has 10k tez balance an 90k delegation. They are "full". It's perfect for them: they collect 100% of inflation on their own stake, and 15% fees on the remaining 90% of stake delegated to them.
• the same baker now has 10k tez balance and 180k delegation and 190k total stake (edit by jdsika). They are twice overdelegated: only 100k tez is taking into account for stake (hence rewards) calculation. It is bad for them: since the rewards are paid evenly between them and the delegators, they only collect 50% inflation on their own stake. Delegators also collect only 50% of their potential rewards. Baker still collects 15% fees on the delegators' rewards.

We are proposing to insulate the baker from this problem and exacerbate it for the delegators.

Proposal

We introduce a new configuration toggle overdelegation_protection taking a boolean. It defaults to true

When true, we skew the percentage calculation so that the percentage of the rewards allocated to the baker is 10% when the baker is overdelegated. All other delegators share the remaining 90%.

Following up on our example:

• a baker charging 15% fee has 10k tez balance and 190k total stake (edit jdsika). They are twice overdelegated. But, 10% of the rewards given by the protocol are reserved for the baker. TRD distributes the other 90% to delegators based on the delegators' share. The baker still collects 100% inflation on their own stake, and 15% fees on the remaining 90% - same rewards as if they were "full". Delegators are worse off though, because they only collect 47.5% of their potential rewards.

When the baker is not overdelegated or when overdelegation_protection is set to false, today's TRD behavior applies: equal distribution of stake between baker and delegators based on their share.

Motivation

Overdelegation is a problem for bakers and delegators. But it is of utmost importance of the tezos ecosystem to encourage more public bakers to join. The overdelegation problem is discouraging bakers, because they know they may earn less if they are overdelegated.

Ithaca made it better because overdelegation no longer has any effect on "performance" metric displayed by popular indexers. But it can still lower the baker's gains. Being a delegator, or keeping their coins on an exchange is better than baking. This proposal fixes that: a baker knows they are getting the maximum possible earnings no matter what.

An alternative is to selectively punish the delegators who caused the baker to "tip over" to overdelegation. But this would require TRD to load the entire history of delegations: a serious deviation from today's behavior which relies on a "snapshot" of delegations in time. It would be difficult to pick a methodology to select the account to punish, across the many that come to mind, and to account for all the edge cases. It would make TRD's behavior hard to understand from the outside.

In emmy*, the overdelegation threshold was approximate and variable per cycle, based on staking rights. In tenderbake, it is a simple, constant 10 factor. Therefore, it is now possible to implement the simple protection mechanism described here.

Effectively, this proposal insulates the baker from the overdelegation problem. It is now the delegators' problem. They have to collectively sort it out by taking some of their delegation elsewhere. This indirectly may cause more holders to become bakers, which is good!

In case of overdelegation, bakers are still encouraged to reach out to their delegators to tell them to delegate elsewhere. But it no longer affects their own earnings.

Implementation wise, I believe this will be a small patch.

Open questions

only 100k tez is taking into account for stake (hence rewards) calculation.
What do we do with owners and founders in this scenario?

[ericlavoie]

It is the simplest way, like you said trying to determine who cause over delegation and penalize them, is too complex to implement. Founders is dealt with the balance reservation (10% in your example) would get divided by the founders ratio set in config. Owners is irrelevant since it is the baker fee calculation 15% (for example) which is calculated on the total reward distributed.

[nicolasochem]

@ericlavoie do you want to try implementing it? 😉

[ericlavoie]

I may help, but I don't know enough with the code base, I'll take a look, but someone more experienced with the code should take it and assigned some subtask, it would help learn the code base..

[jdsika]

I like it!

There is still a performance metric that is impacted by the overdelegation and even more when overdelegation_protection is True.

The APY of the client who chose to delegate to the baker.
In the case of False the baker is taking part of the risk which results in a little lesser impact on the APY for the client.
I think a next step is to write down the calculations here and edge cases and then we can get started.

[ericlavoie]

The calculation for the no limit to the bond (default 10% reserved)
The total balance of the baker, the maximum staking balance with that amount, and the current staking balance.
If current is bigger than max staking balance and overdelegation_protection
we calculate the ratio of total balance over max staking balance and apply it to the reward amount. This amount is used to distribute to founders according to their ratio.
The delegator calculation is the total reward amount minus amount calculated for founders share.

What are the edges cases, different limit set for the baker, the default is 10%, what impact if different than that^

[ericlavoie]

Ok I check a few things, using https://api.tzkt.io/v1/accounts/{baker-tzkey} we check if frozenDepositLimit key is set, if not then if frozenDeposit = balance then we enable the alternate calculation, if frozenDepositLimit is set, the comparison becomes if frozenDepositLimit = balance, then alternate calculation is used.

[nicolasochem]

Sounds good. You should probably put frozenDeposit and frozenDepositLimit in the reward provider model then in payment_producer.py, implement the logic you described and set a variable overdelegated = True|False and we take it from there.

[ericlavoie]

Ok to set the reward provider model, rpc, tzkt and tzstat api code need to have those 2 values pulled for each case.

[nicolasochem]

correct. For tzstats it should be there somewhere (but may have wrong values, I am still working with Alex) and for RPC the hard part is to get access to a reliable archive node to test end-to-end. Make sure to work on top of the ithaca2 branch.

[ericlavoie]

I am getting lost in that code, too much sub code.

[nicolasochem]

it looks like breadcrums implemented this feature and called it "overdelegation guard":

https://github.com/kalouo/breadcrumbs/blob/master/config-template.hjson#L35

Breadcrumbs is shaping up to be a great project 👀