PUP-29: A Cadence Change to Updates of RTTM Adjustment for Target Emissions (ACCURATE)

Update 01/18/2023:

Incorporated changes suggested by @JackALaing


  • Author(s): @cryptocorn, @msa6867

  • Parameter: RelayToTokenMultipier (RTTM)

  • Current Value: Variable, subject to monthly PNF update schedule based on trailing 30-day average relays

  • New Value: Variable, subject to weekly PNF update schedule based on trailing 7-day average relays


Moving from a monthly cadence of updating the RTTM to a consistent weekly cadence, in conjunction with moving from a trailing 30-day average to a trailing 7-day average when inputting relay average into the calculation of RTTM, will lead to less deviation of emission rewards, both over and under, from the target amount.

This proposal moves to a weekly cadence of updating RTTM and switches from using a trailing 30-day average to a trailing 7-day average when inputting average daily relays, while leaving the target daily emission unchanged at 690k POKT per day. Changes to the POKT tokenomics or target daily emissions are outside the scope of this proposal.


PUP-22 (Further Reduction in Emission Numbers) contains the following PNF directive:

This directive to PNF is replaced with the following:

The Pocket Network Foundation (PNF) shall calculate the RelayToTokenMultiplier (RTTM) by dividing the target daily emission rate (denominated in uPOKT) by the Trailing 7-Day Average Relays. Poktscan shall be used as the source of truth for relay counts for the measured periods.

PNF may also use the following calculator to calculate RTTM:

By inputting the Trailing 7-Day Average Relays and the WAGMI Daily Target Emission rate, a new parameter value is outputted. As a part of this proposal, the parameter value will be adjusted weekly to account for changes in Daily Average Relays, regardless if there is a change to the Target Daily Emissions Rate. It is suggested that each Monday RTTM will be updated (unless the Monday is a public holiday, in which case RTTM shall be updated on the following business day). That being said, PNF may, at its discretion, choose the day of the week most convenient for them as long as a regular weekly cadence is maintained.

[Note: the above spreadsheet does not need to be modified in order to be used in conjunction with this proposal. It is only noted that cell A7 would be relabeled “Trailing 7 Day Ave Daily Relays” and the trailing 7-day average Daily Relays, rather than trailing 30-day average, would be input into cell B7.]


Currently the recalibration of the RelaysToTokenMultiplyer (RTTM) to balance emission rewards to the daily target emissions laid out in FREN (690k daily from Jan 1st 2023) and other possible emission reduction proposals (SER at time of writing), has been updated on too slow a cadence such that the daily emissions have significantly deviated from the target.

RTTM was originally proposed to be adjusted monthly, and at points of high volatility within the ecosystem it has been adjusted weekly to better contain spikes and troughs in daily emissions. While moving to a weekly change of RTTM has had some positive effect in keeping emissions consistent with the target daily amount, even this increase in calibration tempo still suffers the problem of being a lagging indicator, and we have seen deviation of 30% or so from our target. This proposal looks to further increase the cadence of recalibration, such that large spikes or troughs in daily relays can be quickly responded to and daily emissions will fluctuate within a much smaller range of the target.

Furthermore, the current methodology of using trailing 30-day average to calculate average daily relays is not responsive enough during times of relay growth. It is proposed, therefore to update the averaging method from a trailing 30-day average to a trailing 7-day average. 7-day averaging provides sufficient smoothing of random peakiness in relays while being responsive enough to larger trends of relay growth to prevent most overminting.


The following spreadsheet provides analysis of the overminting that occurred during the month of October (prior to the chain halt) due to relay growth in October compared to September averages, as well as the overminting that hypothetically would have occurred under different cadence and averaging conditions. As can be seen, a move from monthly to weekly cadence while still using a trailing 30-day average would have only reduce the October 1-25 overminting from 33% to 21%, and moving to a daily cadence scarcely helps reduce the overminting more than this. On the other hand, moving to a weekly cadence of update in conjunction with moving to a trailing 7-day average would have reduced the overminting to only 6% during this period - a more than three-fold reduction compared to only moving to a weekly cadence while still using a trailing 30-day average.

Other tabs on this spreadsheet show the actual relays count for the entirety of 2022 and the hypothetical overmining that would have occurred under different update cadence and averaging methods (assuming hypothetically that FREN was in effect for the entire year.)

These results are summarized in the following table:

Total Minting Deviation 2022 Update Frequency
daily weekly monthly
Averaging Period 1 day 0.4% 5.4% 0.4%
7 day 1.4% 2.4% 6.7%
30 day 5.3% 6.4% 10.3%

As is noted above, weekly updates with trailing 7-day averaging provides the least overminting when ignoring the daily-update column. While daily updates provide even lower over-minting, the improvement compared to weekly updates is not worth the work overhead that it requires.

Dissenting Opinions:


Copyright and related rights waived via CC0.


It seems that there is very little dissent to our proposal (or people are pre-occupied with PEP-49). @JackALaing , can we put this to a vote when we pass the minimum time threshold?


Yea, this is a no brainer.

Love what you guys do for the DAO @msa6867 & @Cryptocorn

Nice one two punch :boom:


Hey @Cryptocorn, this does look safe to put to a vote. The only logical dissent would be from those who have to implement the weekly cadence (the Foundation directors) but we’re already planning weekly batches in our process so this proposal slots nicely into that.

I do have 2 minor suggestions first:

Here is the updated calculator that we’ve been using and sharing with every FREN update. FREN Calculator - Google Sheets

It would be worth editing the proposal to link to this instead.

Do we need to be this precise if the updates are still being made weekly? The new Foundation directors are onboarding and haven’t finished defining our internal procedures, so we may find that another day works better for our schedules in the long-run. For context, we would be batching all governance transactions on a weekly basis to ensure consistency, and these weekly RTTM updates would be included in every batch, but we haven’t settled on which day to use.

I would propose removing this sentence and allowing the directors to use their discretion to adjust their batching schedule as long as it maintains the weekly cadence.

1 Like

I have updated the proposal to reflect both changes suggested. We are ready to put this to a vote.


This proposal is now up for voting. Snapshot


This proposal is up for voting now, but it would be good to have a day that this gets updated and stick to it. There is no enforcement mechanism, but at least with Mondays, we knew by Tuesday if there was an issue. With ‘a day’ I fear we can have ‘creep’ when people are busy, forget etc.

I’ll delete the comment if PNF decides on a day of the week and publicises it, which would take us back to being able to to quickly highlight a missed update (which I hope was always the intention of PNF, just not sure if I was reading it right, so looking for clarification).

1 Like

The Foundation will have a consistent weekly batch of transactions, so that we can’t be busy or forget. We haven’t yet decided which day will be most suitable for our schedules. I was just asking that this proposal not prescribe Monday in case the Foundation decides another day works better. Whichever day is chosen will be publicized and you will be able to track how well we adhere to that because we’ll be announcing every time the parameter is changed.


Great, thanks for confirming.

This proposal has passed with 22 yays and 0 nays.