PUP-23: Stairway to Sustainable Economics

Thanks for the explanation.

I am new to these paramters, so please bare with me and correct me if I’m wrong.

The DAO in summary will pay attention to the POKT price (i.e through exchanges), leverage the actual USD price and use this price along with the new proposed USDRelayTargetRange price to come up with BaseRelaysPerPokt?

1 Like

You got it.

I believe the exact order is

  1. POKT/USDC price changes take USDRelayTarget out of USDRelayTargetRange,
  2. PNI is is prompted to update calculator w/ latest POKT/USDC price,
  3. calculator spits out new BaseThroughput, and
  4. updating this parameter brings USDRelayTarget back into range.

Note: BaseThroughput and BaseRelaysPerPOKT are synonymous in this case given that StakedPOKT has remained constant.

Separately, if top 2 most expensive competitors change fiat prices, we update the
USDRelayTargetRange to reflect a new USDRelayTarget.

1 Like

I understand now, so this is all about pricing on the protocol level. But why are we tying in features that the Portal is offering rather than what the Protocol currently offers to justify our relay prices? I want to provide some counter arguments as there’s some murky advertising areas when it comes to what the Portal is capable of and what the Protocol is currently capable. This is not to indicate I agree or disagree with the actual proposed pricing, but rather to understand the logic behind increasing the costs. Without the current Portal implementation, some of the justifications on charging a premium falls short as there are serious limitations to the current protocol. It’s almost as if we’re tying in the Portal functionality for the pricing justification - but please correct me again if I’m wrong in reading this.

We are not charging additional per region (many of these providers are only in a few regions )

Pocket V0 as a protocol does not allow apps to select nodes from specific regions nor enforce QoS. Only the Portal allows for this

We are not rate limiting per second (many of these providers rate limit per second )

Apple and Oranges. Pocket V0 as a protocol does have a different limit though - per session. Only the Portal allows for circumvention of this by passing relays to another staked app session.

And so if we are tying in features the Portal offers as part of the reason to increased app stake price - why is the Portal cost of business not included into this price? Or rather if we are not tying in the Portal functionality, why are we increasing our prices for the protocol when it still faces some pretty large scalability and consumer adoption issues (QoS related)

1 Like

That makes sense @poktblade. I agree with you that the 2 bullet points you referred to need contextualization and are technically dubious. I’ll edit proposal to remove these points and update thread.

As far as the overall tone -

I think you are largely right. For the short-term - it is really hard to talk about access to the protocol without implicating the portal.

Obviously protocol team, core contributors and community members like yourself are working to change this. As we build out different portals, better SDKs to improve direct access to app stakes, and v1 to innovate our blockchain design, I am betting the protocol and Pocket Portal will decouple.

1 Like

Proposal update: We updated the proposal to remove the following data points:

  • We are not charging additional per region (many of these providers are only in a few regions )
  • We are not rate limiting per second (many of these providers rate limit per second )

As per thread, the amount of regions being offered is not a protocol feature. It is a Pocket Portal feature and doesn’t inherently benefit users who access the protocol directly or through future portals. The cost of an app stake isn’t directly tied to this feature.

Also per thread, rate limiting per second would be logic defined at the portal level. At the protocol level, this is a moot point because of the way Pocket designed session participation. The cost of an app stake doesn’t dictate any rate limiting at all.

1 Like

Hey Rich - thanks for the acknowledging my responses in a friendly tone and overall reciprocation of my comments . I must admit - I’m quite new to this whole monetization plan and pricing as a whole, so apologies for any silly questions lol. I have a couple more questions on how this is going to be sold to customers and what they should be expecting because there are still a bit of implications on what the protocol is offering, i.e QoS.

I agree - once V1 hits the mainnet, these points of increasing the price on the protocol level start to make more sense to me. The future is looking really bright with the next protocol upgrade. I took a step back and re-read the proposal and one of the larger justifications of increasing our price still fall a bit short: We have reached comparable latency of our competitors. This is only possible with the Portal’s Cherry picker, it is not something that is guaranteed with our protocol.

So I guess my last question would be: If we are increasing the app stakes price right now on the protocol level, is that with consideration that users who pay now will have to wait until V1 to actually receive what they paid for? This gets really hazy with the Portal and what we are effectively marketing to customers who pay for app stakes. To me, it makes more sense to increase the price once we get closer to V1 mainnet. Couldn’t portals adjust their pricing to account for this factor instead of setting it at the protocol level right now?

