This is a lot of information to parse. Can you dumb this down a bit?
1 Like
At first read, this seems to make a lot of sense. Cutting emissions, incentivizing Node-runners & Gateways to optimize paid growth and giving future rewards prediction stability.
I look forward to read @msa6867 and @shane’s thoughts amongst others.
Without getting too ahead of myself, I’d be interested to see this as part of a ‘Grand Bargain’ to also change the Era budget to increase subsidies for Gateways and then incentivizing Gateway growth both to process more paid relays + start other revenue generating activities.
2 Likes
For MaturityRelayCharge:
Is it expected that Gateways will be free to charge end clients their own price structure, perceived to sit somewhere between the differential of the 75% - 100% of Infura’s costs?
I.e. so they would be expected to charge 85% of infura’s cost, making 10% and their customer ‘saving’ 15%. At maturity.
If so, how does Infura bulk pricing affect this?
1 Like
Yes, but that number is arbitrary. Using Infura as a benchmark might not be the best and maybe 75% of their rate leaves to little space for gateways. So, this number can be discussed and modified.
We are more interested in the concept of setting a MaturityRelayCharge than the exact value. We actually expect to reach some consensus about that in this thread and I look forward @poktblade and @ArtSabintsev comments on that (and any other potential portal operators).
2 Likes
Let me try…
Think of this as setting up two milestones and two relay prices:
For Node Runners
- Set a value that you wish to pay them per relay (
MaturityRelayCost) - Set a number of relays per day that signals the end of the “bootstrapping” (
ServicersBootstrapEnd)
So, the idea is that you know how much the protocol will pay node runners after you have more than ServicersBootstrapEnd relays per day. Before reaching this threshold the DAO will pay the node runners more to build up the supply side.
For Gateways
- Set a value that you wish to charge them per relay (
MaturityRelayCharge). This is the amount of POKT per relay that they will be paying the DAO to be burned. - Set a number of relays per day that signals the end of the “bootstrapping” (
GatewaysBootstrapEnd)
The idea is the same, until you reach the selected number of relays per day (GatewaysBootstrapEnd) you will charge them less in order to help them kickstart the demand side of the network. After you reach the selected threshold, you charge the full price.
What about all the graphs and stuff?
The rest of the post shows that this approach will not mint more than the current scenario (SER) and explores different situations.
Also, we show that we will reach “deflation” at less than 10 B relays a day (the current proposal of PNF targets this value).
Finally we show that with this approach the node runners will be interested in the relay growth of the network, as opposed to the other proposals.
Are the relay prices that you give definitive?
No. We actually care more about the model of the MINT strategy than in the actual values. Fell free to propose new value sets.
3 Likes
Hey @RawthiL thanks again to you and the POKTscan team for all your amazing contributions over the years, and almost every week at this stage.
And this is another genuinely impressive contribution, even if I believe that this proposal isn’t what Pocket needs right now, as it will cause more harm than good if introduced.
In responding here, I am also bringing some of our private conversations to the public sphere.
Unclear Purpose
First off, my main concern is that it’s unclear what the actual objective of this proposal is. If it’s simply to prevent inflation from dropping as low as 4.98% (as per the ARR proposal), then it would be better to argue about this directly rather than introducing so much complexity and governance overhead by way of the introduction of 10 new parameters to govern and update over time. Notwithstanding how thoughtful this proposal is, it will still be way too unwiedly for new contributors to grok.
Further, given that we are about to start a major first principles review of Pocket’s economics as part of the economic R&D workstream for v1, it is unlikely that this newly proposed system will be relevant for v1, or even in a few months. So the cost/benefit is unclear.
Doesn’t fix inflation concerns
Secondly, in addition to the point above, it is highly unlikely that this proposal will achieve our primary aim at PNF (with the ARR proposal) to:
Partly because this proposal has so many parameters, so it will be harder for the message to cut through, but also because MINT allows net inflation to increase again in the future, even though it is expected that such a higher number of relays, meaning more protocol burn and more demand for Pocket’s service would result in a higher price of POKT, which could mean even additional increases in payments to Pocket’s supply side, in terms of both the quantity and value of POKT, without clear justification for doing so.
Node runners are some of the largest holders of POKT; if they don’t care about the network’s success, then we have much bigger problems to worry about. Can you explain why node runners wouldn’t care about the growth in the value of their POKT?
The supply side benefits from capital appreciation from their POKT stakes and revenue growth from servicing relays in the network. So I disagree that the supply side won’t benefit from the network’s growth and success.
This proposal hinders the growth of our demand-side
Thirdly, the attempt to program the protocol fee for gateway operators seems to be an unnecessary distraction prior to v1. In any case, it’s much harder to grow demand than supply. And any attempt to reduce the incentive to grow Pocket’s demand side will cause us all to suffer. We see this in our conversations with new gateway operators who are worried about the cost of each relay they bring to the protocol. The protocol fee is clearly low, but it’s still a barrier to growth when Pocket currently has a tiny fraction of the market.
The fact is that no gateway operator is yet profitable. So this is an attempt to deal with a problem - excess profits of gateway operators - that doesn’t yet exist.
Is POKT money or capital or both? And what should we optimise for right now?
Lastly, I acknowledge that we have fundamentally different views of how Pocket’s economy should be designed and structured and how stakeholders benefit from their role within the ecosystem. For example, you have mentioned several times that you believe that POKT should be analysed in the context of money. This is a much longer conversation, but my main pushback on this is that without designing the Pocket ecosystem so that POKT becomes a true store of value - as opposed to a cryptocapital asset or a cryptocommodity - the velocity problem will make POKT’s value capture potential difficult, to say the least. I view POKT as a combination of a a cryptocapital asset and a cryptocommodity, and I refer you to the work of Placeholder in this regard, as my views largely reflect theirs - Value Capture and Quantification: Cryptocapital vs Cryptocommodities — Placeholder
The question of the sustainability of Pocket’s economics is genuinely holding back new contributors and capital providers from joining the community. Reducing protocol inflation in very clear and explicit terms will give confidence to the outside world that Pocket is on the right path, making it easier to incentivise more talent to join us and raise Pocket’s profile to the world-class level we are all aiming for.
Pocket’s supply side will get paid more and more in direct fees over time for their work and will also benefit from the capital appreciation in their stake. Excess rewards will get competed away by other more efficient networks, and the more we overpay the supply side, the more we risk causing another unsustainable boom and bust cycle, just like last year.
2 Likes
The purpose is not just to bring down inflation, it is specifically about adding “something else”. We used the 5% reference to make sure that this proposal is not regarded as a greedy proposal coming from a node running company.
The intention is to reduce inflation and more importantly give perspective and projection.
The V1 research will be way more complex than this proposal, simply by the number of network actors that it must include.
I dissagre that this proposal will be irrelevant in V1. We tried to avoid making assumptions about the distribution of the relays incomes (servicer / validator / DAO splits) and we focus solely on the Pocket Networks export product price, the relay.
In V0 and as well in V1, the only source of incomes that the protocol will have is the commercialization of relays. The relays being sold to the public will be paid in POKT at a price given by MaturityRelayCharge and the protocol will incur in costs for producing them given by MaturityRelayCost. This mechanic exceds V0 and is completely applicable in V1.
The research in V1 will have to deal (among other things) in how to distribute these rewards among the new actors.
As I understand it, this argument can be summarized as:
Node runners are POKT holders and they will benefit from the increase of POKT price.
We disagree with this because:
- Makes assumptions about node runners POKT treasuries.
- Bounds success of supply side to a non-controlled variable such as POKT exchange rate.
- Works against the attraction of new builders (the cited point), since new node runners have no “bags”. If the intention is to only attract gateways or other types of builders, then the quote should be modified.
They do care about the value of the POKT token, but they clearly dont care about how many relays are run through the network. This is observed in the TG chats, where relays ATH are disregarded (with a large amount of trolling) by holders and node runners alike.
This is indeed the main friction portion of this proposal, but we are trading what we think is a small amount of friction for a clear view of the mid/long-term operation of the network. As a gateway operator I would be more worried about the real cost of the relays than the actual one.
Anyway, the ones that should give their opinions on this subject are the current portal operations, PNI and Nodies.
I will answer this later in the main thread. The topic is indeed a long one, and the article you cite (and the larger one that is the base of its assumptions) is very interesting (contrary to our views tho).
(to everyone else trying to discuss the POKT token nature please refer there)
4 Likes
Before looking into details, here is some top-level feedback.
-
The proposal will be cleaner and easier to follow if you do not introduce new DAO-governed parameters. The only two actual parameters being modified are RelaysToTokensMultiplier (RTTM) and GatewayFeePerRelay (GFPR) [introducing a new acronym for ease in the following discussion). Everything else is simply instructions to PNF on how to set the parameters on a week by week basis. This is consistent with how WAGMI, FREN and SER were structured, where RTTM is the single parameter being modified, but along the way intermediate concepts are introduced (target inflation in the case of WAGMI, target daily emissions in the case of FREN and SER
-
This is a v0-era proposal (RTTM is not a v1 parameter and GFPR is set to be removed with v1). Description would be helpful on (a) why this is needed in v0 vs "can it wait til v1 and (b) what is the intended transition of the concepts contained here into the v1 context
-
If at all possible, I suggest separating this into two proposals, one for setting GFPR and one for setting RTTM. If not possible, I suggest adding to the rationale section why it is absolutely imperative to set both parameters in tandem. As it stands, it seems like GFPR and RTTM are being set completely independent of each other, and their being adjusted jointly in a single proposal is mainly so that the net emissions are seen to be well contained. This makes it hard to do apples-to-apples comparison between your proposed methodology to set RTTM, and the SER and ARR methodologies. (Net emissions for SER and ARR would also look rosier in an environment of linear-increasing GFPR vs the current static $0.00000085.) I envision your having a GFPR proposal that is completely stand-alone without reference to any other parameter and a RTTM proposal that is competing with ARR and SER for methodology to finish out v0 that may have dependency on GFPR. The benefit is that (a) adequate focus is given on right-setting the value of GFPR which will be a highly-contentious topic and (b) an alternate RTTM methodology to SER and ARR can be discussed and considered even if the DAO is disinclined to adjust GFPR at this time.
-
I think there is universal agreement that GFPR = $0.00000085 is a highly-subsidized rate , not a “maturity” rate. and that the goal is to raise this (on the on-chain app burn equivalent in v1) over time. The rationale I think you need in your rationale section is why we should consider defining, right now, the movement toward maturity vs simply letting the system settle down at current values and revisiting right-sizing GFPR some months down the road.
-
Likewise, there is (I assume) near-universal agreement that in maturity emissions will grow, likely linearly, as paid demand (app burn and/or gateway fee&burn) grows and the the WAGMIFREN/SER/ARR construct of suppressing emissions from growing as demand grows is a temporary mechanism only to reign in inflation. The rationale I think you need in your rationale section is why we should consider reintroducing, right now, the growth of emissions as relays grow, versus holding off until RTTM is brought closer to maturity-level values.
A common theme of #2-5 above is to make the Rationale section more about why the DAO should choose the methodology outlined in this proposal vs keeping with the status quo or choosing a competing proposal (e.g., ARR), rather than about the specifics of parameter values. Perhaps the latter could go into a new section that includes not only the nominal value listed but also a ball-park range of what you see to be the “sand-box” of possible values to consider for the parameter in question.
4 Likes
I certainly empathize with the desire to reintroduce the growth of emissions as relays grow and we have discussed privately the deficiency of WAGMI/FREN/SER in regard to this decoupling. Have you considered the much simpler proposal of simply tacking on an extra component to emissions equal to a percentage (less than 1) of GFPR-based treasury burn; e.g., that could be a stand-alone proposal to modify SER or you could work with PNF to amend ARR proposal to include a percentage-of-burn component to emissions. This really is in keeping with the march toward maturity idea of burn&mint with an ever-decreasing subsidy,
On the other hand, I do think the misalignment of node-provider incentive to grow relays compared to gateway-provider incentive to grow relays is over-stated. Gateway providers are essentially wholesalers - the sales-people of the system. Their pay is entirely dependent on their sales effort. And their pay is naturally and singly tied to their ability to bring it sales at a cost higher than the wholesale cost they are being charged. Node providers are more like the widget makers of the factory rather than the sales people of the factory. Of course we want the “widget-makers” to be evangelists for the widgets they make, and the factory offers referral incentives etc, but ultimately the factory relies on it’s sales force to bring in sales. Of course, your point is that it is reasonable for the widget maker to expect to get paid based on the number of widgets it makes… totally true once the system reaches operational maturity, but in a period of time where the compensation is still mostly subsidy, I think it is equally reasonable for the widget makers to grow into fixed subsidies that are set in a way to optimize efficiency over quantity
3 Likes
Regarding the GFPR methodology you outline, it is a fairly sound approach (if potentially a bit premature) assuming a single-party gateway provider. However, in a multi-party environment, such as the one we are now entering into, it is not clear that the approach is tenable.
In a single-gateway environment, it is reasonable to reduce wholesale-price subsidies as a function of total system relays, as it is reasonable to expect the gateway provider to become less reliant on subsidies as it grows into its economies of scale. In a multi-party environment, the economies of scale each gateway provider is able to achieve is based solely on traffic handled by that provider, not on the traffic handled by the entire system. Therefore, there is no basis for setting subsidy levels on the total system traffic.
Since GFPR is an off-chain parameter meant to get us through the remainder of v0, perhaps it is possible to re-invent it as being able to take on different values based on gateway-provider-specific metrics. I.e., base the fee level not on total system relays, but on the relays served by each specific provider? That way greater subsidies can be given to start-up gateways to incentivize their start up period, with subsidies being reduced as they mature and achieve economies of scale.
@cryptocorn - Could you clarify this comment/question? The ERA budget contains some funds for on-off grants to help bootstrap new gateway providers (“this is a funding bucket for supporting their launch regarding legal, docs or any other small support needs they may have to go live.”). This is independent of and outside the scope of the manner in which “subsidy” is used in this proposal with respect to gateway providers, namely the charging of a wholesale rate that is below fair market rate for the protocol-level service being rendered to the gateway (wholeseller).
1 Like
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.
2 Likes
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.
1 Like
Yes, not to distract from this discusssion but I will provide an update on this in the PEP60 thread soon
2 Likes
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
2 Likes
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.
2 Likes
Thank-you @RawthiL for the model you provided! MINT - Calculate RTTM and GFPR - Google Sheets
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.
3 Likes
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