PUP-23: Stairway to Sustainable Economics

PUP-23: Stairway to Sustainable Economics

Attributes

Parameters:

  • USDRelayTargetRange

  • ReturnOnInvestmentTarget

Current Values:

  • $0.0000018 to $0.0000031

  • 10 months

New Values:

  • $0.0000068 to $0.0000113

  • 24 months

Summary

Pocket Network is actively working on Portal Monetization and the topic has arisen in the comments of the following Forum posts here, here and here. In anticipation of releasing the Portal Monetization product we feel it’s important to update the effective app stakes cost for the service that Pocket Network is providing.

While the growth, speed, and quality of service of our network has increased and we have seen increased demand for App stakes, since May 2021 Pocket Network Inc has been pricing our offering based on the guidelines of PUP-7: Whole Lotta Requests. In this previous proposal, Pocket DAO set the parameter values for 1) USDRelayTargetRange (as a reflection of USDTargetRelay), and 2) ReturnOnInvestmentTarget. This proposal PUP - 23: Stairway to Sustainable Economics aims to update these parameters so Pocket Network can proceed with Portal Monetization and complete our economic flywheel.

The main objectives for this proposal are to:

  1. Contribute to sustainable economics: by increasing the cost of an app Stake, we can price the Portal service for dApp users to align with the value they are receiving.

Our current prices were calculated in a different environment when our quality of service, brand recognition, and breadth of blockchain support was not as competitive. Given that we have invested time and resources to overcome those pain points, we are in a much stronger position to offer a product of higher value and capture revenue for the community.

  1. Increase the security of the network: by increasing the price tag for a malicious actor to effectively buy the demand side of the network, we can make our help make the network safer.

By preventing our app stake costs from being disadvantageously cheap in environments when the POKT token price is depressed, the cost of capturing the App side of the Network can be increased and reinforce our safeguards

  1. Unlock Portal Monetization: by removing barriers to properly implementing shipping revenue collection, the Pocket Network portal team can update the price to reflect the cost to run the network.

The existing price was meant to be digestible for prospect users for only upfront costs. Now that we prepare to ship the Portal Monetization product, we will allow that upfront cost to be spread out. This means we can increase the price while keeping the price tag digestible for prospect users. This increase means an additional amount of POKT that will be purchased in the open market.

Of note: Portal Monetization proceeds will flow into the open market. If the Portal users pay in fiat, stables or other tokens, the payments will be converted to POKT in the open market in a transparent way that is outside the scope of this proposal.

  1. Stabilize the price: by adjusting the cost calculation methodology to reduce the variability of app stake cost, we ensure a reliable cost-basis for the user.

The existing methodology was too dynamic and dramatically dropped prices for Pocket’s service based on competitors’ entry into the market. This proposed methodology is more reliable and less susceptible to new competitors subsidies, irregular changes, and possible price wars.


In these respects PUP - 23 is an extension to PUP - 7. As a result we take note of famed philosopher Robert Plant who once sang: Pocket Network’s infrastructure is as solid as gold and so we’re are building a “Stairway to Sustainable Economics”.

Background Info

Why does the DAO delegate price adjustments?

For more detailed background information on why the DAO delegates price adjustments, please read the section of the same name with the original PUP - 7: Whole Lotta Requests proposal. As a TLDR,

The DAO Constitution then delegates the operational responsibility of price adjustments to the Foundation, by giving the Foundation the permission to adjust on-chain parameters in order to fulfill the USD targets.

This was designed in anticipation of the need to be operationally responsive to price fluctuations, along with the desire to minimize the operational burden on the DAO. Thanks to these measures, the DAO only needs to vote each time they want to adjust the $ price, rather than every time the POKT price fluctuates

Why should the DAO update the price?

The current cost for a Pocket app stake is 10x the cheapest monthly cost of our competitors. This is what we currently quote dApp developers, ecosystem foundations, and strategic partners. Regardless of the price of POKT, this is an estimated $950 USD per million daily relays as a one time cost (as of July 2022). When we wrote the original proposal, the cost was $2.7k USD per million daily relays.

