Halve OSMO Inflation

[JohnnyWyles]

@Seppmos

To me it boils down to the same question as with LP incentives. The ultimate goal should be for both, to be fully funded by the chain or in other words the CP, if we aim at lowering inflation to zero one day. Hence, why can’t we do this rn?

This part is key for both. As long as we have inflation it doesn’t need to happen right now, but it would need to if we had 0 inflation.

I think we should skip this for now because all of these additions add extra complexity to what could already be a contentious change. Although I originally suggested the funding via the Community pool, lets make a separate proposal out of that as some point.

Another chain to reference is Kava. They went to “zero inflation” last year, but replaced inflation with heavy spending from the community pool, resulting in a similar impact on the circulating supply, so the narrative impact doesn’t seem to outweigh the economic here.

[Alex1]

Like many have said, I think the CP is big enough now so we should stop all funding from inflation and even reduce the share from revenue.

Reduce Dev share to 15% & reduce inflation to 0% or 2% and redirect to stakers most of it. Then use the CP carefully to fund what’s necessary. Agree with Seppmos on the LP incentive on a 3 months or 4 months renewal period from CP.

[LeonoorsCryptoman]

@willbbtc

I don’t think the duration of a parameter’s life matters much. What matters is that once it’s done we don’t go back. I prefer to compare OSMO to ETH as both are primarily a DeFi environment while BTC is a commodity money.

Ethereum, at multiple points in its history, has cut inflation coming out of each newly created block. What has mattered the most is that inflation has never been re-increased for security or sustainability purposes. The same has to be achieved he

Yeah, I am more referring about making sure what an investor gets when she/he decides to invest.
If we mingle every x period with the inflation parameters, we don’t get a predictable outcome, which is bad from an investor point of view. So therefore I would personally go for some stable scenario, which provides clarity to investors.

[JohnnyWyles]

Summary and proposal text for tomorrow:
I hope this is a suitable summary of the current actions to be taken that are directly relevant to the inflation reduction proposal.

This proposal sets the inflation reduction interval to 365 epochs, triggering a reduction in the epoch after this proposal passes.

The reduction is also set to two-thirds, resulting in a new inflation rate of around 3.3%.

Unless further parameter changes are implemented, this sets a new reduced maximum supply for OSMO of around 714 million.

The distribution parameters are also changed to the following:

• Staking: 50% to 65%
• Dev Vesting: 25% to 20%
• Liquidity Incentives: 20% to 15%
• Community Pool: 5% to 0%

Impact on Staking Incentives
Staking APR reduces by 50% to around 5.6%, a moderate staking APR for an established chain.
The main improvement is to staking yield after inflation, and this is now around a third reliant on protocol revenue generation at current levels.

Liquidity Incentives
This proposal is concurrent with another proposal to adjust the liquidity incentive emissions so that the actual emissions remain constant despite the lower inflation. This is achieved by reducing the incentives that were previously redirected to the community pool.

[Govmos]

We regret our delayed entry into the discussions. On behalf of the PRO Delegators’ validator team, we express our support for this proposal. Initially, we considered proposing a revision of the inflation reduction factor to 0.5, rather than a further thirdening (equivalent to a 0.33 ratio). However, in recognition of the significant effort invested by @JohnnyWyles in facilitating a comprehensive, data-driven debate, we will align with the proposed inflation reduction parameter of 0.33, which appears to have community consensus.

Post-proposal vote and the forthcoming thirdening event, we recommend revisiting the reduction of this parameter to 0.5 to reduce this factor for next year’s reduction event.

Thank you for reading,
Govmos.

[ValarDragon]

Sorry for being late to replying, been heads down coding new features. Hastily writing one now, since this is a serious misstep.

I’m here for lowering the inflation rate to stake, but there are some critical details that are missed here.

As done right now, reduces the amount being sent to devs by 60%. To me this seems in large part like a serious firing / consideration of mis-application of duties. I do not think this is intentional, but instead is coming from accidentally from the mental model that the dev reward is part of inflation .

