Polkadot's Economics: Tools to Shape the Forseeable Future

[jonas]

Introduction

With the network maturing and an increasingly clear path forward (Polkadot 2.0, JAM) it is a good time to revisit and tweak some of the economics around Polkadot. This post summarizes recent technical developments that allow initiatives to address current pain points and enhance the network’s overall functionality. It serves as a starting point for a well-informed community discussion on whether and how these mechanisms can be used. In this post, I will mostly focus on introducing and discussing the mechanisms without delving too deeply into specific parameters. Once there is general consensus on the utility of these mechanisms, we can then focus on finding suitable parameters.

Goals

This post aims to achieve several goals:

• Inform and update the community about recent technical developments and their current status and timeline.
• Outline how these mechanisms could collectively address recent issues that have been heavily discussed within the Polkadot community.
• Initiate an informed discussion that considers the broader picture of these changes, which are potentially closely related.

These insights can be used to discuss frequently raised topics in the Polkadot community, such as sustainable Treasury inflow and adjustments to overall inflation.

Current situation

This is a good timing to kick off discussions around changes to Polkadot’s economics, because significant progress has been made on necessary changes to the code to provide us with the tools needed to efficiently optimize Polkadot’s economics in the near future.

Additionally, we observe substantial Treasury outflows backed only by continuously diminishing inflows. The next graph shows the inflows (blue) and outflows (red) with the net-inflow (black).

While outflows have continously risen, inflows have decreased because the staking rate is approaching the ideal staking rate. The following graph shows the percentage of era rewards diverted to the Treasury.

This dynamic has lead to a significant reduction of treasury balance in recent months. Note that ~5M DOT moved to AssetHub and ~2.6M DOT on Hydration, while there are open spends of ~5M DOT for active bounties. These numbers are not part of the next graph.

While the Treasury still holds sufficient funds, we should act and get to a more sustainable inflow, instead of relying on the somewhat less predictable mechanism that currently funds the Treasury.

New Developments

Mechanism 1: Fixed Treasury Inflow

A while ago, I proposed to divert a fixed part of the inflation directly into the treasury to become independent of the ‘staking inefficiency’ mechanism that currently makes the overwhelming inflow to treasury. Since the RFC process wasn’t established then, discussions happened mostly in the forum post. Despite the absence of any measurable signal about the opinion (such as a Wish-For-Change vote), there appeared to be broad support for the mechanism. This led a few engineers to start implementing this feature.

In the meantime, changes were made to alter the calculation of the ideal staking rate to prepared the system for an increased staking rate caused by large unlocks from the first wave of auctions and a general outphasing of parachain slot auctions in favor of agile coretime. While the increase of staking rate took longer than I personally anticipated, the analysis in this post shows that there has been a net benefit for stakers due to that change. Due to the way the system works right now, that also means that the Treasury receives smaller inflow. Especially in the recent weeks, the gap between the ideal staking rate and staking rate dwindled leaving the Treasury with lower inflows.

While the Treasury is still potent and has sufficient balance, we should strive for a quick introduction of the code change proposed in the original forum post. Luckily, the respective upgrade has already been developed, audited, and deployed on Westend and should be ready to be deployed on Polkadot during the upcoming release cycles.

What changes?

The MaxStakerReward is a new storage value that can be accessed by governance and determines the percent of the total eraRewards (i.e. inflation) that goes to stakers. Conversely, 100% - MaxStakerReward would directly be minted to the treasury. The mechanism is already live on Westend (Chainstate → Staking → MaxStakerReward) and we’ll hopefully see this live on Polkadot soon. On Westend, for example, the MaxStakerReward is set to 80%, which essentially means that 20% of total inflation goes to treasury.

Status & Timeline: The mechanism is audited, live, and tested on Westend. Depending on the release schedule drawn by the Polkadot Fellowship, this could take around 1 - 2 months to be live.
Impact: It makes sense to merge this change in any case, because it could be initiated with MaxStakerReward = 100%, which corresponds to exactly the current situation. In a later referendum, the community can change the parameter. Alternatively, the community could determine a different parameter with which the update could be shipped. This mechanism would lead to a sustainable and predictable inflow to Treasury.

