ON HOLD: Flexible Inflation

[kianenigma]

Update July 17: Please note that this RFC for now is "on hold" until we add some basic parameterization to the relay-chain(s) as per polkadot-fellows/runtimes#364. This PR is a small subset of this RFC. Once this work is done, we can explore this RFC again.

[Ank4n]

Does this mean pallet-inflation would still take into account parachain slots for the inflation calculation? Since crowdloans are deprecated and core time in, I am wondering the relevancy of current logic (i.e. we might hit the saturation point of 60 slots pretty easily). May be we can push a sensible (and conservative) change in the first iteration itself?

[Ank4n]

We are parameterizing the ideal staking rate already which makes sense 👍.

[kianenigma]

It could take the auctions into account, but that is not correct anymore.

What I propose is to also alter the existing inflation rate to a fixed idea rate (eg. 75%), no longer taking the auctions into account.

My wording here is confusing, I will correct it.

[Ank4n]

What would happen if some era rewards go unclaimed (for more than 84 eras)?

[kianenigma]

pallet-staking removes all era points of an era n once 84 eras have been passed. It should similarly burn any funds that are left in the pot account of era n. I believe the WIP implementation should already be doing that.

[acatangiu]

nice!

[Tomen]

thank you for the proactive approach!

1. the basic concept looks good. The details go into the option of having a fixed inflation rate opposed to a fixed rate inflation rate. I would suggest to also reflect this optionality in the earlier parts of the RFC, as it might be part of the ongoing debate and should be made clear to the shallow reader.

2. If I read the RFC correctly, it opens two essential angles: Configuring via OpenGov and making future code changes easier to implement. This is very elegant and could be reflected in the early parts of the RFC. The ability to code alternative inflation rates makes it for example possible to build an emitting function that makes the inflation rate dependent on the current issuance and a targeted supply. I understand that the RFC is unopinionated, just pointing out how it can relate to current discussions by showing future paths of integration.

3. Discussing the drawbacks of potential over-engineering, I would suggest to discuss in the RFC how it would potentially be called from OpenGov. This makes it easier to deliberate on this. As an example of what would be plausible scenario for configuration:

What Gov wants:

• Inflation
  • Mint 100m per annum
• Distribution
  • Send 10m to the Treasury
  • Send 10% to account A
  • Send 30% to account B
  • Send 1m to account C
  • Send 5m to account D
  • Of the remainder
    • Send 50% to account E
  • Burn the Remainder

How could the extrinsic for it look like?

I think if we start from the extrinsic, we can deliberate if the feature set is matching this wish or not

[kianenigma]

Thank you for your comment @Tomen!

On points 1 and 2, the RFC implementation will indeed open many many doors. I did not mention a lot of them to keep the text concise, but I will advertise the possibilities more in the introductory sections.

In general, the exercise that we should do is for community members and stakeholders to propose a written description of what they wish to see, and I will showcase an example of what hte code for it would look like in this RFC. You have already done this in your comment, and I will get to it next:

What Gov wants:

Inflation
Mint 100m per annum

Distribution
Send 10m to the Treasury
Send 10% to account A
Send 30% to account B
Send 1m to account C
Send 5m to account D
Of the remainder
Send 50% to account E

Burn the Remainder

Before doing this exercise in your example, I want to ask you:

What do you mean here by 10% or 30%? 10% of whatever is left of the 100m at this point, or 10% of the total?

In general, the rule of thumb with making such things configurable via governance is that it is easy to express a value to be parameterized over governance. For example, the value 100m or the value 10%. But, it is harder to express a function in a parameterize-able way. For example, in your example, the overall inflation function is:

fn inflation(total): 
    pay(10%, T)
    pay(10%, A)
    pay(30%, B)
    pay(1m, C)
    burn
    ...

It is quite easy to tweak the 10%, 1m, A, B or T in this function. But, redefining the function itself (the order of pay, burn and such) is a bit harder.

At the moment, my RFC mainly focused on having a fixed function defined in the runtime code (upgrade-able via code upgrade) tweak-able values (upgrade-able via any governance means). It is possible to add some degree of parameterization to the function part as well. But, it is worth asking if that is needed or not as it would be another possibly over-engineered aspect.

[kianenigma]

I am deliberately closing this RFC because I am seeing that it is realizing more confusion than good.

The path so far:

• I started this RFC as a way to propose a very flexible, and moderately "programmable" way to configure the inflation model, making it more flexible and transparent.
• I did not specify at all what the final inflation should be in this RFC.
• In parallel, mainly due to the great work of @jonasW3F, the community agreed to move Polkadot to a fixed cap inflation model that actually does not need any flexibility. https://polkadot.polkassembly.io/referenda/1139
• So, this makes the immediate need for this nullified, and I/we have more important things to deliver (namely AssetHub and its migration).

The state of affairs:

• Polkadot has been updated in this PR to the final outcome.
• Kusama has retained its previous inflation model, except now it has pallet-parameters allowing adjustments to parameters like max inflation.
• Both runtimes have an "experimental" runtime API that wallets may want to start using to get a unified clarity on the state of affairs. I want to emphasize that it is experimental. In fact the one in Polkaodt has a bug that is only being fixed here.