This proposal aims to do this by adjusting 2 things:

  1. increase the multiple from 10x to 24x the average monthly cost of our competitors.
  2. recalibrate the way we calculate the multiple
    – from cheapest cost of our competitors
    – to the average of the 2 highest cost competitors

ReturnOnInvestmentTarget = 24 months

In PUP 7, this value was voted on as 10 which is a proxy for 10 months of cost upfront to own the app stake. In this proposal PUP - 23, we propose this value be 24. This essentially would increase the cost so it goes from 10 months of the average of centralized competitor rates to 24 months of the same rates.

This 2.4x multiple on the most recent rate is important to get back us to sustainable economics by leaning accomplishing the following 3 main goals:

  1. Leveraging the fact that Users own their infrastructure
  2. Generate more demand side revenue for the ecosystem
  3. Unlock the Portal Monetization product

Own your infrastructure

One of Pocket’s unique advantages is that staked dApp users effectively own the bandwidth they use. This is meant to align the interests of the users with the network. This is not true of our competitors which will give users 10 months of service at this same price with no equity, stake or ownership of the bandwidth. Centralized competitors have implemented SaaS models that are meant to keep users paying in perpetuity.

More demand-side revenue

By collecting more demand-side revenue from app stakes than we have in the past, Pocket Network is able to bring relief to the entire ecosystem. With a higher cost per app stake, we can increase the amount of POKT demand side buying pressure which would provide new liquidity into the market and benefit the supply side of our ecosystem which currently gets paid in POKT.

With the estimated cost of the supply-side of the network decreasing after PIP - 22, PUP - 19 and the light client, we have an opportunity to make the most of the existing market of available relays. If we estimate a capturable market of $5M monthly recurring revenue across the RPC industry today, that’s over $120M of available application sales available to us, not including growth of our nascent industry.

This provides a strong counter balance to decreasing the annual cost of operating Pocket Network to under $5M a year. This proposal unlocks the Pocket Portal to take any equivalent payment of stable, fiat, and other limited Native tokens, and funnel that revenue into purchasing POKT on the public markets. This would be an additional option to any users who of course can bring and stake with their own POKT tokens. This closes the loop of the two-sided marketplace we have intended from the beginning.

Unlock the Portal Monetization product

The Pocket Network product team is adding a 2nd option to the user to spread their app stake over time. At present this option doesn’t exist, and the Portal Monetization process aims to productize the collection of revenue using different payment methods. The objective is to reduce the barrier to entry for those who are unable to pay for a full POKT stake up front.

USDRelayTargetRange = $0.0000068 to $0.0000113

This parameter range wouldn’t change with this proposal. Pocket Network would continue to adjust it dynamically based on the details outlined in PUP - 7.

USDRelayTarget = $0.0000091

The way we calculated the parameter is not as relevant due to recent developments. Hence we propose we update it (and the < USDRelayTargetRange > as a result). In PUP - 7, the methodology was such that we took the lowest price point among competitors as outlined below:

The last point is the strongest factor in our opinion, which is one of the reasons we’ve been subsidizing relays until now. It is our view that we should maintain a cheaper price at least until we have caught up to our competitors with quality of service and usability.

To achieve this cheap price, we take the minimum cost being offered by alternate service providers, attach a target buffer that pads the lower and upper end for a target range, and then adjust off-chain governance parameters that make up the Relay Throughput (see appendix).

Now that Pocket has caught up to our competitors with quality of service and usability, we feel compelled to revisit this. When we wrote this proposal there were 3 competitors and prices didn’t change much . Since then there have been 2 additional competitors to the list and we have seen prices change significantly.

Given the introduction of new tiers as well as a generous expansion of free tiers from our competitors, there has been a race to the bottom as far as pricing. In May 2021, the cost for ~1 million relays was ~$2700 USD. Right now, the adjustment of the has cut that cost to ~$950 USD. Simply put, this means that the PUP 7 methodology could return less and less revenue to the pocket token economics (and the community members, token holders, and network participants as a result) over time.