Mechanism 2: Parameter- / Inflation Pallet

Currently, the inflation calculation (including parameters such as the max_inflation (which is currently set to 10%), is deeply embedded into the runtime and cannot be changed without a runtime upgrade itself. This is not optimal and changing code around the inflation through this method comes at a significant risk. To solve this issue the Parameter Pallet has been developed, that abstracts several parameters from the runtime and makes them accessible by OpenGov. RFC0089 proposed by @kianenigma complements this initiative of making allowing direct access to these parameters.

What changes?

The parameter pallet exposes crucial parameters of the inflation system directly to governance (potentially on different OpenGov tracks). The most important ones include:

• max_inflation: Total yearly inflation.
• ideal_rate: Ideal staking rate that could be a fixed point.
• falloff: determines the shape of the curve that sanctions the rewards for stakers for not being at the ideal rate.

Status & Timeline: The mechanism is audited, live, and tested on Rococo. Depending on the release schedule drawn by the Polkadot Fellowship, this could take around 1 - 2 months to be live.
Impact: As the previous mechanism, the abstraction of the parameters from the runtime does not necessitate any change. Once deployed, we can start referenda to change the various parameters.

Mechanism 3: Unbonding Queue

RFC0092 introduces an unbonding queue to the Relay Chain that allows for a flexible unbonding time from staking, depending on the overall stake that is currently unbonding. That means, in times where not many users are unbonding, stake could be unbonded as quickly as two days. It balances security considerations with UX improvements and will likely result in a large (expected) decrease of unbonding time for users. This also offers a good compensation of a lower staking reward (caused by lower inflation).

This addition to Polkadot would further increase its agility and vastly improve the UX for stakers.

Timeline: (TBD) Necessary approval by the RFC by Fellowship first, then code & audit.
Impact: This change would significantly reduce the expected unbonding time for stakers, while making sure that there is always sufficient stake slashable to provide sufficient economic security.

How does it all fit together?

The mechanisms discussed above paint a clear path for the community in the near future. Once the necesarry code is live, Treasury inflow can be fixed leading to a sustainable and predictable inflow, yearly inflation and other economic factors can be adjusted and enacted through governance. With a potentially lower inflation (and a higher inflow to Treasury compared to the current situation), staker rewards necessarily drop. A quicker unbonding would compensate for that.

Special thanks

I would like to thank @gpestana for his invaluable support in countless discussions about the current state of the implementation and helping with calculating numbers using code very close to the actual implementation. I’d also like to extend my gratitude to @pavla and the rest of Parity’s Data team for allowing me access to their infrastructure and supporting me to get the data I need to make well-informed analyses.

[lolmcshizz]

Great summary of how all of the pieces are coming together.

Very pleased to see that Fixed Treasury Inflow and Inflation Pallet are literally just waiting for deployment

Clearly the conversation is going to quickly move towards specific numbers - so I’ll kick this off now with:

• MaxStakerReward to 80% - meaning a fixed 20% of inflation to the Treasury (and other pots!)
• max_inflation reduced to 8% from the current 10%
• Once Optimistic Project Funding is implemented, 25% of Treasury inflows to be directed towards this “pot” (5% of inflation)

The above would see:

• Inflation reduced
• Single-digit DOT inflation
• Retain double-digit staking APY
• Consistent Treasury inflows markedly higher than current levels
• Significant inflows for Optimistic Project Funding - luring in talented builders

[kianenigma]

Thanks for the detailed explanation of what has been done @jonas!

Mechanism 2: Parameter- / Inflation Pallet

Given the need to quickly make the existing parameters of the inflation system configurable, without fully implementing RFC89, I support the idea of introducing the pallet-parameters to the existing RC runtimes, keep the existing hardcoded inflation forumula, and instead just make the aforementioned 3 parameters (max_inflation + ideal_rate + falloff) configurable using pallet-parameters. This work can precede pallet-inflation + RFC89 and will remain mostly compatible with it. The implementation of this work is relatively simple and I encourage any community member or PBA Alumni to take it up. I will be supportive of providing technical support as guideline as needed.

Mechanism 3: Unbonding Queue

A few technical pieces of work needed to be done in pallet-staking to enable RFC92 and the staking engineering team within Parity would likely implement it with high priority.

[Pheeb]

Treasury spending is out of control because it is a large pot that attracts the wrong type of attention. A small treasury with balanced inflow/outflow and a budget should be the goal. Let the funds run low… Force fiscal conservatism. Let’s make sure we get good value for the money we do spend.

[YungBeef]

Great to see all of this shaping up.

I expect that this will remain true, but there is one thing I want to highlight, which is that (most of the time) stakers should be at least protected from inflation, in order to not have their share of the network diluted. Inflation and staking rewards transfer network share from those that don’t help with security to those that do, and the treasury. While it wouldn’t be the end of the world, I think it would be very bad if even stakers are losing to inflation - being robbed by the treasury, essentially.

Obviously there is no way to guarantee this because the staking rate varies, but stakers would be protected at a 50% staking rate with MaxStakerReward = 50%. With that in mind, I think 65-75% would be a reasonable value for MaxStakerReward.

[polka.dom]

@lolmcshizz

MaxStakerReward to 80% - meaning a fixed 20% of inflation to the Treasury (and other pots!)

@lolmcshizz What’s the general reasoning behind the 20%? Not against, would just like to kick off a discussion on budget/taxes.

[HopeClary]

I agree with some of your shared views here regarding strategic budget, I have voiced this opinion as well. The word Chaos is used a lot because when standing up breakthrough products, such as a large voting DAO, people are experiencing pain points.

I don’t think letting things get to danger levels is a good approach. I am grateful this type of work and analysis is being accounted for, as part of Polkadot’s future structure. Please note that Open Gov Watch only started a few months ago. Behavior and analysis of data capture for current trends to form plans doesn’t occur overnight. I understand there have been many bad actors. Process improvements are currently in order and from what I can see they’re starting to roll out. even from the “grifters segment” being added to The Kus. Maybe adding a wall of shame on the Wiki could also be an option? If I google a name and it came up there, that should deter some folks?

[lolmcshizz]

Hey! The 20% of inflation came from this original banger of a post from Jonas when sustainable treasury inflow was originally discussed: Adjusting the current inflation model to sustain Treasury inflow - #27 by jonas - it “feels” like a reasonable place to start imo

[Abdulkadir00004]

Really, happy to see this discussion been taken more serious. This break down is very important as it will enable interested community members to understand the current state of the Treasury and the need to make certain decisions.

[Juba.K]

@jonas @lolmcshizz

It’s great to finally see real steps being taking place to implement changes in Polkadot token structure & demand.

In the past month we have seen the following come to light for discussion / wish for change

• staking unbond time reduction
• inflation cut
• supply cap

I believe that we are at an inflection point with Polkadot - one that could re-introduce us into the spotlight as a very competitive & attractive blockchain project - and it all starts with making the DOT token competitive across the wider digital asset space.

One topic for selling pressure which is not widely addressed is the staking rewards being too lenient, as in, stakers wish to, attempt to and even successfully live off of their staking rewards. This has set a precedent in where it has been acceptable to constantly sell staking rewards DOT - which is arguably the most immense selling pressure on the token itself.

Infinite Supply + High Inflation = a race to the bottom. Before the ‘securing the network’ comments roll in - there won’t be anything left to secure if there aren’t any people buying DOT.

The time has come to implement an aggressive framework which aims to incentivize holding dot > selling dot or at least reducing the amount of DOT sold due to scarcity (supply cap).

This un-bonding proposal is a step in the right direction - the first of a 3 prong approach which may spark interest in token supply & demand and staking participation, however, in my view, is still much too lenient to create the impact needed to propel DOT back into the spotlight.

Still - the staking reduction could play a nice complimentary role to a hardened token structure and am very in favour of all changes in this area.

With all of the developments under way, pushing a token revamp narrative may be what shines the spotlight on all the incredible things happening for the native Polkadot network and its ecosystem projects - it will literally sell itself to the broader market much like early 2021.

This comment is not meant to be taken as technical or financial advice - this is just a personal opinion from a DOT holder.

J.

[jimmy-tudeski]

First, KUDOS to @jonas for doing an outstanding job highlighting the recent technical developments and proposing economic adjustments for Polkadot. The detailed breakdown of mechanisms - treasury inflows, parameter adjustments, and the unbonding queue is a great foundation for future discussions about the final parameter tweaks that will be enabled to be modified with referenda.

Building on this I like to drop my support in the first place to reduce staking rewards with enhanced flexibility and liquidity for stakers. Reducing staking rewards while offering more flexible unbonding and agile access to staked funds is a viable strategy supported by various research studies.

These studies show that stakers highly value liquidity and the ability to quickly access their funds, even if it means slightly lower returns. By shortening unbonding periods, Polkadot can attract more participants who appreciate the reduced opportunity cost and increased flexibility, ultimately enhancing overall network participation and security.

I think we should start with the MaxStakerReward parameter set to 100%. This way, we keep things as they are initially and let everyone get used to the new system without any sudden changes to our staking rewards. Once this baseline is established, open a discussion about tweaking the parameters of fixed inflation going to the Treasury.

At the same time, we need to get serious about how we’re spending Treasury funds. We can’t improve Polkadot economics focusing only on the income side. We must carefully revise the spending approach. Let’s implement a thorough review process for funding proposals, making sure we do proper cost-benefit analyses and set clear milestones. Transparency is key, so detailed reports on spending and project outcomes should be published regularly. Also, regular audits and accountability measures will help ensure our funds are being used effectively.

Given the critical need for both flexibility and protection against potential manipulation by large stakeholders, how should we best approach the implementation of changes to the MaxStakerReward and inflation parameters within the OpenGov framework? Should we initially manage these adjustments through the Technical Fellowship or the Root Track to ensure the necessary oversight and stability? While opening up a parameter pallet to OpenGove mechanics might sound exciting it also introduces risks. Without careful design and safeguards, there’s a chance that large holders (whales) could game the system to their advantage. That’s why it’s crucial to start with these parameters under control.

I also have some concerns about adjusting the MaxStakerRewards parameter and inflation rate simultaneously. Altering both at once can make it difficult to isolate their impacts and could lead to unforeseen issues. We should consider detailed economic modeling to determine the final numbers for inflation and the percentage directed to sustainable Treasury inflow. By understanding the economic implications thoroughly, we can make informed decisions that ensure the stability and growth of the Polkadot network. Starting with a controlled adjustment, such as initially setting the MaxStakerReward to 100% to maintain the status quo, and then gradually introducing changes based on thorough analysis and community feedback, would be the most reasonable approach from my perspective as a long-term Polkadot supporter, staker, validator and Polkadot resident :).

