Proposal for Adjusting Polkadot's Inflation System: Reducing Issuance and Complexity

Governance
21

I agree with Jonas and share a few additional ideas here:

Get rid of the 24-day spending cycle

Like the ideal staking rate, it is a historical artifact that is no longer necessary.

The 24-day spend cycle determines when spend_local() spends are executed and when the burn is applied. With the introduction of the new spend() extrinsic, the 24-day spend cycle has become obsolete. Additionally, the 24-day waiting period is very unpopular and there doesn’t seem to be a good reason to have it.

Action Items:

  • wrap spend_local() such that it executes a local spend() immediately.
  • to maintain the burn, introduce 2 parameters. One for burn frequency and one for burn amount of the Treasury.
  • remove all other code artifacts that relate to the 24-day spend cycle

Transition to linear or sub-linear inflation

Currently, Polkadot has slow exponential inflation. This is completely fine if you understand the economics behind it (and inflation is constrained). The problem is that people do not understand the economics behind it and it is impossible to sufficiently educate them about it.

To me, it has become evident that a theoretically sound model is still not fit for the market if people reject it.

Exponential inflation has a very negative perception. It is a bad meme. Thus I strongly believe we should transition to a linear inflation that emulates current values but makes them more tangible.

Example

Total Inflation: 100m DOT per year (~70% of what we have now)

  • Stakers: 75m DOT per year
  • Treasury: 25m DOT per year

Comparison

upsides:

  • simpler to understand, better memeability
  • with linear inflation the inflation rate diminishes over time (100m @ 1b supply is 10%, 100m @ 2b supply is 5%)

downsides:

  • diminishing relative security budget over time (but it’s totally manageable to react in time)
  • essentially none

Direct some coretime revenue to the Treasury

Currently, the Treasury has ~2 sources of income:

  • inflation
  • tx fees
  • (slashes, randos sending tokens to the Treasury, etc…)

TX fees are a concept of monolithic L1s where everything happens on the L1. Since Polkadot is more of a rollup host, coretime revenue is an analogue of tx fees in our system.

I think in the long run it would be ideal to reduce the dependence on inflation and instead incentivize the treasury to optimize for coretime revenue. Building a parameter that allows splitting coretime revenue between burn and Treasury inflow would be a great starting point.

7 Likes