Reflection on the current discussions
Hey everyone,
There have been extensive discussions in the forum, social media, and during the recent livestream. As expected, this topic evokes strong emotions and a wide range of opinions. I’d like to take this opportunity to reflect on these discussions, consolidate the options, and propose a way forward.
Here are the key takeaways:
- Most participants support reducing inflation.
- My initial proposal of a reduction to 8% has received significant backing.
- Many participants have also expressed a desire to reduce inflation even further.
In this post, I aim to align these options by focusing on a single change: whether we compute the newly total issuance of 8% on the total issuance after inflation or always on the total issuance when the upgrade goes live.
The following summarizes the two options:
Option 1: 8% constant inflation
MaxStakerReward: 85%max_inflation: 8%staker_inflation: 6.8%min_inflation: 6.8%- Treasury inflow: 1’155’539 DOT (per 24 days, growing at 8% annually)
- APR: 11.62% (at 58.5%)
- APR after inflation: 3.62%
The table below illustrates the development of the model over time.
| year | total_issuance | total_inflation | yearly_inflow_ | staker_apr | apr_after_inflation |
|---|---|---|---|---|---|
| 0 | ~1444688000 | 0.08 | 115575040 | 0.1162393 | 0.0362393 |
| 1 | 1560263040 | 0.08 | 124821043 | 0.1162393 | 0.0362393 |
| 2 | 1685084083 | 0.08 | 134806727 | 0.1162393 | 0.0362393 |
| 3 | 1819890810 | 0.08 | 145591265 | 0.1162393 | 0.0362393 |
| 4 | 1965482075 | 0.08 | 157238566 | 0.1162393 | 0.0362393 |
| 5 | 2122720641 | 0.08 | 169817651 | 0.1162393 | 0.0362393 |
| 6 | 2292538292 | 0.08 | 183403063 | 0.1162393 | 0.0362393 |
| 7 | 2475941355 | 0.08 | 198075308 | 0.1162393 | 0.0362393 |
| 8 | 2674016664 | 0.08 | 213921333 | 0.1162393 | 0.0362393 |
| 9 | 2887937997 | 0.08 | 231035040 | 0.1162393 | 0.0362393 |
Option 2: 8%, then gradually decreasing inflation
MaxStakerReward: 85%max_inflation: configured to start at 8%, then decreasingmin_inflation: equal to staker inflation- Treasury inflow: 1’155’539 DOT (per 24 days, growing at 0% annually)
This option does not lead to a fixed staker APR (giving the same staking rate), but rather lead to a reduction over time.
The table below illustrates the development of the model over time.
| year | total_issuance | total_inflation | yearly_inflow | staker_apr | apr_after_inflation |
|---|---|---|---|---|---|
| 0 | ~1444688000 | 0.0800000 | 115575040 | 0.1162393 | 0.0362393 |
| 1 | 1560263040 | 0.0740741 | 115575040 | 0.1076290 | 0.0335549 |
| 2 | 1675838080 | 0.0689655 | 115575040 | 0.1002063 | 0.0312408 |
| 3 | 1791413120 | 0.0645161 | 115575040 | 0.0937414 | 0.0292253 |
| 4 | 1906988160 | 0.0606061 | 115575040 | 0.0880601 | 0.0274540 |
| 5 | 2022563200 | 0.0571429 | 115575040 | 0.0830281 | 0.0258852 |
| 6 | 2138138240 | 0.0540541 | 115575040 | 0.0785401 | 0.0244860 |
| 7 | 2253713280 | 0.0512821 | 115575040 | 0.0745124 | 0.0232303 |
| 8 | 2369288320 | 0.0487805 | 115575040 | 0.0708776 | 0.0220971 |
| 9 | 2484863360 | 0.0465116 | 115575040 | 0.0675810 | 0.0210694 |
The following graph illustrates the metrics visually:
Other proposals
I’ve noticed some members of the community suggesting a significant reduction in inflation, for instance, cutting it by half to 5% or even more at once. However, I personally don’t support such a drastic change. Polkadot has developed into a complex ecosystem, and sudden, significant adjustments could trigger unforeseen second and third-order effects that are challenging to predict and might have detrimental effects. Additionally, a rapid decrease in inflation might undermine the stability of staking rewards, discourage participation, and disrupt the general balance. For example, a large reduction in staking rewards most likely forces many validators to drastically increase their commission, leading to even lower APY for nominators. Therefore, if we consider reducing inflation below 8%, it should be done gradually. This approach will allow us to monitor the ecosystem’s adaptation and ensure we make informed decisions based on observable impacts.
That being said, the process outlined below allows for community members that feel their preference is not captured by the proposals to add their own opinion.
Next steps
I want to remind everyone that this discussions aim to identify the most suitable parameter changes that have a good chance to be approved through a root referendum in the future. In the absence of better on-chain mechanics, we can construct a series of Wish-For-Change (WFC) referenda that run in parallel to choose between competing proposals. The referendum with the highest support is arguably the best candidate to put forward for a root referendum.
From my perspective, there are three referenda that help us obtain more clarity.
- WFC 1: Keep 10%
- WFC 2: 8% constant.
- WFC 3: 8% then decreasing
At first glance, WFC 1 (“Keep 10%”) appears to be somewhat redundant, because people could just vote “NAY” on both WFC 2 and WFC 3. There is, however, a stronger signal in observing WFC 1 being approved with the highest support, because it means that there is not another referendum that is likely to win with the current set of voters.
Using a set of WFCs has several benefits:
- It provides an objective, credible indication of which option is preferred, granting legitimacy through OpenGov.
- It undergoes the same voting mechanism as a later root referendum (in contrast to making off-chain polls).
- It is a permissionless process, allowing any part of the community that feels unrepresented by the proposed WFCs to initiate their referendum with parameters they find more suitable and potentially gain more support than other proposals.
- Spam is limited by the fact that a referendum needs a decision deposit of 20’000 DOT.
- While not being optimal, voting on different combinations of the proposals allows to express a preference order by the voters.
Important: The WFC referendum cannot be binding, meaning there is no mechanism to force the chain to update the parameters to the one specified in the WFC. It is simply a method to aggregate the opinion of voters through OpenGov and select a suitable candidate.
Rules
In the absence of a proper on-chain decision aggregation device for preferential questions, we need to use a set of WFCs as proposed above to narrow down consensus.
There are a few rules that I think make sense here.
- Only a WFC that is
executedcan be considered a candidate (i.e., it must be gathering enough approval). - If one or more WFCs are accepted, the one with more AYE votes (weighted with conviction) is considered the preferred candidate.
- WFCs should be run mostly in parallel.
This setup makes voting generally straight forward. A voter votes AYE on their preferred proposal and NAY on all others. If a voter sees their most preferred referendum failing, they might vote “AYE” on the secondly preferred referendum.