Signal Proposal: Upgrade Mint (Inflation) Module
This proposal is designed to assess community interest in upgrading the abilities of the mint (inflation) module to include the ability to allow for automatic adjustments over time. This is not a proposal to actually change the current inflation settings.
Overview
Presently the inflation parameters are designed using a moving change rate. The moving change rate mechanism ensures that if the % bonded is either over or under the goal %-bonded, the inflation rate will adjust to further incentivize or disincentivize being bonded, respectively. Setting the goal %-bonded at less than 100% encourages the network to maintain some non-staked tokens which should help provide some liquidity.
Proposal
This proposal suggests modifying this so that the inflation values can change automatically over time with new abilities. Using a step based approach, where each step would have a min and max value for inflation, and a change rate that would go into effect at a specific block for each step. This would leave the target bond values as is in the module to be tweaked by individual proposals if desired, since those settings are less likely to need to be set on a per step basis. However, if SCRT Labs and or discussion determines there is a different and better approach to allowing inflation to adjust over time, then that approach would be taken in a future upgrade.
The core motive for adding such flexibility to inflation parameters on Secret Network is to empower stakeholders on the network to make and implement long term plans that don’t require constant tweaking. This should give better clarity and help prevent a FED style micromanagement of the inflation parameters on an unpredictable frequency.
Voting Yes on this proposal means you’d like to see these features added in a network upgrade by SCRT Labs.
Voting No on this proposals means you would not like to see these features added in a network upgrade by SCRT Labs.
References
- CosmosSDK Mint (inflation) module : x/mint | Cosmos SDK
2 Likes
I hate the current “change rate” as its complex to explain and a lever you cant pull and is very slow to react.
However, id favour an inflation value to be set to a constant rather than dynamic. i donth think thirdenings and anything like that has favoured other protocols. keeping the Gap between staking and non-staking APR only dependent on the bonded percentage is imo the way to go. it creates certainty for the market and reaches the goal of chain inflation → incentivizing security through staking.
1 Like
WRT dev effort, the proposal needs to be more concrete for me to assess. In general it’s very painful to modify SDK functionality like that. The foundation tax feature is very hard to maintain across SDK upgrades, when we merge from upstream and have to resolve conflicts.
All that to say that I’d like to see more well defined functionality with concrete examples.
3 Likes
I’ll work on finding examples and update. If anyone else has any cosmossdk based examples of a modified minting module that allows for a schedule to be put in place feel free to share here as well.
I meant concrete examples of how you’d use the new functionality, so it’ll be easier to design the implementation.
oh that’s easier i can lay it out in a bit.
Making a proposal to set the steps would possibly look something like this.
{
"type": "cosmos-sdk/ParameterChangeProposal",
"value": {
"title": "Proposal to Modify Inflation Parameters",
"description": "This proposal aims to modify the minimum and maximum inflation parameters in our network to better respond to economic conditions and the needs of our network's participants.",
"changes": [
{
"subspace": "mint",
"key": "InflationMin",
"value": [["0.020000000000000000", "9523610"], ["0.025000000000000000", "9823610"], ["0.030000000000000000", "10023610"]]
},
{
"subspace": "mint",
"key": "InflationMax",
"value": [["0.100000000000000000", "9523610"], ["0.110000000000000000", "9823610"], ["0.120000000000000000", "10023610"]]
}
],
"deposit": [
{
"denom": "uatom",
"amount": "512000000"
}
]
}
}
In the nested array, there is a value for the parameter, followed by a block number where it would go into effect. Once a valid proposal with values for steps passed, the min and max inflation would go into effect at each steps block, a single step being defined in each part of the nested array.
1 Like
@assafmo @thenodefather If SCRT Labs doesn’t want to dedicate time for this, we could propose to adjust the Inflation parameters by hand around a certain schedule. That would take 0 dev work, even though it would a lot nicer if we just had a single proposal for a schedule like this.
3 Likes
Certainly, it’s feasible to manually adjust the proposals at each stage, and we’ve seen numerous blockchain networks adopting this approach. If the community prefers not to set a pre-determined schedule, that’s entirely acceptable. However, It’s pretty clear governance can be unpredictable and political dynamics can shift over time which would lead to a lot of uncertainty over such an approach. Many individuals in the crypto world appreciate the stability offered by a predetermined, automatic schedule. Take Bitcoin, for instance, which features an emission schedule that changes every four years. We can also find examples of Cosmos-based networks implementing step-based changes. These cases use different methodologies, and the intent here is not to impose a specific model. I’m simply responding to @assafmo’s inquiry by offering a concrete example of how such functionality could be utilized. Also, many of the other proposals being discussed currently also require dev work, answering assafs question simply allows him to assess the difficulty.
Even though this is merely a signal to add the ability to apply a schedule to inflation and not an actual change to inflation, I’d like this to be discussed on next weeks governance call since there were concerns brought up. cc @pmuecke
1 Like