As an alternative, we propose that we remove the calculation of being a monthly multiple of the ”minimum cost being offered by alternate service providers” and replace it with being a monthly multiple of the average of the 2 most expensive being offered by alternate service providers. Remember, since POKT is the token of Pocket Network’s economy users are also owners in the value accrued to POKT (e.g. “Web3 is the internet owned by the builders and users, orchestrated with tokens” - C. Dixon), this commands a competitive fee as it is a distinct difference relative to alternatives who are extractive from their users.

This provides the network with the following benefits:

  • Less thrash: since we are taking an average of 2 values, no single price change will drastically change our overall pricing scheme.
  • Premium servicing: by taking the 2 most expensive of alternate service providers, we are anchoring to those best in class who are bringing in real revenue vs. the recent projects that are offering close to free service by subsidizing demand
  • Competitive economics: by taking the 2 most expensive of alternate service providers, we are working towards returning as much revenue to the Pocket Network as our competitors extract from their user base. Originally, we were taking the least expensive of the original set of 3 competitors. Now that there are significantly more competitors with only a limited offering, we want to avoid partaking in a race to the bottom among them.

Anti-goals

To achieve the 3 main goals listed above, this proposal is intended to be as focused as can be. For this reason, we also have the following anti-goals:

  1. Competing with other providers solely on price

We maintain that our unique decentralized product with a staking model is not an apples to apples comparison with others.

  1. Overanalyzing or “boiling the ocean” in trying to find a single cost for every user persona

Our competitive intelligence exercises have revealed a myriad of pricing strategies across other infrastructure providers based on different products. It is extremely complex to calculate fixed app stake cost with a pricing structure that varies based on use case. As a result, we intended to keep the protocol level app stake cost uniform.

  1. Relitigating PUP -7

This proposal is merely an extension of the previously voted upon PUP - 7. That proposal was based on Pocket’s unique protocol design and PUP - 23 is not meant to take a affirmative or negative stance on that decision; it is merely meant to update the parameters to match the current environment.

# Conclusion

These proposed 2 parameter changes in tandem will make Pocket Network token economics more competitive, predictable, and accretive. Revenue design can be a large strategic decision, and doing so on a protocol level is even more difficult. However, it is clear at this point that we have to first start by remedying PUP 7 in order to get cost calculations back on track so we can ship Portal Monetization. Ultimately, this will be the first among several steps down the path (or up a stairway) to more sustainable economics.

Dissenting Opinions

We should leave the parameters at current levels

Leaving the parameters at the current levels runs several risks. They are outlined in the section above. As a quick recap, leaving the app stakes costs where they are now broadly put us at risk of not achieving 1) economic sustainability, 2) network security, and 3) Portal Monetization adoption.

However, an equally important business issue is that Pocket Network could be “leaving money” on the table. This 10x the monthly average of competitors rate was calculated when the cost of running the network was significantly lower, our quality of service was not as competitive as our centralized competitors , and Pocket Network had less brand recognition.

Several developments have happened since then:

  • Our quality of service has improved to even exceed our centralized competitors on critical performance metrics (creating more parity between us and the centralized route)
  • Our brand recognition has improved greatly (unlocking partners like Polygon Studios, Aave, and Harmony that were reticent to be users back then)
  • Our support of various blockchains has broadened (expanding our total addressable market and users that are willing to pay us for critical infrastructure services)

While we have users that are paying to use our service now, we are confident based on our business development conversations that we can charge more for service, add the product feature to split that cost out in monthly installments, and infuse more buy pressure for POKT in the open markets.

Won’t raising app stake prices make demand go down?

This is a valid concern. It is intuitive that all else equal, customers prefer a lower price.

However, there are a couple of details to outline here:

  1. We are not raising app stake prices in a vacuum

We are actually restoring prices to be comparable to what we had originally proposed, and then increasing it over a longer period so our Portal Monetization pricing structure is more sensible. We are not proposing we change the price out of turn. We are proposing we change the price so make progress on the Portal Monetization strategy.

  1. Our unique staking model means that “all else is not equal”

We maintain that since our Node Runners give a service on a perpetual basis based on the staking model, our competitor’s SaaS model should not be equated to the pricing model that Pocket offers.

  1. Price can signal the quality of the product

