Rewards Saturation Also Threatens Non-Saturated Pools

[staking4ada.org]

EDIT Aug 27: based on feedback from various feedback from the community, for which many thanks, we have concluded the idea brought forward in this post is incorrect:

Contrarily to what this post suggests, large pools can grow all the way up to saturation point, without any negative consequences for their rewards. Even if they get lucky to produce more blocks than they are supposed to receive on average (apparent performance > 1), they receive the same additional rewards (percentage-wise) as any smaller pool also would get.

I will leave the contents of my post below intact for future reference.

---

After taking a closer look at the widely used term “pool saturation”, I came to the conclusion that the risk of getting less than optimal rewards is not just relevant for operators of --and delegators to-- pools marked as “saturated”.

Due to the Ouroboros randomized slot leadership distribution to stake pools, also delegators to pools which are considered to be far below the calculated “pool-saturation” size, in Epoch 212 estimated at 207M ADA, are at risk of occasionally getting their rewards capped.

To illustrate what is going on, please refer to the chart below:

What the chart demonstrates, is that a pool with an active stake of “just” 138M ADA will miss out on rewards, whenever it gets a very lucky slot leadership assignment and is allowed to mint many more blocks than usual.

Smaller pools on the other hand, with an active stake significantly lower than 138M, can take the full benefit of exceptionally generous slot leadership allocation, without any risk of losing out on any rewards.

As a result, I would like to present my theory that the perceived higher profitability of large (135M+) pools compared to smaller pools could be much smaller than generally assumed.

Although this needs further mathematical research, the downside of losing out on rewards on a regular basis, for large pools actually might have a greater negative impact on yearly ROS, than the upside of being able to divide the minimum fixed pool cost of 340ADA among their relatively larger delegator base.

I am looking forward to your comments on the suggestion that also pools far below saturation, will see their rewards capped every now and then. For the full article I wrote on this subject, read this blog post.

edit 26/8: please treat the idea presented above with caution, until verified against feedback as well as contradictory data from the ITN.

[Gilianscheatday]

What this means, is that a pool of this size on average produces exactly the number of blocks needed to generate the maximum possible rewards. Beyond this optimum block-quantity, no additional rewards will be generated, regardless how many additional blocks the pool mints. However, any number of blocks below the optimum quantity will result in proportionally lower rewards, to be distributed among its very large share of stakeholders.

Where did you get that information from?

Documentation says:

saturation, a term used to indicate that a particular stake pool has more stake delegated to it than is ideal for the network. Saturation is displayed as a percentage. Once a stake pool reaches 100% saturation, it will offer diminishing rewards. The saturation mechanism was designed to prevent centralization by encouraging delegators to delegate to different stake pools, and operators to set up alternative pools so that they can continue earning maximum rewards. Saturation, therefore, exists to preserve the interests of both ada holders delegating their stake and stake pool operators.

The bold part basically says that anything below 100% will not have diminishing returns. So I am wondering if either your understanding of how saturation works or the documentation is wrong or not clear enough.

(Edited by @RobJF to fix markup)

[staking4ada.org]

Good call and I invite everyone to look at this too.

I believe that the documentation talks about averages. So that text is correct within the context of that pool minting every epoch the exact number of blocks proportionate to its share of active stake at the calculated saturation-point (let’s call that number n-blocks).

The reality is that also smaller pools will occasionally mint more than n-blocks, whenever they have favourable slot leadership assignment, thereby also getting their rewards capped.

[Zaytion]

I don’t believe your chart is accurate.

