[RFC-0011] PoS inflation adjustment

I want to be clear here, I don’t mean to be a naysayer. I appreciate the desire to harness the active market participants as potential minters, and how that might benefit the ecosystem of the coin on many levels. My perspective comes from a confluence of forces pulling in several directions, and ultimately an attempt to achieve consensus by adhering to a rule of ‘if none of our core principals change, then no one will reject the proposal’. There are two core principals at play here. The first is the 1% total mint inflation, which the community has philosophically incorporated. It would feel amiss to alter this number because of a slippery-slope type feeling akin to the aversion toward changing Bitcoin’s ultimate supply cap. If we change it once, who’s to say we won’t change it again? The second principal is one of hard coded limits, which you can see in places such as the maximum rate of change of the mint difficulty. This point was pretty much the only comment I have attained from Sunny King when asked about this proposal, he mentioned that having a maxinflationadjustment was a beneficial concept as a protection for the protocol. Now, I will agree that the 5% personal inflation (which is consequentially accompanied by 20% minimum mint participation before the feedback loop is invoked, assuming the first principal of 1% total inflation) is somewhat arbitrary. However, I believe 5% interest is a critically incentivizing number, being larger than nearly all ‘guarenteed’ fiat interest rates, such as bond yields. The 20% mint participation number is coincidentally also a very important threshold historically, as it is larger than Peercoin has ever experienced for a prolonged period of time. Ultimately, I believe that the numbers in the proposal as they stand are very poignant as compromises for blanket consensus while still maintaining the drive towards a higher level of motivation for market participants to take that extra step to become minters. I truly do not mean to dismiss your analysis in any way, and am happy to continue discussion about the numbers chosen for this proposal.


Great to hear that you are open for discussion.

  1. The first is the 1% total mint inflation, I agree global inflation should not be changed.
  2. Participation POW mining still contribute to the majority of issuance. Let’s say at 5% participation then personal reward rate might be capped at 8% (8X), then it quickly scales down as more participant joins POS minting to balance out rate of reward and participation.

I am trying to propose is to allow these levers to be scalable between different factors like

A) coin price and
B) demand/supply market dynamic will play a role to incentivize
C) higher stake rate.

Given RFC11 is the first significant economic update to the network, there have been a lot more Proof-of-stake blockchains since 2012. This needs wider community feedback to consider.

  • Would higher POS participation make the network more secure and attractive without introducing significant risks?

  • How do we scale this reward rate while respecting 1% global inflation to improve Peercoin adoption?

The scenario: If personal reward cap scale down from 8 to 1%, as participation increase from 10-30%

I have a example of linear scaling between personal reward rate and participation.

This has been increasing in the last 3 month, at the current participation rate of 13.6% (3.479M/25.5M) the reward rate would be around 6.6%.

Feedbacks are welcome on what these levers should be, and how it should scale.

Generally higher PoS participation is correlated with higher security. More specifically, a higher mint difficulty corresponds to a higher security.

I would avoid coupling any protocol rules to the active (or perceived) market, that would be a recipe for failure.

This is possible and feasible to implement, but I would like to address the individual differences between your proposal and the proposal how it stands.

  1. You decrease the beginning threshold to 10%, allowing for a higher adjustmentmaximum, which you restrict at 8.

  2. You steepen the curve such that it reaches an adjustment of 1 at 30% participation instead of 100%.

I will respond to these changes with two points, which roughly correlate to the two changes.

  1. Lowering the beginning threshold and steepening the curve exacerbates the concerns Otzi had. This could result in some form of self-limiting or cyclical behavior wherein people attempt to game the system. It is important to note that there is a subtle but important difference between people claiming their inflation and people actively minting to increase the mint difficulty. One creates chain security while the other barely helps at all. We do not want to turn continuous minters into seasonal minters. I don’t believe the original proposal would to that, but an 8x slope over a 20% change in participation may cause that.

  2. The second point boils down to why leave money on the table? If you are bottoming at 30% participation, you are only awarding 0.3% total PoS inflation at that level. In fact, if we look at total amount of coins given out per year, you can see that it maxes out around 17.5% participation with ~0.94% inflation (aside from the full 1% given at 100% inflation). Game theory would state that the system will equilibrate around that point. Such an eventuality would clearly be less than ideal.