Our Business Development team has received multiple data points that there are competitors that offer their services for free on an ongoing basis. We have also seen offers from competitors win deals from apps and blockchain foundations that are in the seven figure range. Given the rationale outlined in sections above, we are confident that our proposed price point signals a high quality of our product. When we were bootstrapping the network and only single digit million daily relays, we largely subsidized our network. Now that our service has improved and we have scaled into more than a billion daily relays, Portal Monetization aims to have the price signal a better quality.

So how much will this cost to the User? Why are these costs so confusing?

Adjusting parameters are the mechanism for the DAO to give guidance to Pocket Network. Changing these 2 discussed parameters values update the cost of an app stake which is a main input into Pocket’s token economics. The cost of an app stake dictates how much the demand side pays the protocol for the service that the supply side provides.

Using this guidance, the price of a Pocket endpoint will reflect these values:

Scenario USDRelayTarget* ReturnOnInvestmentTarget ~ Cost per million daily relays (USD)
Original PUP - 7 values in June 2021 - 10 $2,375
Revised PUP - 7 value in February 2022 $0.0000025 10 $950
Newly proposed values with PUP - 23 $0.0000091 24 $6,625

Source 1 2 *using an updated calculation for Price per Relay

With these costs in mind, Pocket Network (and any other Portal service provider for that matter) will price service accordingly.

Portal Monetization will introduce various payment methods over time. Regardless of which option a user chooses, they will still pay approximately the same price that can cover the ~ Cost per million daily relays for how many relays they are staked.

Interestingly enough, if other parties build and operate new portals, they can use whatever pricing structure they desire. They can decide to set a price more than or less than the cost for an app stake. However, their cost for an App Stake would be the same protocol level for ~ Cost per million daily relays.

The calculator that guided our cost model seems to have changed.

Correct.

Pocket Network Inc uses these tools for guidance. Based on community member feedback, we propose to simplify the model and reword some of the terms.

The main difference is that we updated the USDRelayTarget to have the same calculation as a Price per Relay. This is not a linear calculation because each competitor measures a request different (Pocket uses a relay, Alchemy uses compute units, Quick Node uses API credits, etc). This proposal is a useful occasion to standardize our pricing models as best as we can.

Previously we were using a larger unit value that was particular to how we calculate base throughput. However, with a more standardized Price per Relay, we maintain like the math is clearer. This adjustment also shows the previous values for PUP - 7 for comparison purpose. Regardless of the outcome for PUP - 23, we are inclined to use this updated USDRelayTarget definition, and so it is important we highlight these changes in the calculator.

Why more expensive than the competitors?

In the section <Why should the DAO update the price?> we outline why we think Pocket is unique enough to warrant a premium. This rationale is long standing and based on our unique protocol.

However, there are some additional considerations that expand on this and further justify why our service would be worth more to a user.

  • We are not charging additional per call type (Alchemy, ANKR and Quicknode charge more based on how expensive the call is )
  • We are not limiting number of endpoints or number of networks
  • We support more networks than any of the competitors

These features that may change over time for both us and competitors. These are not based on protocol, but Pocket Network has no reason to change them any time soon.

In it’s totality, Pocket Network’s product design and features makes a unique value proposition to users.

Aren’t all stakes close-to-free anyway due to Gigastakes?

Nothing will change about how the free tier is configured as per PUP - 9: Gigachad Pocket Portal Free tier. For context, Gigachad stakes is a technological design that enabled Pocket Network to provision app stake access for free tier usage during V0 product design. Until V1, Gigachad stakes will remain in place for scalability reasons regardless of the outcome of this proposal.

The cost for app stakes laid out in both PUP - 7 and PUP - 23 is the quoted rate we use for dApp developers, foundations, and new chains. This guides us in collecting revenue for the demand side access to our network, beyond the free tier. Nothing about the free tier is impacted by these proposals.

Won’t this impact my current Node economics?

This will actually positively impact current node economics. All else equal, the economics of PUP - 23 will increase the demand-side buying pressure by ~7x of POKT and should be a positive force to token economics. This would in turn, positively impact POKT token economics thus adding to node operator revenue (in fiat terms), and slow down the impact of inflation.