This is a misunderstanding of the dev supply imo, and treating it as coming as part of inflation. Really what is happening is that the dev supply was a distributable stream osmosis set at launch, with governance having the ability to change who it goes to. This shouldn’t be mentally modelled as inflation. This supply was intended to only be contingent on governance redistributing from this team or splitting the vesting to more teams (e.g. including the SDK team). Remember, the dev-osmo supply is pre-minted on-chain already. It is not part of the inflation.

I think we should get much more conversation time around this before pushing all the way through. We haven’t had twitter spaces, or much comments from even the dev teams on this.

Its important we stick to a mental model of 1 billion total supply-ish, achieved perhaps via lengthenings or more ineresting monetary policies with this as a cap. Or be very explicit about lowering it. If its lowered, this needs to be done very carefully, and still leave opportunity for increasing up to 1 billion supply.

We should take our time as this is one of the most important parameters of the chain.

Reading through here, it feels like a new prop saying “inflationary supply to stakers is capped at X%, the rest must come from taker fees” would hit on a lot of what folks want.

I think this should be voted down, and get way more conversation time.

[ValarDragon]

Another issue is I think its actually really hard to see in the current prop that its reducing circulating supply growth for the rest of time by 5/6 (83%), and leaving it to future proposals to raise it back. I think most would only notice that 2/3rds reduction (66%) if they didn’t think hard about the numbers.

An 83% cut feels way too high, especially on the length of discussion here that has occurred. Even reading through the forum post here, its pretty hard for me to glean its really 83% until I see the final supply number of 713m and start questioning how that possible happened. (Current circulating is ~670M!)

[Govmos]

@ValarDragon

This is a misunderstanding of the dev supply imo, and treating it as coming as part of inflation. Really what is happening is that the dev supply was a distributable stream osmosis set at launch, with governance having the ability to change who it goes to. This shouldn’t be mentally modelled as inflation.

We appreciate your thoughtful input to this discussion. It’s unfortunate that we’ve entered the conversation late. After careful consideration of your feedback, we acknowledge that our endorsement might have been hasty. Given the swift pace of OSMO governance (just 5 days), we have decided to shift our vote to Abstain. We firmly believe in an inflation reform aligned with the revised vision for OSMO’s utility within the protocol. However, some aspects may need further attention, and we believe it’s prudent to prolong the discussion to clarify any potential misconceptions prior to implementing any on-chain changes.

[maxpower]

@Govmos

Given the swift pace of OSMO governance (just 5 days)

It’s not though, it’s 10 days which is quite long.

[ValarDragon]

I do think 10 days is super fast for emission schedule changes, super slow for a lot of the routine things that end up going to gov

[BullBear]

This is a major proposal and it deserves a good amount of time to digest/flesh out the discussion about it.
I support the development for Osmosis from inflation based to revenue based model fully. I think it is very logical to go that way in steps.

I have seen many posts on social media arguing for a No or Veto, not because of the contents of the prop but because of the timing and rushed way it is put forward. (only 10 days of discussion and on chain now)

The content of the prop is too valuable to have it Veto/no because of timing.

I propose to keep this discussion open for an extended amount of time.

Therefore I aks that a prop will be put on chain that asks for 3 month of delay of prop #833 and #834

In this time the discussion will have all the time it needs and timing will be much better.

Prop #833 and #834 imho are too important to let it get Veto/no because of side concerns while the actual changes proposed are supported.

[JohnnyWyles]

Yes, this probably went to chain faster than it should have as expressed by both Dev and Govmos.
It would have been up even sooner without a deliberate delay, but all it takes is for new information to come to light to cast a proposal in a new light which unfortunately came too late.
At least a month is probably more appropriate for these discussions.

I find that part of the issue is that discussion spikes when a forum post first goes up and then when it goes to chain, so additional time seems wasted.
We should schedule a twitter space to discuss this and go through what changes are possible under the current minting model, as well as with any future changes to the emissions.

Unfortunately, 843 and 844 are Parameter change proposals, so they couldn’t be delayed if passed. The only way to delay this is to vote them down.

[LeonoorsCryptoman]

@ValarDragon

I’m here for lowering the inflation rate to stake, but there are some critical details that are missed here.