This ensures we have a clear understanding of each change’s impact before moving forward with further adjustments. By taking these steps, we can create a more balanced and sustainable economic model that benefits everyone in the Polkadot ecosystem.

[jonas]

I agree that 8% total inflation with 20% to Treasury are reasonable parameters to start with and see how things are going. Treasury would see (at current issuance) 64’000 DOT daily inflow.

An additional point that we should discuss is that adjustments to the inflation and Treasury inflow would not change the system around the ideal_rate. But, with a fixed inflow to Treasury, sanctioning stakers further (if the system deviates) would not be desirable.

Therefore, we should also discuss the ideal_rate that could be fixed with the parameter pallet. It is important to note that the whole system originally was designed to nudge the allocation of DOT to a sensible ratio between liquid tokens, bonded tokens in staking, and bonded tokens in parachain slots. With the latter missing, there is, in my opinion, not much reason to keep this system. There already is a natural mechanism that regulates the ratio between staking and liquidity, which is expressed by the following relationship:

• Too little DOT in the staking system → Higher potential APY → People enter staking to profit.
• Too much DOT in the staking system → Lower potential APY → People exit staking to use DOT otherwise.

With an unbonding queue as proposed in RFC0092 this system should have the necessary flexibility to regulate.

To achieve this quickly, we could set the ideal rate to some high value (e.g., back to the original one before parachains = 75% or even higher) and significantly reduce the falloff parameter that regulates the impact of a deviation between the ideal rate and the actual rate. With this, we’d essentially be much more relaxed with deviations (especially below the ideal rate).