This would adversely affect the Node Runner configuration

These parameters should have no impact on node configuration as it has been the case in the past.

Applications won’t pay this much in advance

This is actually one of the main impetuses for our Portal Monetization strategy. We aim to give the option for users to pay this amount over a longer time period and then be rewarded with ownership of the stake at the end of the 24 month period.

Additionally, it is much easier to lower prices rather than increase them when going to market.

Copyright

Copyright and related rights waived via CC0.

Appendix: How Relay Throughput is Calculated Based on Stake

The relay throughput for an application is determined by the MaxRelays parameter, which is defined by this Protocol Throttling Formula:


MaxRelays = StabilityAdjustment+(ParticipationRate∗BaseThroughput)

Base Throughput

The purpose of the Base Throughput is to set the number of Relays an Application can get based on how much POKT they stake. This is the most direct way to adjust the Max Relays for the long-term and is updated at the discretion of the DAO.

For more details on the Base Throughput, see the documentation here.

As noted, the BaseRelaysPerPOKT parameter is not suitable to be fully-automated as it is susceptible to the Oracle Problem. As a result, it is incumbent upon the DAO to regularly adjust rates based on what we vote on as an acceptable cost structure to Apps.

8 Likes

I strongly support this proposal.

4 Likes

I support this proposal

2 Likes

A couple quesions before I am ready to comment:
First, PUP-7 states, "We assume, based on existing business development conversations, that an App Developer is willing to pay 10 months of a competitors monthly service cost for a one-time cost to use Pocket in perpetuity until Application Burn Rate is implemented. " Can the authors please clarify if “in perpetuity” truly means in perpetuity (iethe appeal to ABR in the above phrase is only referring to stopping the offering of in-perpetuity relays to NEW clients or ADDITIONAL relays to existing clients one ABR kicks in) or if usage of “owned” daily relays curtails once ABR is implemented for EXISTING clients?

Second, in both the existing model (10 mo) and proposed model (24 mo) is the total payment REQUIRED upfront and in advance or are app devs allowed to pay monthly over an extended time (there was some chat earlier in TG that made it seem like the latter was intended)

1 Like

Here’s the big question - we’re having trouble onboarding more dApps with our current pricing. How is increasing the cost 4 times going to affect adoption?

Let’s assume we adopt PUP-23 , we manage to monetize half of the monthly billion relays, and bring in 500X$275 = $137,500 worth of revenue every month. We’re minting 400,000,000 *0.08 = $32,000,000 per year, or $2,700,000 worth of POKT per month. Even if we reduce inflation to 20%, we’ll still be minting 10x what we’d be taking in, and that’s at current prices - if POKT price goes up, servicing cost goes up, while revenue stays constants since it’s tethered to USD.

I can’t help but feel that , under the current circumstances, this type of price increase, in isolation, will impact the network negatively in the long run while creating little token demand compared to emissions in the short run . Our goal should be to get dApps invested into the Pocket ecosystem. We’re not looking for customers, we’re looking for partners, because this is not a traditional retail product. And dApps are just as important participants to the Pocket ecosystem as node runners. We need more dApps, we need more relays, we have plenty of nodes runners.

To that effect, and this might sound blasphemous, but I think we should consider rewarding dApps that sign up and pay for the service in the same way we rewarded node runners, get them invested into the ecosystem, and bootstrap the demand side. I think dApps that choose to partner with us and pay for a 24 month stake UPFRONT should be credited 5% of POKT emissions generated by their relays, and DAO fee should be raised to 15% in order to cover that. So, if we mint 200 million POKT, 10 million POKT should be distributed yearly to our staked, paying dApps. And, as inflation reduces, rewards reduce naturally, until we reach 0 inflation and ABR kicks in.

At current RelaysToTokensMultiplier of 1371, a dApp staking and producing 1 million relays daily would earn 1,371* 30 * 0.05 * 0.08 = $164.52 worth of POKT per month, or 60% APR. This can be used to increase their daily relays cap and support their application growth, or sold for cash. With only 5% of POKT emissions even at 20% inflation we can drive major adoption. Or we could go 10% if we want to make a splash.