Also just some random scenarios I thought of:

  • App customer pays up front - what if the Pocket Portal has to shut down and they are stuck with V0 protocol features only?
  • V1 gets delayed
1 Like

Say again?? Isn’t “owning the app stake” enough after paying 2 years(upfront 2 year for lifetime access is unheard of for a subscription = 3 to 5 is more typical) and on top of that not even requiring upfront payment but allowing monthly over two years, then we are going to return total POKT (which may have experienced cap gain over the two years) back to the dApp? I am having a hard time understanding the business model.

1 Like

Users will receive their staked POKT at the end of their term regardless of V0 or V1. Yes, it would be a lot cleaner to have it all on-chain and priced accordingly for V1 protocol level service.

Still, Pocket will be be able to keep track of app stakes and be transparent in how many POKT is purchased through Portal Monetization.

To be frank - I think the whole community loses if we don’t collect from the protocol level as soon as possible.

There are several portals and different external products in the works right now (some may be able to ship as soon as V0 with workarounds). Plus Portal Monetization is coming very soon.

Personally, I do not think it is wise to wait any longer to - at a minimum - increase the PUP 7 value for app stakes.

If we ship Portal Monetization (or anyone ships different portal products) with these depressed costs (remember that PUP 7 app stakes costs have actually decreased since we originally passed the proposal), then we don’t really bring much relief to POKT token holders.

I think this point can’t be overstated.

@poktblade - you and @msa6867 are some of the most informed and helpful community members we have. I think your contributions to this thread are not only informative to myself, @eullrich and @gabalab who have been working hard on this, but also a paragon for the type of contribution that any community needs.

7 Likes

This proposal is up for voting snapshot.

1 Like

I appreciate the focus on driving the monetization model for POKT, however there are a few things about this proposal and comments thereafter that I have questions about…

“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”

Why is it a desire to target a USD price point for a relay? Seems to me it undermines the point of the token to abstract away fiat costs and lets the native token capture the value that the network provides and lets the market determine the value through price discovery to find the balance.
Relays should be priced and valued in POKT only.
Targeting a USD price range will inherently limit that value capture and will always require intervention while undermining the demand for POKT in the market.

From @poktblade

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?

These are pertinent questions that I haven’t really seen answered. Is the foundation able to provide metrics demonstrating the QoS or at least tracking it over time. Otherwise how is the portal going to be ‘sold’? Performance metrics are a must have.

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.”

Having a fiat payment processor for the gateway seems to once again completely undermine the whole point of the token. Where is the demand for POKT going to actually come from?
Relying on 3rd party market makers is extremely concerning, because they’ll just manipulate the market to their benefit regardless of the utility of the token or the protocol. This reeks of moral hazards including insider trading.

Not to mention this is a huge red flag for 3 letter agencies to target us. This should be avoided at all costs.

This really is the most confusing aspect of this proposal and plan. I just can’t support not allowing the actual market to evaluate and price the token without interventions. We need real demand, not a charade of demand. I would suggest offering the same kinds of payment plans, but without any fiat option. Force token usage at all times.

I caution against loss of the utility of the token in any measure, combined with “ROI targets” and posts that suggest the token is an investment vehicle in this current regulatory environment is extremely unwise.
Letting the open-market forces to adjust the value according to the level that is mutually beneficial to supporters of the network and the users. This proposal, as stated, seems to interrupt the process of letting the market determine what the value of POKT should be.

TL;DR Monetization of the portal is necessary, but the apparatus here seems to undermine the value of POKT to be derived from network utility and market forces.

I am going to err on no on this proposal and the main idea behind my reasoning is that I feel like we’re offsetting too much of our mistakes to our future customers when we haven’t proven to deliver yet.