Eventually, we could also think about removing the system that targets an ideal staking rate and let the system fully self-regulate based on the aforementioned mechanism and only rely on a fixed inflow for the Treasury.

I’ll be sharing some numbers for APY and Treasury inflow under different parameters soon.

[jonas]

I think you and others are pointing out an important thing, namely that Treasury funds are and will be a scarce resource. The goal of having a fixed Treasury inflow should not be to offset any spending spree. Instead, it should give more predictability to work within a reasonable budget. This might mean we see times where outflows continue to exceed inflows but also, necessarily, where outflows need to be restricted to allow the Treasury to replenish.

Starting conservatively and set MaxStakerReward to 100% is understandable but the time appears to be of the essence with the gap being very narrow between the ideal rate and the actual staking rate. Current inflow from inflation to Treasury has dwindled to 1.7%. Depending on the Fellowship and their release schedule I was told that the upgrade is out another 1-2 months. Initialising the upgrade with a MaxStakerReward of 100% would delay a fixed inflow additionally by at least the time for the referendum. If the staking rate remains around the current level, that would mean several spending periods that are backed only by little inflow.

Another important point you mention is the question on which governance tracks these changes are decided on. We can either choose existing or create new ones. Given the impact of any changes, I think it makes sense to set the strictest requirements for them (similar or equal to root).

