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.
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 .
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.
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.
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?
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)
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.
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.
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?
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.
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.
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:
increase the multiple from 10x to 24x the average monthly cost of our competitors.
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.
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?
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.
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.
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.
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.
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.