As a customer, what does Pocket currently have to deliver to justify a 7x price increase?

  1. The latency is still subpar to centralized providers. Hops are costly, especially hops to random nodes in a session. The P90 latency will suffer with current v0 design as a result.
  2. Customers can’t use the app side of POKT without going through the centralized gateway, and if said centralized gateway shuts down, they get a subpar network performance and v0 has its own problems (fraudalent relays, bad actors ,etc). This centralized gateway exists because our protocol can’t deliver on what customers actually want. So not only are we increasing the prices prematurely, we are increasing it with the promise that we can deliver in the future. Not appetizing for a customer and very misleading.
  3. When you think about it, the proposal suggests we can lower the price in the future. So what we are effectively doing is punishing our early customers by a 7x increase on something that isn’t fully complete yet. Is that really the route to go? These are the early customers paying/investing on the promise that POKT will reach its goals.
  4. To my understanding, a large reason why we are increasing the price is to help alleviate some of the network costs and bring app demand to our network. But I think we are thinking about this in the wrong way, we should be heads down optimizing our network, improving our network (V1), bringing infrastructure costs down to where it makes sense, create a sustainable economic model where node runners can all coexist, etc before we raise our prices. We are shifting a lot of our failures over to the customer, and I don’t think that is a sustainable route to monetization.
  5. I think this is a pretty significant PUP proposal and shocked at how many people have participated in it. Why is this? The proposal has been up for quite some time, so that’s not the reason why. I would like to hear more supporting and dissenting opinions before I can strongly vote towards this PUP.
2 Likes

There has been strong demand for both a predictable budget line item and a SaaS type subscription model. In countless community conversations @JackALaing has participated in, this specific functionality has been requested. Monetizing the portal in this way is specifically meeting those requests.

The entire purpose of a market test is…testing, no? The referral program and other BD/Sales/Marketing efforts will be driving efforts to acquire new dapp stakers through this system.

The use of a market maker is likely a suggestion based around ease of use, but this is trivially addressed by having a PNF director be responsible for making the purchases on an agreed upon interval after dapp stake. For example, once weekly roundups of the stakes that week.

And forgive my skepticism, but bringing up things like insider trading and 3 letter agencies sound like pretty blatant fear mongering given that we’re talking about a utility token designed to be a public good.

What, exactly, is the difference between dapps buying POKT for USDC in the open market, and dapps giving USDC to Pocket Network to buy POKT in the open market? This response doesn’t make sense to me.

Return on their investment in infrastructure, not “return on investment in the token as a security”. There are a number of implied dangers in your reply which seem to intentionally misread the proposal in order to support a perspective of market testing a premium pricing schema in a transactional model which has been repeatedly requested as “a bad thing”. When I sign a 24 month contract with AWS for services, I am also calculating a return on investment. This is not an SEC consideration. “Buy backs” are common across a number of industries, and don’t just apply to stocks, but also to equipment, franchises, etc.

Pocket utilizing this method to streamline dapp onboarding for customers who have requested such is not some nefarious scheme to create a “charade of demand”, it’s literally adding another form of payment, and it seems exceedingly disingenuous to suggest otherwise. If I accept Visa, and then decide to accept Mastercard, that in no way changes the nature of the transaction occurring.

I have voted to approve this proposal.

I do not see that having a fiat payment processor or not has anything to do with this proposal. That is a completely separate and unrelated issue.

I think there may be a significant misunderstanding due to an errant comparison of apples to oranges.

Apples: competitor charges $100 per month in exchange for 15M RPC/day in perpetuity

Oranges current: collect $27 worth of POKT per month for ten months and return POKT to dapp at the end of the 10 months in exchange for lifetime access to 15M RPC/day. True cost for LIFETIME access (opportunity cost of money sitting idle while staked) = $5 + POKT/USD exchange-rate risk (assuming 4% per annum risk-free opportunity cost of USD)

Oranges proposed: collect $100 worth of POKT per month for24 months and return POKT to dapp at the end of the 24 months in exchange for lifetime access to 15M RPC/day. True cost for LIFETIME access (opportunity cost of money sitting idle while staked) = $100 + POKT/USD exchange-rate risk (assuming 4% per annum risk-free opportunity cost of USD)

In other words, turning this into a two-year true apples-to-apples comparison we get the following: True cost for 15M RPC for next two years (assuming 4% opportunity cost for USD):

Competitor: $2400
Pocket Network current: $5 + POKT/USD exchange-rate risk
Pocket Network proposed: $100 + POKT/USD exchange-rate risk

Thus the proposal is merely a step in the right direction to sustainable economics (from >99.7% subsidized to ~95% subsidized)… this is a first rung on the stairway… not the top of the staircase.