[jimmy-tudeski]

Thx for Your reply Jonas, appreciate it a lot. I was just thinking shouldn’t we also think about some outflow restriction mechanics?

While a fixed Treasury inflow of 64,000 DOT per day as proposed (1,920,000 DOT per month) provides a stable and predictable funding source, it is still insufficient to cover the high levels of outflows (2,500,000 to 3,000,000 DOT). And we see the high spend trend is in full swing thus IMO to ensure long-term sustainability, Polkadot shareholders must put a significant focus on controlling outflows.

Additionally, I understand that flexible unbonding and setting the ideal staking rate back to some higher values - as You propose for example 75% is to keep up the APY and make the ecosystem more agile to get more people interested in securing the network. As I understand flexible unbonding is here to attract those who are sitting idle and not staking because of the high opportunity cost coming with a long unbonding period limiting other income-bearing opportunities, like participation in ecosystem DeFi incentives for example.

My other question would be - can this impact the governance voting preferences concerning conviction voting? Right now if the minimum unbonding is 28 days and x1 conviction corresponds to that time, people are more willing to use 1x conviction for their votes not to be locked longer than eventually unbonding. Many people who vote with higher conviction do it to some extent because the minimum unbounding is 28 days.

(if I have to wait 28 days and it’s already hard to catch market fluctuations, have a first mover advantage in DeFi liquidity incentives, or do arbitrages if I stake, I vote with close to max convocation as I know I will miss those opportunities no matter the conviction so I just do not bother)

If we will have agile unbonding, how can this impact the conviction voting preferences? Asking as this came to my mind just now.

[jonas]

I am not sure what you mean by “outflow restriction mechanics”. There is a natural limit in the sense that there is no way for the Treasury to spend more than it has. Apart from that, I don’t think there should be any additional (protocol-level) restrictions to spending to allow for full flexibility. Having said that, it could be quite useful for us all to come together and discuss long-term sustainable spending. But IMO that should happen on the social layer, which hopefully translates into voting patterns. Potentially the decreasing Treasury balance will lead to such discussion.