1 Like

Increased Load on Nodes

Any measurements on a stakebox for how much of an increased load this proposal would have? There’s something to be said for an energy efficient and sustainable blockchain .

When speaking with the devs, it was made clear that by simply indexing just one more variable during the initial sync, there will be only a trivial additional load. Thanks for bringing this to my attention, I should probably edit the proposal to reflect that.

1 Like

I have added the bit about trivial load, as well as generalized functional form and something about ‘futuristic’ minters. The futuristic minters section is speaking to the recent understandings of rfc2-4 about multisig minting and even mint pools. Rfc12 would be independent of this point.

It has come to my understanding that with the recalc to 1% inflation, peercoin will not become deflationary when lots of fees are burned. Just a important detail to consider…

We don’t want to become deflationary, it’s important to have some inflation in order to keep the economic system healthy.

While peerchemist is correct that the aim is not to become deflationary, the txn fees are not included directly in the calculation of adjustment (just like pow rewards are not directly included), so it is still entirely possible that some time in the future the txn fees overtakes the pos rewards.

This proposal was discussed recently in a team meeting. We will attempt to simplify implementation and will continue to discuss it.

I did some coding to create a simulation. While doing this, I realized some of the math of the rfc isn’t quite right, but the spirit is still the same, as is all the discussion we’ve had on it. The simulation makes a whole bunch of assumptions, such as no PoW component and the same order of minters every year, but I think it is something that is worth playing with. Attached are some images representing the case of the ‘seasonal minter’ that people have been worried about. As you can see, it should pose no issue because the adjustment is an average over a year. Indeed, the ‘opportunistic minter’ would need to wait for an opportunistic year, rather than a season, and at that point they are missing out on quite a bit of compounded interest. I’m happy to answer questions about this simulation, it can be slow when run with >100 blocks and has a lot of assumptions embedded into it, but it shows some interesting details that I think are important to play with.

inflation.py (2.6 KB)
adjustment.pdf (24.6 KB)
outputs.pdf (35.1 KB)
newtotal.pdf (24.9 KB)

I’ll continue to play with it and maybe make some of it more pretty with time, but this is the general gyst.


Here is an updated version of the simulation. I have added in a tag for seasonal minting, as well as an inflation rate for PoW mining that is assumed to not participate in minting. I have made a number of changes, but the most important here is one that will most likely wind up changing the way rfc11 is written/coded. I believe the best way to implement this is to calculate the adjustment based on what the PoS reward would have been had rfc11 not been implemented, i.e. 1%. The most obvious result of this is that the first year behaves differently than subsequent years (as the adjustment has not boosted the PoS holdings yet).

The long-term result of this simulation (when run over 100s of years) is for the adjustment to match the PoW reward. For example, if PoW=0.02, then the adjustment will trend towards 2.5, corresponding to 50% participation. This is because that is the participation at which the increase of the supply due to PoW cancels out with the adjusted inflation of PoS. This is not quite realistic, as in reality the PoW is not a % inflation, but rather a fixed rate. I may try adjust this to better represent reality in the future, but it is of course impossible to fully simulate the entire network.

The other potential upgrade I might want to do, other than trying to put a legend or something on the graphs, is to add in the concept of ‘coindays’. This would be a very difficult upgrade, and I’m not sure I will be able to ever truly simulate coindays as they should be simulated.

inflation.py (2.9 KB)
adjustment.pdf (11.6 KB)
newtotal.pdf (10.6 KB)
outputs.pdf (12.4 KB)

In these images, blue is year 1, orange year 2, green year 3, red year 4, purple year 5. The ‘newtotal’ graph includes a brown curve because it has year 0 added in, which shifts all the years by 1. Plotted are the settings as they are uploaded here. I think this shows a pretty powerful case which is quite close to the current network stats: 20.5% participation, 3% PoW inflation.


I look forward to studying the simulations. This proposal seems certain to ensure that 1% inflation is maintained.

The next question, therefore, is whether it also keeps up the minting rate, and hence blockchain security?

