When designing IISS 3.0 we were operating under the constraints associated with what was developed on ICON 1.0. It was a fairly complex design so we didn’t want to make too many changes to the code.
Now that we’ll be migrating to Batang we have much more freedom in terms of design. That is why I’m now proposing a much cleaner and straight-forward economic design for Batang with predictable inflation rates and clearly defined percentage breakdowns of where inflation is allocated. In our current system, it is impossible to say with certainty that “x% of inflation will be going to voters while y% inflation goes to validators” or “the amount of newly minted ICX per month is x”. The percentage breakdown and amount of newly created ICX per day constantly changes as more/less people delegate their ICX, meaning we have very little control of how we would like to allocate network resources and how much new ICX will be minted during any given period.
IISS 3.1 will consist of several inflation pools with specific percentages of inflation allocated to each of them. The percentages assigned to each pool, as well as the size of the total pool, will all be able to be changed via a Network Proposal vote.
- i_global = Monthly inflation pool size in ICX
- i_prep = percentage of pool going to P-Reps
- i_voter = percentage of pool going to voters
- i_relay = percentage of pool going to relayers
- i_cpf = percentage of pool going to the CPF
Note: As a rule, i_prep + i_voter + i_relay + i_cpf + i_n must always equal 100%.
As for the specific allocations, I think it would make more sense to decide these things closer to launch when we have a better idea of the state of the network at the time. This way we can lock in the lowest inflation rate possible while still ensuring P-Reps are profitable, the CPF is properly funded, and voters still have a high enough incentive to stake + vote.
Additionally, in future iterations, it will become relatively easy to add new inflation targets through Network Proposals. This opens up the door for many interesting opportunities. For example, we could decide to create some sort of network-funded Defi project and direct inflation toward the smart contract as network-funded collateral. Another option could be a pool for people that lock their ICX for a full year to earn extra inflation. These are just examples that came to mind during writing, but we could direct inflation toward anything we want with this simple and clean model.
I’d like to form consensus on 2 things for now:
1.) Direction - that we will have one inflation pool that gets split into the aforementioned buckets
2.) Removing the 3/4 root function for P-Reps above 1% delegation that we previously agreed upon in IISS 3.0. This adds considerable development difficulty and detracts from the simplicity I’m shooting for in IISS 3.1. I would prefer to solve the vote concentration problem a different way using some form of vote decay, which we will discuss in a separate thread.
Overall, I am becoming a bigger believer of “simple is better” and trying to work that into our economic designs. This means less exceptions and conditional rules where possible, as these add a lot of calculation burden to our network and open the door for more issues, bugs and edge cases.