I agree that MaturityRelayCharge shown in unrealistically high. Keep in mind that the authors have stated that the actual parameter values are subject to fine tuning / right sizing via discussion. I think we can evaluate the general construct first and if the construct seems solid then move to finding to correct parameter values. [My current thinking is that we will be in good shape if we can get ~3E-6 usd per relay in maturity (and decreasing from there over time due to Moore’s Law)
3 Likes
This proposal relies on the parameters, especially considering this is a counter proposal to PNF’s inflation proposal. So I believe that is what should be the focus.
Personally, I don’t think any further explanation is necessary. Their argument is this is a dynamic way of calculating RTTM and GFPR that goes with relays growth, instead of being arbitrary defined with proposals. That is the rational for this proposals compared to something like SER or PNF’s proposal, and I don’t believe two proposals (a RTTM proposal and a GFPR proposal) would be beneficial since this is in-fact a single system to govern them both.
It also is designed to incentive the entire ecosystem around relay growth, as right now SER and PNF’s proposal do not. Node runners don’t care about what the relay counts is, other than a marketing number. This makes it their incentive to see relay growth.
To me, no further explanation is necessary in this proposal, but we need to know if the formula will work, hence why I took a gander at seeing what the default parameters would produce. If the default doesn’t work, I’m open to seeing what modifications can be made to make this proposal feasible.
2 Likes
Adding some edits to the main post:
- Fixed some grammar, thanks @Cryptocorn !
- Clarified on/off chain parameters, as requested by @msa6867 .
- Added rationale on why this is presented in v0 and why it works on v1. Per request of @msa6867 and points raised by @b3n and @Dermot among others. This should help understand why are we proposing this now and why we think it will be possible to carry over this strategy to V1:
- Added “Explain Like I’m 5” section (as named by @PoktNews and requested by @Misskitty42 among others. )
2 Likes
I modified the parameter sections to make this distinction more visible. As you say the only parameter being modified is the RTTM, the others are “DAO instructions” or guidelines. Anyway there must be consensus over them and their values must be agreed upon.
We address this in the new rationale section “On the timing and implementation of this proposal in V0 and its projection to V1” (see previous post or the edited main post).
Separating the proposal is not possible. We think that thinking of these parameters as different and unrelated stuff is the paradigm that we must abandon in favor of a more systemic view of the network. We added some rationale about this in the main post (section “On the timing and implementation of this proposal in V0 and its projection to V1”). Also, the explanation provided by @shane on this matter reflect what we believe too.
Regarding on how the proposal would look like if we keep SER and only change the GFPR, there is a mention to this in the original post text:
Also, in the notebook provided in the “Resources” section, we added a simple flag to turn on/off this hypothetical scenario. Feel free to explore the possibilities. It can be found on the “Run Options” block:
# If true, the calculations use the constant burning price of 0.00000085 USD/relay
# wich is the current state of the network.
# If false, the values for the "SER" curve are calculated using the proposed
# increase of GFPR. This means that it would be a "hybrid" scenario, not the
# current one nor the proposed.
USE_CONSTANT_BURN_FOR_SER = True
``
This mechanism (as first glance) seems more complicated as it requires the calculation and redistribution of rewards to be done off-chain. Nevertheless I look forward to discuss it on its own if you decide to create a proposal using this concept.
Well I certainly would not like to make widgets in your factory. Your system might work when the labor force has nowhere to go, it does not work for educated/skilled workforce and it certainly wont work for a permissionless node runner environment that can now sale their service to anyone. No new contributor will enter the system if you say them “you are earning peanuts and will earn peanuts if we produce more. But don’t worry we will think of something later.”
The values proposed (which can be changed tho) were set to create a harsh environment for node runners. This proposal (as it is now) wont produce much more rewards than ARR, so the idea of “optimize efficiency over quantity” is backed into the parameter set. The difference is that we shed some light on where the subsidy goes and for how long (measured in production per day).
Delaying the alignment of node runner incomes to relays produced by day will only grow the discomfort of node runners (which are ecosystem builders). Telling the supply side of the network: “Don’t worry we will think of something later” but not define when and how that will happen (when we can), is completely arbitrary. There is no guaranty of a brighter future for them.
The same argument can be given for node runners. It is expected that a node runner become less reliant on subsidies as it process more relays. Check the Game of Providers post, you will see that smaller node runners are suffering more, should we incentivize them? I think the community just tells them “do what you can, see you on the other side”.
We need to think as a protocol, gateways are just as permisionles as node runners, and they should not be treated differently at a protocol level. We can think of DAO grant and incentives. On that regard, I really like this idea:
1 Like
Thanks @b3n for your input, I will try to answer your as simply as possible.
- Is this a need/problem? Go to next step:
Yes, the node runners are clearly uncomfortable with ARR and the fact that they are always the only adjusted parameter of the system. Node runners (builders) will start to leave and since there is no projection of increased reward none will come. Moreover there is much talk about setting the emissions fixed in USD (regardless of traffic), which is unacceptable. - Is it a need right now?
Yes, the community is looking for a new emissions policy, ARR is the main example. This proposal is the first to take into account that the burning is now a real thing. As opposed to WAGMI,FREN and SER, we can now leverage the demand into the models and clarify where are the DAO incentives going. - Is this the right solution?
Yes, it is a fairly simple solution that can be exported to V1. It only introduces a few parameters that delimit the bootstraping epochs and the prices that the protocol will charge to users and pay to servicers. It does not dwell into complex mechanics on how the tokens are distributed among actors (DAO/Validators/Servicers) and it does not require complex calculations. - Is this the right team/person (to implement, when relevant)? -
- Is this the right size/price (to pay, when relevant)? -
We have shown that node runners are not 100% aligned with relay growth as it does not translate into token appreciation directly:
- We have observed it in the price actions after relays ATH.
- We have read the node runners comments in the chats after the relays ATH.
- We found no direct connection of the number of relays to the token exchange rate when we modeled the economy of the Pocket ecosystem.
Does this mean that reaching 10B relays wont affect the price upwards?
I don’t know, nobody knows.
Why tie the success of the supply side to something that you cannot control?
We cannot answer this.
Did the price action improved when the number of relays grew from 800 M/day to 1.2 B/day in the last year?
No
Will it grow when we reach 5B/day?
Don’t know.
It is a simple reasoning, there is no evidence nor model that ties one thing to the other, therefore any “alignment” that is observed comes from other sources.
We are particularly happy about Pocket relays ATH, but I cannot answer for every node runners out there, and probably those node runners that are less engaged with the community care little about this metric. This proposal can change this problem without having to pay in supply growth.
2 Likes
Yes!
And this is much much much more clear than keep complex schemes on gateway-specific GFPRs, the DAO could easily vote on a per-gateway case. Just charge what the protocol say and transfer tokens from the DAO to the gateway that need help, direct funds going to the gateway that will return as payments to be burned.
1 Like
Thanks @shane for starting to play with the numbers, thats why we created the linked resources!
What you say is true, and we want to open the discussion on the parameters. Maybe it was not clear enough, but the parameters are the things that we are very open to modify.
The current parameters are only to show that we can almost match ARR proposal effects while aligning the ecosystem actors into network growth.
What you point out should be discussed, maybe the MaturityRelayCharge should be lower (and hence the MaturityRelayCost). Changing that wont change the spirit of the proposal, which is to provide projection.
It must be also taken into account that the price at those levels of production (10 B relays/day) would benefit from scale. New portals might be able to apply for DAO grants to kickstart their production. And also there is the prime to pay for decentralisation and automatic scaling that the Pocket Network would provide to the gateways.
This can also be changed. These are only parameters that we can select (almost) arbitrary.
As @msa6867 said, we actually care more on the mechanics than in the parameters. They are open to discussion.
And we look forward to this!
This!
3 Likes
I get this concept, but me personally, I can’t vote for a mechanism unless I know it works economically speaking. I’d likely choose a path with a predictable outcome, like PNF’s proposal, before I would support a mechanism that I don’t know if it can be constructed to meet our economic goals.
Economic mechanisms need to first prove their merit with working parameters IMO, so I’m all ears seeing what parameters would work, to make this proposal have a compelling result.
1 Like
Please update “Current Value” as follows:
-
Current Value:
RelayToTokensMultiplier: variable according to Sustainable Emission Reduction (SER) schedule
GatewayFeePerRelay: 0.00000085
Node runners have been fairly silent on this proposal so far. Their comments/feedback would be very welcome ( if not on the specifics of this proposal, then at least comment on the overall theme of how important it is to them to see rewards increase as relays increase during the remainder of v0). If I recall, comments by noderunners in the comments section of the ARR proposal were about evenly split if not majority in favor of that proposed change. I could be wrong, but that was my impression.
2 Likes
A couple of NITs to clean up:
Please define R in your formulae.
Re epsilon: in your example, you give exchange rate of $0.031/POKT. Since this is the conversion direction most in the community are familiar with (USD to POKT), perhaps it would be more intuitive to use this conversion direction in your formulae (ie divide by epsilon rather than multiply where epsilon is USD to POKT) or else, at a minimum, quote at least one time the equivalent POKT to USD (eg 32.3 POKT/USD) so the reader is explicitly alerted that you mean the opposite conversion direction in your formulae. Eg…, something like:
1 Like
No off chain calculations or redistribution of rewards needed. RTTM would simply consist of a subsidy component (either fixed as in ARR and RDI, or diminishing as in SER) plus a percentage of GatewayFeePerRelay. E.g.,
RTTM = RTTM_0 + PercentBurntoMInt * GatewayFeePerRelay * epsilon,
where RTTM_0 is that of SER or ARR or RDI or whatever subsidy-based mechanism is decided upon.
[Note that in v1 the above would be replaced with
RTTM = RTTM_0 + PercentBurntoMInt * AppBurnPerRelay * epsilon ]
I think you will find that when all is said and done, your proposal for setting RTTM can basically be deconstructed into something like this equation.
================
Following is feedback on the specifics of the proposal:
On the demand side:
- The proposed mechanism for setting GatewayFeePerRelay seems sound
- The maximum value I foresee for MaturityRelayCharge is around 0.0000035. Even that may be a bit too high. I can go into specifics if needed but will not unless needed.
- For GatewaysBootstrapUnwindStart, I think a minimum of 2B relays/day and perhaps even 2.5 or 3B is desirable to maximize prioritized focus on growth. I believe it will help for existing and new operators to have the simplicity of fixed, predictable pricing during this period. That being said, I do see value in developing a game plan now for weaning off of subsidies, and your approach is as good as any I have seen with respect to demand-side fees
- Proposed values of MinBootstrapGatewayFeePerRelay and GatewaysBootstrapEnd seem fine
On the supply side:
- The proposed mechanism for setting RTTM is not sound. Please see my comments to the RDI proposal as almost everything I said their applies here. tl;dr, denominating the supply side in USD in addition to the demand side causes a complete decoupling of USD to POKT conversion rate from POKT fundamentals eliminating needed price discovery / price feedback loop that will help price find a floor, leading to risk of hyperinflation during the pre-maturity regime (relays << GatewaysBootstrapEnd).
See, eg, the following example where I have populated the parameter set with as realistic values as possible and explored what if price continues to drop to sub-cent level.
Granted this is better than RDI, because here at least the possibility for hyper inflation only occurs in the pre-maturity regime. Post maturity (eg >10B relays per day), a proper choice of parameters will guarantee the net mint is deflationary, but the problem remains that the feedback mechanism that can help token price rebound from ATL is removed and the system is stuck with high values for both RTTM and GFPR which will keep price depressed. See e.g., the same parameter set as above when maturity is reached at 10B relays.
Going back to my proposed alternative construct:
RTTM = RTTM_0 + PercentBurntoMInt * GatewayFeePerRelay * epsilon,
where the first term is a subsidy/bootstrap component and the second term is a percentage of the burn, it is possible for the second term to be denominated in USD. But it is not possible for the subsidy component (RTTM_0) to be denominated in USD without threatening to harm the project.
Since we are at RTTM ~= 500 right now (and dropping), and we are not in an environment where anyone is seeking to raise RTTM, I think it to be a reasonable expectation for proposed changes to the mechanism for setting RTTM to show how their methodology is at least bounded to RTTM <=500. This can be as simple as adding an explicit bound of MIN (500, x). That would satisfy the concerns raised above about risk of hyper inflation, removal of price feedback mechanism, etc.
- Notwithstanding the above, if MaturityRelayCharge is set to 0.0000035 or smaller (as suggested above), this implies MaturityRelayCost even smaller. I use 0.000003 as a starting point (~85% of MaturityRelayCharge). This is probably still relatively too high (perhaps 75% of MaturityRelayCharge is a better target? ).
- I kept MaxBootstrapServicerCostPerRelay close to your original (0.000009) for the sake of providing starting continuity between your proposal and the ARR proposal:
- Proposed values of ServicersBootstrapUnwindStart and ServicersBootstrapEnd seem fine
2 Likes
As you say this can be seen as simple change of cost plus a bias:
MaturityRelayCost = PercentBurntoMInt * MaturityRelayCharge * epsilon
and then just
RTTM = RTTM_0 + RTTM_proposed
The one is a fixed bias in POKT and the second is the proposed controlled RTTM obtained from the linear functions ans so on. This is more complex than the current approach that some already call too complex.
As you say below, maybe a hard cap on RTTM will solve this more simply.
I would love to hear your rationale on this, as we need consensus on these values. Nevertheless I have to admit that the feedback from portal runners such as @poktblade and @ArtSabintsev are the ones we need to give more weight.
I agree that giving some flat rate for a little while is OK and might help them. More after seing that growth is not going as fast as expected.
I agree with the objection of denominating the supply side in USD, but given the token exchange rate instability and the low weight that the Pocket Network has in the relay market, it is necessary to give up some control over the emissions to try to keep the exchange rate in rails (this is a consequence of the economic trilema, something that we cannot avoid). We would be glad to give up this as soon as we can and transition to a POKT denominated economy.
Please keep in mind that in contrast to RDI, this proposal is only viable is parameters are set together, “hyperinflation” is only possible if there is no burning counterpart.
Just to clarify to everyone, a price of 0.001 USD/POKT is a lot. Is the same as the one that POKT suffered going from 1 USD/POKT to 0.03 USD/POKT. While I highly doubt that we can suffer such depreciation process again, everything is possible. It is correct to analyze these extreme cases.
This is an interesting take, if I understand correctly you are saying that our economy might be stable in maturity but the nominality is too high. In simple words, the exchange rate would be stable low in 0.001 USD/POKT. We don’t want this.
While I believe that this is a very unlikely outcome I agree that we need safeguards.
I like this idea, let me explore it. I will test the cases of extreme POKT depreciation:
-
0.0155 USD/POKT(1/2 current price, as reference for main post graphics) -
0.003875 USD/POKT(1/8 current price) -
0.0019375 USD/POKT(1/16 current price) -
0.00096875 USD/POKT(1/32 current price, almost the ~0.001 that is used in the shown calculations)
Keeping the proposed values and setting a hard threshold of RTTM <=500
This simple addition set a cap to inflation of ~20%. Anyway, I feel it is very difficult to reach this situation, as we cannot possibly support all the supply side with 15 K USD / Month, probably the exchange rate is going to stabilize before or the supply side will collapse.
Using the new values and setting a hard threshold of RTTM <=500
The new values mentioned by @msa6867 are:
MaturityRelayCharge = 0.0000035
GatewaysBootstrapUnwindStart = 3 B
MaturityRelayCost = 0.75 * 0.0000035 = 0.000002625
Results are similar wrt supply growth. The main change observed is in the gains of node runners and servicers payments.
Differences in parameters sets
To compare with proposed values to the ones in the analysis, I will use the parameters mentioned here but the exchange rates in the original analysis.
The adjustment of the prices to the supply side and the charges to the gateways moves the supply attrition threshold to ~8 B relays / day. This is paid by a cut of ~50% to node runners incomes. Also the movement of the GatewaysBootstrapUnwindStart does not create a significant change to the supply growth profiles, as the GatewaysBootstrapEnd is unchanged. The extended “stability” of the gateway price is paid with a more step growth of the GatewayFeePerRelay during the gateway bootstrap unwind phase.
Conclusion
While I still wait for Gateways runners opinions on the subject, I have no functional objection on the proposed changes (new values + cap).
I could argue that the proposed cuts to node runners are too high, because we will not reach current levels of emissions (denominated in USD) until ~6B relays/day as opposed to the proposed parameter that achieved this in 4 B relays/day, however this is about projection.
2 Likes
Quick question on one point.
How come the supply growth for the “5% PNF” option doesn’t take into account the current Gateway fee per relay? Not including this artificially makes every other option much more attractive. Unless I’m missing something ?
1 Like
Actually the PNF proposal (ARR) as it is today will be a line just as SER, but crossing the “deflation” threshold at around 10 B relays. Also, same as with SER, increasing the GFPR linearly will create a lower supply reduction target, but this would be a hybrid proposal (not proposed anywhere).
Since the ARR is still a proposal and its behavior is the same as SER, we did not include it in direct comparisons.
The idea of the 5% PNF line is showing where that inflation rate lies. The narrative around ARR is that the inflation will be lower than 5% and many community members stick to that. We wanted to provide a clear comparison to this core component of ARR.
We know that in reality it will be lower due to burning and change of the base supply.
If you feel it is confusing we can remove the PNF tag and just leave 5% reference.
1 Like
If we want to try and make an apples to apples comparison between MINT, SER and ARR, it would make sense to update the slopes for ARR (as per the “PNF 5%” but to make it the 4.98% as proposed) and SER to account for the same GPFR as MINT. There is no reason to expect that MINT will result in higher GPFR than either of ARR or SER. And I don’t think that’s your point in this proposal in any case. It’s more that you would like to give everyone certainty that there will be a rise in the future, even if everyone (the current and prospective gateway operators included) understands this.
I largely agree with the points from @msa6867 on this point that this proposal obfuscates the proposed effect on net inflation - in comparison with ARR - by accounting for a higher GPFR in the future in its model but not for any of the other models.
1 Like
There seems to be some confusion around this point, probably due to resistance in changing how we observe the Pocket economic.
We are trying to transition from a supply-only economy to a supply+demand economy. When there was no demand (no burning) the ecosystem only gained value through seigniorage (minting only). There was only one variable to control and it could be controlled irrespective to other actors. Now we have other tools and we can shape a healthy economy, lets do that please.
-
Are the RTTM and the GFPR independent values?
No.
They are both components of the economic ecosystem and they should balance each other. The community is not unaware of this, the theory of “set burn == mint” is the extreme thesis of this reasoning. -
Does it makes sense to update SER / ARR slopes with the proposed GFPR?
Not really.
There is no proposal for doing so. It is only an imaginary hybrid landscape that wont correspond to neither SER/ARR nor MINT. -
Is the only objective of this proposal to lower supply growth rate?
No.
We are proposing a lower supply growth to keep the status quo. Some argue for higher emission rates to make the protocol more appealing to inversions, we think that it is risky to do so right now, but we can show the investors that it will be good in the future (a future measured in relays by day). To this end we must tie emissions to relay growth (as it was always the idea in Pocket) and to be able to do so (and avoid falling in the spurious emissions trap), we need to increase the GFPR. Without the GFPR change the proposed RTTM change makes no sense and vice versa. -
Do you think that it is possible to propose the MINT mechanims to change GFPR and keep SER/ARR emissions?
No.
It makes no sense to keep one parameter fixed and the other driven by relays. This kind of patch-like solutions is not sustainable. They might be easy to understand but they are really short-sighted. We have new tools now (i.e. burning) we must learn to use them. The fixed emissions were a solution when we had no other tools.
I don’t understand this, we are proposing a direct change of the GFPR.
Neither SER nor ARR proposes any changes of the GFPR. Any expected changes in the GFPR are pure speculation, both in magnitude and time of application, preventing any king of projection or mid-term thinking.
1 Like
To facilitate the exploring of the proposed changes, we have created a small tool that recreates all the graphs in the proposal based:
For those who want it simple!
The tool tries to bring down the proposal to 5 simple questions:
- How much a relay should cost to Pocket Network client
- When should the bootstrapping (by means of lower fees) should end. This is also the golden mark of “deflation threshold”.
- What is the price of POKT that you want to test. All models are impact by this, so use your imagination.
- What is the maximum “inflation” (supply growth) that you want to allow to happen until we reach the “deflation threshold”.
- How we divide the price of the relay among all network participants? Use the slider to define how it is divided. The section in green is how much will be kept by the gateway operator, the section in red defines how much is given to node runners and the last section marked in blue defines how much is absorbed by the protocol. This last part is what will control “deflation” in maturity, if you set it to zero, then we will have “burn=mint”, lower than zero is deflation.
Just hit --------- GENERATE PARAMETERS --------- when you are ready and all the advanced configuration will be filled for you.
For those who want to go deep
The tool enables full control of all the proposed parameters. Feel free to change each of them and explore the results.
This section includes 3 checkboxes that result in:
- Green: Toggle on/off the reference lines of SER and current states. This is useful for some scenarios where the scale of these lines makes the graphs difficult to read.
- Red: Apply the RTTM cap to prevent the minting to go to hyperinflation levels on extremely low POKT prices.
- Blue: Affect the SER minting to the proposed increased GFPR instead of the fixed GFPR that governs them. I added this for illustration purposes as this scenario is not being proposed and it does not exist.
Results
When you are done configuring just hit --------- CALCULATE AND PLOT --------- and see the results of the proposed parameters.
Now the graphs are interactive, you can zoom, pan and see the tool-tips for specific values (who needs spreadsheets…).
Scroll down, there are many graphs. In this picture, the graph on the right is a new one, it represents the earnings of the gateways operators. This was missing in the original proposal and it is indeed important to visualize.
Notes
- If you are lost and messed-up all the values, hit the
--------- RESTORE DEFAULT PARAMETERS ---------on the top of the page to re-load the… default parameters… - There might be some bugs around, please report if you see some weird numbers.
- Yes, graphic design is my passion
3 Likes
@shane I have created an hypothetical scenario where the inflation is contained to 4.8 % always and there is no risk in exotic scenarios (as opposed to BASH)
Go to the sheet “just for shane”
The supply growth curve for every scenario:
The income curves, in USD, for every scenario:
I still do not have the data I need, but I just wanted to show you that it is possible with MINT.
If you say “gateways are earning too little”, that can be changed really easy… just use the playground.
The comments con complexity are just cheap. Formally, BASH is much more complex, I know because I re-created the whole model.
1 Like
Cool! Will take a look 
1 Like
Having finished our inquiries with the Gateways operators (PNI and, soon, NodiesDLB), we present (above) the updated pre-proposal with the final parameter values.
Changes:
- Updated proposal text: simplified version is the default view, with clickable deep-dive option at the end.
- Updated the parameters, now they’re final.
- Added mechanism to cap emissions at 5% of supply.
- Updated the resources to reflect changes in parameters.
- @zaatar and @Cryptocorn suggested edits.
As the new parameters do not create a significant deviation to ARR until 2 B relays/day, we will delay submitting MINT for a vote until there is constant traffic of at least 2 B relays/day (or when we observe any other significant deviation between ARR and MINT).
3 Likes