It seems to me that the main risk is from “yoyo-ing” - that is, a low minting rate leads to 5% inflation, which leads to people rushing to mint, which means the inflation falls back to 1%. Do those new minters them lose interest and leave - which in turn repeats the process?

You are describing the ‘seasonal minter’. The solution to this concern is two fold. The first step is to understand that the adjustment is a yearly average. That means that it doesnt matter if people are minting more in the winter and less in the fall, the result is essentially an average of the whole year. So you get the same amount whether you mint in the winter or the fall. You can play with this concept by turning on the ‘seasonal’ trigger in the simulation.

This means the way to game the system in this ‘yo-yo’ type procedure is to game it year-to-year. So you would withhold your coindays for a full year hoping that next year the participation is less than this year. The solution here is to impose a new type of restriction that hasn’t been brought up before but that I have been discussing with some of the devs. Essentially, we would impose a maximum coinday reward. In the current code, if you held your coins for 10 years and then mint, you would receive about 10% reward. I would make it so that after 365 days you stop accruing additional reward. This would entirely defeat any attempt to game the system year-to-year, because if you mint now and again in a year you would get the same reward next year plus you would get this year’s reward.

With these considerations, I do not believe a ‘yo-yo’ effect is possible given rational actors.

The way you phrase your concern sounds like less of an attack and more of an economic concern. So we imagine individuals who simply would not mint at 1% (i.e. are not current minters) but would at 5%. So first off, we are assuming that rfc11 increases security over the current protocol. Next, we assume that there are a number of these people, all with different % thresholds that they would mint at. The result is something akin to a Dutch auction, where the system will locate the average threshold % and operate there. Any oscillatory behavior comes in by assuming that the threshold to turn on a minter is different than the threshold to turn off, i.e. at 5% a minter becomes interested and is still interested when it lowers to 4%, but decides to turn off the minter at 3%. This is possible, and would create oscillations, but it is vital to understand that a) these oscillations would by definition be above the current mint/security difficulty, and b) that the oscillations are averaged throughout a year, so they are slow and likely have a complex relationship with actual market interest in the coin.

Yes, that’s how I saw it. Part of the overall solution can include Peercoin’s own education to coinholders; so rather than saying minters can “get up to 5% per annum”, we should say: minting is 1%, with a possibility of more for maintaining security, i.e. Peercoin’s selling point should be the security guarantee, rather than the 5%.

Right, but it should also be noted that % gains on a coin that is going up in value is very different from % gains on a coin going down in value. It is entirely possible this form of market-driven oscillation already exists, and we simply aren’t able to distinguish it. In that case, rfc11 could potentially act as a damper for market-driven oscillations by offering higher reward when interest wanes and lower reward when it rises.

I have heavily modified the RFC, and am doing a few re-reads before I commit back to the Peercoin branch. Biggest changes include using nAnnualStake instead of nAnnualPoSRewards, which frames the whole implementation a bit differently, and addition of the 1-year limitation on coinage.


RFC pushed, also I updated the simulation to have a more realistic PoW, namely a constant PoW block reward rather than a % of supply (though you initialize using % of supply still because then it’s not dependent on the specific parameters used). You can see that PoS becomes dominant after ~80 years, even without any reduction in PoW reward (i.e. InflationAdjustment trends toward 1). This is realistic because the PoS supply grows as a % while the PoW reward grows as a constant number.

The following simulation uses the same values as last time, but runs it for 80 years. I only use 20 blocks per year to cut down on simulation time.

inflation.py (3.0 KB)
adjustment.pdf (41.2 KB)
newtotal.pdf (40.1 KB)
outputs.pdf (45.2 KB)


As have been discussed already, RFC11 means that there will be additional load on the nodes.
History of the past ~50k blocks has to be parsed in order to validate the PoS reward properly with RFC11. This can be done in RAM, so that node scans 50k blocks during the startup or by indexing the needed data in the database. Scanning during startup will increase the start time and maybe cause some discomfort to users.

Implementation in the block database will increase size of each block on disk by ~3kb, which means extra 1.5 GB to store the blockchain.

I thought the idea was to do it in RAM since you are going through the blocks anyway, it’s just one or two extra numbers to keep a running tally of. How much discomfort are we talking about?