Thanks for your feedback Serotonin ! I think the question about reward formula is an important topic and i’m happy as well to see other people feeling concerned about it.
Regarding the two points you raised:
I agree that skewed version, curved version and even more skewed+curved combination make the function more complex than the original one, but I am afraid a “single parameter” function will always have some flaws, may it shape a linear, or non linear reward profile. Besides, if we would simplify it a bit, i would get rid of the (subtle) adjustment (1-P*(1-S)) from the original formula, so that it would lead to a simpler, yet rich, form:
Reward = R * Sigma * (1 +( b0 + a0 * P) * S) / (1 + a0 + b0 / P)
with Sigma pool stake fraction, P = pledge ratio (i.e. pledge amount / pool stake), S = pool saturation ratio. The “curved” version would just consist in replacing P by c§ with c the curve sub-function.
The a0 factor is here to give some benefit to higher pledge whereas b0 factor allows to penalize too highly leveraged pools (i.e. where Leverage = 1/ P is too high).
If we wish to make the function evolve, i am pretty convinced it should be made in a “continuous” way, i.e. ensuring that new formula is backward-compatible with previous existing one. That’s why i kept a0 factor, even though i also think it should not necessarily be tuned back to 0. If we should put it back to zero in the skewed (simplified) version as written above, we would get something like:
Reward = R * Sigma * P * (1 + b0 * S) / (P + b0)
For small P the reward would then be mainly proportional to P (inciting growing pledge vs having small pledge) but as P will increase, the divider (P+b0) will have an amortization effect of this benefit, mitigating then the advantage given to very highly pledged pools. If combining with curved c§ then this control over high pledge benefit is even more emphasized, thus countering the “flat” marginal benefit phenomenon araising with the a0 only formula.
If i understand correctly your proposition, the reward function would be defined as (with equivalent notations as above):
Reward = R * Sigma * min(1, (L * PledgeAmount + B) / TotalPoolStakeAmount)
or with my notations:
Reward = R * Sigma * min(1, L * P + B / (S * GlobalStake))
which if you redefine your baseline B in % of global stake instead of in absolute ada amount, would then lead to:
Reward = R * Sigma * min(1, L * P + B(%) / S)
Reward = R * z0 * min(S, L * P * S + B(%))
I like the proportionnality wrt P and the fact that above a certain level of P, there will be no additional benefit (in that way it’s similar to what the curve function would bring, even though it’s a bit more brutal here).
What seems to be more problematic is the presence of the term B / S, whatever the value you choose for B (unless you put it to zero which would lead to an oversimplistic formula).
- First problem i see is that the reward “efficiency” is a decreasing function of S, i.e. a pool will naturally be penalized by growing its saturation ratio. This is a bit unnatural in terms of incentive.
- Second problem: the reward efficiency will be optimal (maximal) as soon as the saturation is low enough S << B% which is also a bit counter-intuitive.
Yet, besides this pure “efficiency” argument, If we look at the effective reward, it looks not too bad and quite well balanced, as a pool with zero pledge would still have a theoretical reward Reward (P = 0) = R * z0 * min(S, B(%)), and as soon as you choose a not too high value for B, this should not create too much advantage to very small pools.
Conclusion: all propositions looks interesting ! I like Skewed & Curved for the flexibility it offers in terms of function shape, for its strict penalization of non pledged pools, and for the backward-comptibility with current formula. Despite its non backward-compatibility, I like your proposition as well, as it embeds in a very simple form the ability to both “incurve” the reward benefit of high pledge (even though it does it a bit less smoothly than the curved reward offers), while still penalizing “significantly” low pledged pool (as soon as B is not too high).
Question now : how could we convince the “dev in charge” to implement these propositions, thoroughly test them in a testnet env and eventually decide (through a CIP voting ?) to put one of them into production ?