Let’s reward early adopters and encourage dApps to become more than customers - partners of the Pocket network, invested in the long term well being of Pocket.

3 Likes

Daily throughput has tripled in four months. What are you basing this on? If it’s the “staked apps” number on C0d3r, that’s not a reflection of onboarding, it’s usage of the gigastake through the portal.

I don’t know about that. Thanks to @JackALaing we have 30 day averages used to make PUP-13 adjustments:

April 25: 693M
May 31: 860M
Jun 30: 879M
Jul 24: 945M

To me it looks like we’re stalling. An innovative product like Pocket being offered for free should be booming in relay growth. I think we can and should do better, there’s a lot of potential for the project and a lot of capacity on the provider side to fulfill that potential.

My mistake, 5 months, and more than triple, from the looks of it. I don’t see any evidence of “stalling” at all.

2 Likes

I’m still waiting for some clear answers to my questions. I know there were partial answers in the TG chat, but would like more definitive answers, not guesses, and to record answers here. Reason for the questions: I’m not sure what it means to put a parameter change proposal to DAO vote if there is not clarity on what the parameters actually do. I may know what the parameters nominally do, but I’m sensing there may be a disconnect between nominal and actual. A reasonable price range for “in perpetuity” is not the same price range for “until ABR kicks in”. A reasonable price range for upfront payment to own relay service for life is not the same as “pay monthly for x months and after x months you are fully vested”.

A separate question for clarification: is USDRelayTargetRange to be interpreted as follows: price is not to be less than the lower end of range and price is not to be greater than higher end of range? Is it guidance only and Foundation can go lower or higher for a specific contract if the occasion warrants, or is it binding? See text of parameters document below *.

That said, I’m certainly not suggesting that gap between nominal and actual meanings must be closed prior to moving forward. Just that they be understood and disclosed. The proposal seems reasonable as a step in the desired direction. Personally I would prefer to see greater delegation to Foundation to set price; it seems a bit silly to have the DAO in the middle rather than just trusting a delegated authority to do its job. Practically it may be a step in the right direction to go with a wider range for USDRelayTargetRange and potentially give range guidance rather than single value for ReturnOnInvestmentTarget. For example, new value of USDRelayTargetRange might be 0.0000031 to 0.00002 - the extension at the lower end to provide continuity with current value (old high = new low) and the extension at the higher end to provide room for inflation** without the Foundation having to come back to the DAO for a re-vote.

(* From ‘Parameters’ document on pokt.network: “USDRelayTargetRange -
The range of USD/relay prices the DAO doesn’t want the real price of a relay to exceed, accounting for the USD price of POKT.”)

(** Note: by inflation I mean the real kind - USD inflation in which competitors such as Infura may be charging clients more in 6 months or a year than they charge now, not the POKT supply growth that we erroneously label as “inflation”)

2 Likes

Latter.

W/ Portal Monetization, users will have the choice for both upfront or monthly payments. There will be a slight premium for monthly payment users given market risk, and so upfront payment users will essentially will benefit from choosing a straight cost.

Does anyone have a pricing comparison table, so we can all see in 1 view how we compare to centralised and decentralised competition for the differently levels of service?

This will most likely have to be voted upon by the DAO when we introduce ABR.

I interpret the economics in the docs for the Application Burn Rate to be at the protocol level which means that ALL users (both existing owners and new applications) would be subject to it. However, if the DAO feels strongly about preserving the ownership of the existing Application Stakes to not be burned, that discussion could be had by the DAO when the time comes. I could see it going either way. However, my understanding (and the way that the BizDev team has described it) is that ABR will affect all thus matching demand burn and supply mint.

This is a great nuanced point:

The cost of an app stake should not be lower than the low end, higher than the high end. However - to your point - if PNI (or any other portal operator) feels like it wants to set the price higher the range for specific projects, it can. Pocket Network will certainly do so for Enterprise-like deals. We won’t have to go to a DAO vote, or any lengthy process.