As done right now, reduces the amount being sent to devs by 60%. To me this seems in large part like a serious firing / consideration of mis-application of duties. I do not think this is intentional, but instead is coming from accidentally from the mental model that the dev reward is part of inflation .

This is a misunderstanding of the dev supply imo, and treating it as coming as part of inflation. Really what is happening is that the dev supply was a distributable stream osmosis set at launch, with governance having the ability to change who it goes to. This shouldn’t be mentally modelled as inflation. This supply was intended to only be contingent on governance redistributing from this team or splitting the vesting to more teams (e.g. including the SDK team). Remember, the dev-osmo supply is pre-minted on-chain already. It is not part of the inflation.

This really needs more explanation… if the dev-rewards are already pre-minted, why are not we not able to set the devshare to 0%? Since we are talking about inflation parameters here… so if the coins already exist; then they should not be part of the inflation parameters and be set to 0%. Otherwise the dev-share will only grow which is kinda weird following your reasoning.

[bananadao]

I looked into the code, as I was curious, and it turns out that the dev rewards are preminted in a special account. each epoch a certain number of coins is minted, and a share of that is allocated to developer rewards in the mint params (25% currently). the developer rewards are sent from that special account to the receiver accounts. the mint module actually mints the extra 25% that is allocated to the developers, and burns it immediately after. The preminted dev account was also removed from the bank supply, and the coins are “re minted” into supply as they is released.

The tokens are minted already, but they don’t exist in supply. From a tokenomic point of view, new supply is being created for the dev allocation, diluting existing tokens. The main goal of reduction in “inflation” is to reduce the effects of this dilution going forward. This has some pretty profound implications for the premise of the proposal. The proposal, and indeed my own prior thinking, seems to be taking the “mental model” that the dev allocation is part of inflation, while @ValarDragon argues that in his “mental model” it is not.

In pure terms, inflation reduction could be achieved by actually raising the developers share. This is because as the tokens are preminted and thus not inflationary, the part of the epoch provision that is allocated to the developers is actually burned directly after minting, as if that inflation had never existed. These developer tokens need to be emitted into supply. This is just a physical reality. I would posit that they could be emitted without dilution supply by sending them back into another “inaccessible” holding account similar to what they are in now. It would be the ideal solution strictly in terms of the tokenomic goal (reduction of “inflationary” dilution).

However, as Dev points out these tokens are actually already owned by the core team, on a vesting schedule. Lowering inflation, and/or reducing the developer share of the epoch provision (as proposed) would extend that vesting, to the point where tokens will be trapped if the emissions rate is too low. Dev is asserting that his team would consider any change to their vesting to be “like a serious firing / consideration of mis-application of duties”. The status quo is that the entire remaining developer vesting will dilute the supply, causing “inflation”, whether mental or not.

[Govmos]

@maxpower

It’s not though, it’s 10 days which is quite long.

There’s a bug in your matrix! We have 5 days voting in Osmo for quite a while.

Source: Mintscan

[LeonoorsCryptoman]

@bananadao

In pure terms, inflation reduction could be achieved by actually raising the developers share. This is because as the tokens are preminted and thus not inflationary, the part of the epoch provision that is allocated to the developers is actually burned directly after minting, as if that inflation had never existed.

Essentially that would also mean that the full balace of dev funds is released into the supply earlier than projected, right?

[maxpower]

There’s a mandatory 5 day discussion period, for about 2 years now.

[bananadao]

I’ve run the numbers a few ways, and to address the main concerns of keeping the developer rewards on its current schedule, maintaining payment for security, and reducing inflation, the only currently feasible way to do this via governance proposal is something like:

• to trigger an immediate inflation reduction by 50% via adjustment of the reduction period (reduction_factor 0.5, reduction_period_in_epochs 365)
• revert to the current mint params, (reduction_factor 0.666666666666666666, reduction_period_in_epochs 730)
• change the distribution proportions to 50% staking and 50% developer rewards

In raw OSMO terms the developer vesting amount will remain the same. Staking return will be reduced by 50% but would be 100% of inflation. Obviously community pool and liquidity mining get no further inflation. These changes would reduce the expected max supply by roughly 120 million.