With regard to conviction voting: right now, the 3x multiplier (not 1x) corresponds to a 28 day locking period, which means that it comes for free if an entity is already staking. There is actually already a section about that in RFC0092 where we argue that the current locks might fit even better for a system with unbonding queue. In a nutshell, the argument is that a higher-than-0.1x lock does not come for free anymore and entities still deciding to lock themselves for longer have rightfully more weight in governance.

[mister_cole]

I understand the benefits of this plan, and it is a fact that low-involvement tokenholders are often frustrated by long unstaking times.

That said, I help moderate the Discord servers where those users often come with questions and complaints, and the biggest complaint is that Polkadot is complicated. Things that are simple on other networks are difficult here (we have two different ways to stake. One of them doesn’t allow voting; one does. One requires selecting validators; one doesn’t. One has auto-claiming and -compounding; one sorta sometimes does depending on the pool, I think, maybe. What is this Existential Deposit thing? What are Decision Periods, Spend Periods, Conviction Voting, and Vote Delegation? Why did ChaosDAO do this?, etc.).

There are good reasons for these complexities, but they frustrate users who divide their attention (and tokens) among many different ecosystems and/or who have grown used to other (simpler) ways of doing things.

So as much as I like this proposal, I can guarantee that it will baffle and frustrate low-involvement users, and I’m not looking forward to trying to explain it to them. Users like mechanisms that they can understand easily and do quickly. Faster unbonding satisfies that second need, but “a flexible unbonding time from staking, depending on the overall stake that is currently unbonding” resoundingly thwarts the former.

This is not meant as opposition to the scheme but as a note of caution on behalf of the tokenholders who will struggle to understand it. It is my belief that the vast majority of DOT tokenholders are in this category.

[Gr33nHatt3R]

It’s hard to argue with any of your points. As a fellow mod, I see these same complaints. I think a lot of it is just part of NPoS. We nominate our own set of validators, as do the pool operators.

I believe they really need to get the ball rolling with Nomination Pool voting. It’s been a long time coming. I also think UIs could opt to always select Nomination Pools instead of even giving a choice right off the bat. You could have a switch to set it to “Advanced” mode or something similar, but by default, select the easiest route for users.

I am curious if we really have a true need for an existential deposit at all. Other chains seem to do okay without it. I think it could at least be lowered and locked automatically upon account creation as a deposit until you remove your account. The user shouldn’t have to worry about their account being reaped. That deposit should be locked until the account is closed.

There are so many things that could make this whole process smoother for the end user. But why ChaosDAO did it is the true question I cannot answer.

[jonas]

@mister_cole: Thanks for sharing, your perspective is very valuable having direct access to these types of users. At least from my anecdotal experience a lot of users that are barely involved with Polkadot and just want to hold DOT and stake some, are quite allergic to the 28 days unbonding duration. Some are surprised that it even exists and they only find out once they try to unbond. My hope would be that the unbonding queue would also alleviate a lot of pain points for these users.

Let me give two points of why I think the queue might not be making things worse for the users you describe.

1. It is true that the unbonding time is flexible generally but in practice it will (probably) be around 2 days most of the time. Below, I show the histogram of unbonding days of the empirical fitting. Together with the fact that unbonding is not such a frequent task, many users might not even find out that the queue is flexible because every time they unbond it’s just around 2 days.

   

2. It is also important to note that the queue makes the potential unbonding time flexible given the current situation of all unbonds. But, the moment a user is considering to unbond, UIs can give them an exact time that they see their stake unbonded.

So, while the whole thing might be complex under the hood, the only thing (if even) a user needs to know is that the unbonding time is flexible and can be between 2 and 28 days but they know exactly how long it’ll be once they decide to unbond.