Re: real inflation. If prices go up for our competitors (the 2 most expensive in particular), than those increases would flow through to our cost as well. @Lucky55 - you can see prices here as well.

Re: 25% range set out in PUP-7. We could adjust that in another set of changes, but it wouldn’t exactly change our pricing strategy. The 25% was intended to guide how often we make the parameter changes for the app stake cost. However, if you feel strongly about expanding that to more than 25%, that could be even more helpful. That would require a new proposal, but would mean less parameter changing for us.

and I really hear you @msa6867 on your point about valuing delegation to PNI on cost. Our goal is to be nimble in building out Portal Monetization,while working for the DAO in a transparent & economical way.

Most of the team is heads down shipping products. With PUP-23, we aim to update previous proposals, level-set on what we can all expect going forward, and demonstrate how value accrues to the Community and Protocol as a whole.

I’m having troubles understanding how this ties in with gigastakes. Since we already have app staked into the network with high relays, Is the plan that we take their monthly revenue, buy POKT with it, then return it to them to stake? How do they actually own the infrastructure / app stake in the very end, closing the loop?

Thank you @RichCL, I really appreciate your responses. I 'm still pretty confused on what has and is being offered to Dapps. Relays can be owned in perpetuity but ownership might get yanked or slowly burned with a wave of DAO hand… “Lifetime access” prices are quoted and offered at substantial subsidies (industry norms for lifetime price quotes tends to run 36-60x the monthly subscription rate for one-time upfront payment vs 10x current or 24x new), but then upfront payment is not even required to lock in the lifetime subscription… Not that lifetime really meant lifetime anyway… DAO is asked to set a "do not go below " price point, but relays are given for free. … and asked to provide a “do not go above” price point, but biz dev is free to ignore. What all this spells to me is that the two parameters at question in this proposal are more “feel good” efforts to help the DAO get its feet wet in bizdev involvement rather than things that are substantive or normative.

In that spirit I am fine with this proposal as is, and agree with the rationale being offered - meaning that I feel confident that Pocket can progress on a good trajectory of market growth with price points competitive to the top-two competitors and do not share the same concern expressed by @iaa12.

Bigger picture, however, I think the time has come for more involvement between NPI and DAO on the bizdev side. Right now DAO is completely at the mercy of NPI to get it right, because the expertise, the prior-experience, the existing client contacts and contracts, the marketing and sales material etc all exist on the NPI side. To meaningfully govern in this sandbox, the DAO will need access to more information than it currently has at its disposal. It will need access to current contracts, exact wording of promises made to Dapps in marketing and sales material, etc. It is foolish to suggest that DAO can simply vote away something in the future that was contractually promised to a client. Even if it has the authority to do so and the legal wiggle room to do so, the resulting loss of good will might cause irrevocable harm to the project.

I think a good starting point would be a townhall whether that be part of Jack’s current series or a new one where community can real time get some questions answered like the ones myself and @poktblade are asking. Second a repository of docs should be created and shared w DAO with redacted contracts, sales and marketing material, memos etc that can help the DAO get a handle on binding contracts, non-binding promises, unofficial expectations etc that the most important of the Dapps are operating under with regarding to their current stakes and RPC usage. These are suggestions beyond the scope of this proposal and may not need to happen prior to this proposal being put to vote but at the same time should not be delayed .

Where did you pull this chart from? Thanks!

I’m having troubles understanding how this ties in with gigastakes.

The Gigastakes solution is separate from this proposal. Regardless of the vote on PUP-23, we can’t change anything about Gigastakes. Gigastakes in itself is a protocol-level workaround that addresses limitations with V0. Essentially it creates one giant ( giga ) stake that has a massive amount of throughput. The portal then creates off-chain representative stakes for each of our user applications that share that gigastake.

“Is the plan that we take their monthly revenue, buy POKT with it, then return it to them to stake?”

For the most part yes. The plan is as follows:

Users will be able to pay with USD using a standard payment gateway. The monthly USD that comes in will be handed over to a 3rd party market maker who will market buy POKT. That POKT will then be held in a treasury account. After the user completes the 24 month payment cycle they will be awarded their accumulated POKT.