5 Likes

Using this numbers example helped me digest a little bit better. Thanks for this, will revisit.

2 Likes

Great question! Could be it’s the summer and people are on holiday. Or forum fatigue. Or, perhaps community members feel ill-equipped to take part due to the complexity of this issue. What better evidence of this than the fact that @msa6867 had to step in to clarify:

1 Like

I cannot speak definitively for other people, but I think most understand that this proposal bears no binding weight but is “guidance” only. Whatever “guidance” is set by this proposal, PNI is free to ignore. Does PNI wants to allocate RPC for free? Its going to do so, despite the min of the range being set to 0.0000068. Does PNI have the opportunity to close a deal with a client willing to pay market rate? Its going to do so despite the max of the range being set to 0.0000113. Why should the majority spend their time digging into the details of a proposal that is not binding? I dig into the details because I understand that even non-binding or symbolic votes are still meaningful in terms of shaping perception and future policy decisions that will become binding. I suggested making the range substantially broader so that PNI is formally empowered to continue its best-efforts approach to bizdev w/o interference from the DAO; my argument being that the handover of this param set to DAO was premature. Rich’s response was to concur that broadening the range makes sense but to submit that as a separate proposal so that this one can track a single concept angle. All that being said, I support the proposal bc it moves the concept ball in the right direction, no matter how small the movement, toward the desired finish line.

2 Likes

Keep in mind this all has to be balanced. The primary driving factor on why we have gigastakes to begin with was that PNF was running out of POKT to stake into apps to drive relays into the network. So in a world of monetization and especially if another portal shows up, the PNF/DAO will have to make a decision whether PNF should have control of gigastake apps or not and under what rules should it be used. Otherwise app stakes would be meaningless, it would not make sense for one Portal to use inflated gigastake apps bypassing all economic guidance, providing a freeminum service whereas another one has to follow the protocol “economic guidance”. Hence, it would be in best interest that the Foundation to respect these protocol parameters with respect to the Gigastakes that we’ve allocated otherwise other portals will be slighted.

So using this example, POKT is still pretty cheap for app user but only assuming they are a long term RPC customer who have a constant rate of usage. YMMV, pricing gets funny when it comes to SAAS and pay as you go models, but overall I get it.

Let’s say that if we were to use these prices and it turns out 7x is nothing more than a drop in the bucket and the customer is getting an amazing deal. I think at the bare minimum, given our reliance on of a Portal, we should be accounting the cost of running any Portal into the cost of relays. Eventually we would need to tie in the network costs too (which will then go into a spiral of how can we optimize)

It is probably a good next step (and probably should’ve have been done before this proposal) for PNF to release Portal statements and break down how much it cost to serve a relay from the gateway. I think based off that, we would have a better estimate of how much should our protocol be priced at. If the portal ends up being extremely expensive to run per relay, then we need to revisit our pricing plan, otherwise it is not sustainable. We need the portal to drive app traffic, and such we need to factor and standardize that into our cost model.

Yesterday, I thought that 7x was on the high end, but now I just realize that I don’t have much information to base anything off of. Something tells me the whole idea of pairing ourselves with centralized providers is a pretty bad model in general, and not sustainable given that all these companies have plenty of VC money and far less optimization problems to solve than us. It’s very possible the most expensive providers are 10x less the price that we are seeing today in 6 months and we are back into square one. If this is nothing more than “guidance” then I think we’re better off creating a stronger model than this.

Rich defined current thinking in a recent TG chat… say a Dapp plays along w “pay as you go” knowing there is a golden carrot at the 2-year mark. They may be all over the map in terms of usage… $60 this month, $100 another month, $10 another month… at the end of the 24 months it all gets returned (the POKt that is, not the USD) and there go-forward “lifetime” access would be the average over the 24 months… that being said, I still haven’t been able to nail down PNI as to whether “lifetime” really means in perpetuity or only means “until ABR turns on”

1 Like

First thing I think is a breakdown of roles and responsibilities. The Portal, I am pretty sure, is run by PNI, (a US corporation between whom and the DAO there is a firewall that must be delicately navigated), not PNF (a cayman Island entity that serves and the umbrella entity structure of the DAO and between who and the DAO should not, in principle, exist a firewall)