@Gr33nHatt3R: Your question about ED is a bit off-topic but from what I understand is that Polkadot needs it for security. I am not an expert here, but I think the reason is that we use a lot of merkilized data structures and every account needs to be embedded into that structure adding load to it. The problem is that all queries to these trees get more expensive the bigger they get, meaning that adding a hundred thousand accounts that are not used (which is more likely if ED is lower), makes it more expensive to handle and work with any existing account. This is an obvious attack vector that we need to minimize with an ED. Other chains might not rely on this merkilized data structure (they just keep a “normal” database) or they don’t care.

I think it could at least be lowered and locked automatically upon account creation as a deposit until you remove your account. The user shouldn’t have to worry about their account being reaped. That deposit should be locked until the account is closed.

That’s how it should work already if users are not creating the extrinsics themselves (i.e., use some type of Wallet). These apps should (and already do) abstract away that complexity and e.g., only allow a transferKeepAlive(). That is not to say that an ED creates UX pain, but it needs to be solved under the assumption that we might always need an ED (which might potentially be much lower) and even if we move balances off the Relay-Chain.

Thanks for the comments, but let’s keep it on-topic

[Gr33nHatt3R]

Much appreciated Jonas! My apologies for going off-topic.

[dotsama]

I’m not sure if I’m understanding correctly, but if this goes into effect from OpenGov, shortly we’ll be able to:

• Determine how much of the inflation goes to the treasury with the MaxStakerReward variable. In the most extreme case, all the inflation could go to the treasury.
• Determine the annual inflation of the protocol through max_inflation, where you can technically set it to 0% or to hyperinflation.

Sorry for being so enthusiastic, but this should be rejected immediately. It’s like giving a match to a pyromaniac. There is absolutely no incentive for those who vote in referendums to take care of the budget. There is only one thing that stops them, and it’s called budget constraint.

If you give serial spenders the money printing machine, they’ll spend it all!

What guarantees that the whales (state bureaucrats of OpenGov) will restrain themselves in spending if they simply print more money when they run out? ARE WE ALL CRAZY?

Polkadot needs predictability. This is sheer madness. Sorry for saying it like this.

Before these changes, leave everything as it is! If the budget runs out, the budget constraint will do the job that the whales’ serial spenders don’t want to do.

On the other hand, BTC and ETH have been successful because their monetary policy has been unchangeable. How lightly you talk about inflation percentages and allocations to the treasury. PLEASE don’t ruin investors.

I understand that something needs to be done about the current inflation of the protocol, but you can never give this power to OpenGov in a direct vote. The change must be ONE and definitive. We absolutely must provide predictability for the next 20 or 30 years.

I’m not just here to complain, but I also bring my proposal for inflation and the treasury. A definitive proposal for the next 100 years.

Inflation Proposal:

Change the current 10% annual DOT emission to a tail emission, where a fixed amount of DOTs is emitted per block forever.

Benefits of the Proposal:

• Economic Predictability: Provide greater predictability to the circular economy of Polkadot.
• Payment Stability: Ensure constant payments to the network validators.
• Consistent Supply: Ensure a consistent supply of DOTs for nominators and the treasury.
• Inflation Flexibility: Gradual reduction of inflation if the total circulating supply increases due to emission. Gradual increase of inflation if the total circulating supply decreases due to potential burns of DOTs exceeding monetary emission.

Treasury Proposal:

A fixed minimum percentage of the emission will always go to the treasury.

Benefits of the Proposal:

• Economic Predictability: Provide greater predictability and gradual adjustment over the years in which the annual budget must be spent.
• Budget Constraint: Remove incentives for those proposing referendums to keep scamming investors with ridiculously expensive proposals when there is no abundant money in the treasury.

Proposal for the Falloff Parameter:

Determine the shape of the curve that sanctions rewards for participants for not being at the ideal rate in a fixed and permanent manner. With the sale of CoreTime and a predictable and fixed emission, an ideal permanent staking rate can also be foreseen, since with the elimination of crowloans there is no reason to keep changing this rate over time.

Conclusion:

We need to strip OpenGov of its powers, not give it more tools when they only represent a small percentage of the full interests of the protocol. Please, I hope my words are heard.

Best regards.