As mentioned in prior comments, we will be offering a monthly payment option in addition to requiring applications to purchase the entire stake upfront. This will be a pay-as-you-go plan, on a per relay basis. At the end of the month, users will be charged on a per-relay basis.

“How do they actually own the infrastructure/app stake in the very end, closing the loop?”

Yes, users will own the app stake either when they pay upfront, or they choose monthly payments (when the payment schedule is complete). We will be tracking this in the Portal in V0, and this will be tracked on-chain in V1.

With Portal Monetization, we will essentially be starting the demand side purchasing app stakes thus closing the loop. This includes staking, editing staking, and unstaking functionality for app stake owners.

1 Like

Thanks for this context. Couple more questions:

Hosting in multiple gateway regions is expensive, along with dev ops, staffing, etc. Will we be using any of the revenue that comes in to subsidize the cost to operate the Portal, or is it strictly to be used for purchasing POKT and other means will be used to subsidize this cost?

From what I understand, one of the justifications for increasing relay price is due to our improved QoS. Do we have more data to prove QoS is up to par to our other providers? Outside of latency, what are the Portal’s SLAs that we are offering to customers? I ask this since this is what some customers may look for before paying for a service. Can the Foundation release the scripts used to benchmark, and was it performed using any other call besides GetBalance rpc call?

How many DApps from a BI perspective actually need access to more than one blockchain. Node runners often have to spend more on i.e Harmony to power that node, whereas something like ETH is much cheaper. Is there any plan to charge per blockchain or region? (I.E for node runners, Asia cost more). Is a flat relay range actually the direction we should be pursuing?

Strictly for buying POKT. This is based on the protocol design and an important step to having all demand side app stakes be denominated in POKT.

As far as hosting in multiple gateway regions, node runners get better odds at earning rewards this way. Coupled with better tokenomics from the demand side purchasing POKT, node runners can make financial decisions about how economical it is to run multiple regions. Given recent cost concerns, it may not make sense for all node runners to run all regions.

Or maybe there is a separate DAO based grant that can relieve node runners who can prove they run x amount of different regions. However, this proposal is taking the cost of app stakes and translating it into demand side purchasing of POKT tokens.

I think you are getting at a really key part of the proposal @poktblade - (and I genuinely appreciate you honing in on this point) - this PUP is to increase the cost of an app stake. This means a more secure network, more sensible tokenomics, and more POKT-buying pressure returned to POKT holders.

It may imply that the price needs to go up as well at the same rate, but, in fact, pricing for the Pocket Portal is still to be determined. We are working towards a state where users pay, own, and freely edit app stakes at the protocol level. Upgrading from PUP-7 to PUP-23 is the first domino that needs to fall before Portal Monetization, and then easier staking at the protocol level. The reality is that right now most users come through the Pocket Portal instead of the SDK.

PUP-23 also sets us up for an ecosystem of multiple different portals with different levels of services (in addition to a self-service through SDK). It wouldn’t surprise me if a group of talented whippersnappers created a portal called “Lightning Shoulders” and engineered the most cost efficient model. Similarly a group of talented business people could create a portal called “P80g6@MM58” that serves only gaming app chains while charging a premium on top of the PUP-23 cost structure. PURE speculation on my behalf, entirely hypothetical. Regardless of these products tho, we want to move towards standardizing the cost of app stakes (at the protocol level).

That being said - to answer your more direct question -

  • our latency has on par with our competitors (as per that speed test you referred to as well as new tests that our Marketing team will be putting out in the coming months and real-time data at https://chainlist.org/)
  • the # of networks we support is more robust, and
  • we’ve proved we can scale past 1bn relays which exhibit a scale of service that few can tout.

There have been rumblings about it. FWIW - I am for this idea.

That being said, it is a material protocol update that would probably warrant a great DAO discussion and proposal. Needless to say, it is out of the scope of this proposal.

A majority of non-Public RPC endpoints require or have a roadmap of multiple chains. Simply put, there is no way we can land Apps like Aave, Synapse Protocol, and Li.Finance if we are not multi-chain. In fact, I think Pocket’s ability to spin up new chains is a super power and competitive advantage.