I’m not a DAO voter so am mostly sharing this to illustrate how challenging it is to be faced with assessing a proposal like this. I feel quite aligned with the response of Dermot and MSA but am especially aligned with this comment:
The reason it resonates so much is because it’s just not clear what is the exact problem this is trying to solve for and it’s really really hard to land on “is this the right answer” if everyone is not crystal clear that we are working on the right problem.
I have shared this previously but I think proposals and debates are a lot simpler when we work sequentially through the logical steps:
Is this a need/problem? Go to next step:
Is it a need right now?
Is this the right solution?
Is this the right team/person (to implement, when relevant)?
Is this the right size/price (to pay, when relevant)?
Mashing it all together feels like a huge cognitive load and frankly I don’t think it leads to good decisions.
Personally I am still stuck at step one and find the “Motivation” section of this proposal quite weak because I don’t think it defines the problem well enough. If the problem statement is:
then it feels extremely lite in comparison to the solution offered; the solution offered seems so large and complex; and it feels like there is a deeply wrong assumption behind it all that somehow node operators aren’t encouraged to see network growth. If there is a node runner who does not believe 10B relays will be better for Pocket Network (and their bags) than 1B please can they explain: Why?
I appreciate the depth of intellectual rigour around the solution and I’m very open to being led to the conclusion that this is the right thing at the right time. But unless there is a real evidence that misalignment of incentives means we are not all invested in the growth of Pocket I don’t see why this needs to be done in the v-0/pre-v1 era, and I definitely can’t assess why 10 new parameters is the optimal solution.
Thanks for the answer - this is exactly what I was hoping to hear.
I continue to warm up to the methodology here, even if in the subsequent proposal some of the parameter current values may have to be changed, especially on feedback from Nodies/PNI on realistic numbers that would allow them to operate Gateway businesses effectively. I make the assumption that the proposal is relatively flexible to change the parameter values based on feedback.
@msa6867 - Without going too far off topic, the Era budget has ~$30k to help Gateways at present. I think that this number will need to be significantly increased to allow Gateways to flourish as we think will be beneficial to the ecosystem. While that debate belongs in the Era discussion, it move to the above with the question of ‘how and how much are we going to subsidise relays for Gateways?’ We could either keep the 0.00000085 price static for a longer period of time, or raise it earlier but then send direct subsidies to the Gateways to help offset these costs amongst others. Either way, the DAO is in effect subsidising the Gateways.
Thanks for the clarification. I agree that direct DAO-to-gateway-provider grants may be a better mechanism to help new gateways navigate the start up period than keeping GFPR artificially low. That would be in keeping with the proposal objective of " * Correctly identify which participant in the network is being subsidized by the DAO" and could help answer @Dermot 's objection of hindering the growth of the demand side
I think it’s also beneficial that by subsidising the Gateways from the DAO directly, the amount of POKT burned increases as the GFPR increases - so will help our placing on metric boards, instead of subsidizing at the GFPR level and lowering the amount burned.
Ultimately its going one way than the other to reach the same destination, but the optics and marketing are far better if we significantly increase the burn.
@b3n - I have been meaning to write some of the above on the Era budget proposal, but i’ll wait for your update. TLDR - more money to adequately subsidize the Gateways to fulfil their potential.
While I don’t fully understand all the calculations behind each variable, this gives us a chance to see what the effect would be in different scenarios. I understand that sometimes a model can’t have simplified math, so having the math in an expressive form that shows the effects, is key. Much thanks
From my initial glance, I love the concept of allowing growth in node rewards in accordance to relays. That was the intended design of POKT from the begining, and I don’t think any ecosystem can function in the long term without a common incentive… which for POKT should be driving relays.
However, I don’t see how this model will work. When I set the Projected Results to Month, set the Relays Per Day to 10B, the Gateway Burn is $1.4M+ a month. I added a few extra field to show the actual cost per relay, and as you can see, it’s only a few digits from what the Portal charges their customer per relay. With this high of a burn rate, gateways would have to increase their prices to Infura level prices… eating away the primary advantage of POKT, cheaper relays.
A gateway like Nodies already has infra that is supplemented by POKT rewards… so why would they use POKT at all, especially if the burn cost is that high?
It would also be significantly cheaper for gateways to just run their own infra instead of the $1.4M+ a month charge. I can’t see how that would work.
While I love the concept, but I don’t see how this high of a fee is possible at this time.
However, I’m not sold that we have to cut everything down to be deflationary at 10B a day. I’m not sold that it is the golden bullet to start us down the right path. I’ve maintained that I believe the greatest value to the ecosystem would be something that encourages folks to lock up POKT, in either staking or some other mechanism.
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)
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.
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. )
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:
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.
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.
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.
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.
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.
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:
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.,
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.
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:
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
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.
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 ?
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.