(The following screenshots are taken from (https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf)

The optimal rewards of a pool are capped at the saturation point, but the pool performance augments that amount and isn’t capped by saturation.

The optimal rewards are described by the following formula:

Here the rewards are capped by the saturation limit. However, this does not take into account the pool performance. That is calculated using blocked added, expected blocks, and the relative stake of the pool (which maxes at the saturation limit):

After the apparent performance is calculated, we multiply it by the optimal rewards from earlier, to calculate the actual rewards:

So the optimal rewards are augmented by the apparent performance without any cap. For example, If a saturated pool created more blocks (denoted by ‘n’ in the above equations) and nothing else changed, beta would be a larger number, thus the apparent performance would increase when you calculate beta / sigma, thus the actual rewards would be a larger number when you multiple a greater apparent performance by the same optimal rewards.

Therefore I believe your chart is in error. If I am wrong I look forward to learning how.

[Klobbinger]

I don’t think the conclusion is correct. Take a look at p 38 5.5.2 formula (2) of the design specifications.
https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf

To take a simplified look at the pool rewards we can assume a0 = 0 meaning that pledge has no influence on the rewards. Then the optimal rewards only depend on R the total rewards paid out in one epoch and sigma’ which is min(Sigma, z0) with sigma being the relative stake of the pool i.e. It’s share of total stake and z0 being 1/k. The max optimal rewards for a pool then conclude to R / k. The amount of produced blocks don’t play a role at that point.

These optimal rewards are then multiplied by the pool performance factor which is calculated by n number of blocks produced by this pool in the epoch, N total number of blocks produced this epoch and sigma the relative share of stake of the pool:

Performance p = (n/N) / sigma

If the pool produces fewer blocks than expected the performance is < 1 if the pool gets lucky and produces more than expected i.e. gets lucky in the slot leader election the performance will be > 1. Over several epochs this will even out and if the pool produces blocks reliably the performance should be 1.

Conclusion :

1. Other pools have no influence on the rewards of your pool

2. As long as the pool is not over saturated the optimal rewards per Ada staked are always the same

3. Getting lucky during slot election will increase rewards even if the pool is fully saturated.

[staking4ada.org]

Many thanks for your extensive reply.

I follow your reasoning that, based on the design spec formulas, optimum rewards are capped based on max allowed share of delegated stake (ttl delegated stake/150), and that subsequently those max optimum rewards can be augmented, if the pools’ relative performance > 1.

However, what originally brought me to my idea (which -as you explained- may be incorrect according to the design spec formulas), are my observations during the ITN phase.

During the ITN I noticed on multiple occasions that rewards of the 4ADA pool (which was never marked as saturated!) max-ed out to a specific amount, with different block production numbers. I saw the same maximum amount also being applied to other pools, which had different block numbers as well, in the same or in nearby epochs.

Unfortunately, the ITN-archive is no longer online, but I downloaded the 4ADA archive before it was taken offline. Here are two examples (i can make the full archive-json available upon request):

two isolated epochs:

• {“epoch”: 54, “blocks”: 32, “blockstake”: 82562534117065, “stake”: 82257749386715, “value_for_stakers”: 34178794536, “value_taxed”: 341753424}
• {“epoch”: 66, “blocks”: 44, “blockstake”: 98181939828227, “stake”: 77742566935800, “value_for_stakers”: 34178794536, “value_taxed”: 341753424}

four consecutive epochs, the third of which did not make the rewards cap due to low block count

• {“epoch”: 81, “blocks”: 40, “blockstake”: 93404161959734, “stake”: 94443529679095, “value_for_stakers”: 34178794536, “value_taxed”: 341753424}
• {“epoch”: 82, “blocks”: 46, “blockstake”: 94443529679095, “stake”: 91444950820529, “value_for_stakers”: 34178794536, “value_taxed”: 341753424}
• {“epoch”: 83, “blocks”: 26, “blockstake”: 91444950820529, “stake”: 91601434999253, “value_for_stakers”: 25103069432, “value_taxed”: 251005340}
• {“epoch”: 84, “blocks”: 41, “blockstake”: 91601434999253, “stake”: 92535717897695, “value_for_stakers”: 34178794536, “value_taxed”: 341753424}

Now, I am not sure if:

• there was an error in displaying the rewards on pooltool.io (although I am quite sure I did receive these exact “value_taxed” amounts in my pool addresses)
• the Orouboros Praos protocol was implemented differently (wrongly?) on the ITN
• despite the apparent mathematical evidence proving me wrong, I AM right about rewards being capped for saturated pools with apparent performance >1

I will try from my side to dig a little deeper into this matter, and will edit my post to include some words of caution.

[staking4ada.org]

Thanks for your reply. Please see my response above which equally applies to your reply as well.

[Klobbinger]

On the ITN a lot of parameters where different and the incentive formula was definitely not the same. Unfortunately I don’t have a source for this, but I remember Charles saying that they used a more simplified incentive structure.

To be 100% sure s.o. Would need to look at the code in the git hub repository. I only know a little python so I doubt I could find that section easily.

[Umed_SKY]

I understand the OPs inclination to think that the rewards are capped at saturation point regardless of number of blocks produced, meaning getting lucky for a saturated pool would have no additional rewards.

However, I also see your point and understand that for a pool to reach its average expected returns even at saturation point, we should have no cap on performance, as doing otherwise would unfairly penalize these pools beyond the saturation point.

Perhaps @Lars_Brunjes can weigh in on this particular issue.

[Zaytion]

I can tell you there are differences between how ITN rewards were calculated and how mainnet are. The major difference is that ITN relatives values for stake and saturation were based on total Ada staked vs mainnet bases these on total Ada supply.

Also the ITN had a fixed amount of rewards with a semi known end date so I think the same number of rewards went out each epoch.

I don’t know how ITN performance was calculated.

[staking4ada.org]

Yes, I wasn’t aware of some of the differences until yesterday. Hopefully we can get this clarified, as I noticed many are wondering about the exact saturated rewards mechanism.

[_ilap]

@Zaytion

So the optimal rewards are augmented by the apparent performance without any cap. For example, If a saturated pool created more blocks (denoted by ‘n’ in the above equations) and nothing else changed, beta would be a larger number, thus the apparent performance would increase when you calculate beta / sigma, thus the actual rewards would be a larger number when you multiple a greater apparent performance by the same optimal rewards.

@Umed_SKY

However, I also see your point and understand that for a pool to reach its average expected returns even at saturation point, we should have no cap on performance, as doing otherwise would unfairly penalize these pools beyond the saturation point.

For long term, the apparent performance should average the rewards out at the pool’s saturation point, and therefor sigma' like capping should be necessary in the apparent performance equation.

BUT, keep in mind that apparent performance, as the leader selection too, is based on the active stake (~12.8bn) and not on the total stake (~31bn) like the reward function.

So, the long term rewards, should converge to the expected value, relative to the saturation point (sigma') and not to a smaller value (if the pool is oversaturated), what the sigma a would do if it’s not capped by some sigmaa'=min(sgimaa, z0)

So, I tend to lean toward for capping the sigmaa to sigmaa' in the apparent performance equation, as
that would average out to the pools saturation level more fairly, and as you said, as it should not penalise the pools beyond its saturation level.

[staking4ada.org]

Many thanks ilap for your input. I have adapted my post accordingly.

[Umed_SKY]

@_ilap

So, the long term rewards, should converge to the expected value, relative to the saturation point ( sigma' ) and not to a smaller value (if the pool is oversaturated), what the sigma a would do if it’s not capped by some sigmaa'=min(sgimaa, z0)

This is my understanding too. Capping performance could be interpreted as a hard cap, where you would never see a pool earn more than x amount (as we saw on ITN), but having a reward cap while keeping performance adjustment unbounded could be considered as a soft cap that would eventually push a pool toward that maximum reward point beyond which there are no additional rewards.

[Klobbinger]

@_ilap

if it’s not capped by some sigmaa'

I’m not entirely sure what you mean by sigma a.

The current rewards formula as given in the docs will lead to the pool rewards to converge over time to R * sigma as long as the pool is not oversaturated and produces all blocks it’s supposed to produce and leaving the influence of pledge out of the equation.

[Klobbinger]

This might be interesting as well. I wanted to know, if a pool operator who saturated his pool soley with their own pledge would be superior to a pool running on delegator’s stake.

If we assume the pool is saturated by pledge only that means we can substitute sigma'and s' with z0.
You can try it yourself on paper, the result will be:

f(s=z0, sigma=z0):= R*z0

If the pool was only running on delegator stake with no pledge the formula can be reduced to:

f(s=0,sigma=z0):= (R*z0)/(1+a0)

Conclusion: Only pledged out (saturated soley by pledge) pools get the maximum optimal rewards if a!= 0. A pool powered soley by delegator’s stake has its rewards reduced. With the current value of a0= 0.3this means the rewards are reduced by roughly 23%!

So what’s with the rewards for saturated pools with any pledge values in between 0 and z0?

Let’s describe the pledge s' as a ratio of z0 :

s' = z0 * x

We’ll put that in the rewards formula and reduce it to

f(s=z0*x, sigma=z0):= R*z0*(1+a0*x)/(1+a0) 

We can see that the equation reaches its maximum for x = 1 .

Conclusion: The optimal pledge amount in terms of pool rewards is 100% pledge.

[_ilap]

I think you have misinterpreted my writing. I was talking about one part of the three main (apparent performance, reward function and ranking/desirability) that affect rewards, the apparent performance.
And sigma a which is in the apparent performance formula is based on active stakes while sigma in the reward function based on all stakes, these are two different things. And it is not capped like sigma in the reward one, meaning it is unfairly over penalise the saturated pools if it is not capped.

[_ilap]

@Klobbinger

Conclusion: Only pledged out (saturated soley by pledge) pools get the maximum optimal rewards if a!= 0 . A pool powered soley by delegator’s stake has its rewards reduced. With the current value of a0= 0.3 this means the rewards are reduced by roughly 23%!

Yes, it is known for long and it can be clearly seen in the simple reward formula, and is about for preventing (one type of) Sybil attacks.

[Klobbinger]

Sure it’s no secret. However there seems to be a lot of speculation on the actual impact of pledge on rewards and an “optimal” amount of pledge so I wanted to confirm it myself.

[Klobbinger]

Sigma is defined as the relative stake and sigma’ is relative stake capped at 1/k. They’re both based on actually staked Ada.

I don’t think it’s over penalizing. An oversaturated pool will win more slots based on their relative stake. Let’s say the pool has a share of 2 * z0 stake. Then it would produce twice the amount of blocks of a saturated pool but would only receive the rewards of a pool that had z0 share of stake.