Attributes
-
Author(s): @o_rourke @richCL @adam @JackALaing
-
Parameters: 1 - USDRelayTargetRange , 2 - ReturnOnInvestmentTarget
-
Current Values: 1 - Undefined , 2 - Undefined
-
New Values: 1 - $0.00036 to $0.00059 , 2 - 10 months
Summary
Now that Pocket’s user base is growing, with new application users who will not be using the free tier, the DAO needs to set its price targets for requests. To ensure that the service is priced competitively and therefore maximize app user growth, we should ensure that the average price of a relay is $0.00048 and that this price is achieved by an app after 10 months of staking. Per the DAO Constitution, the Pocket Network Foundation will be responsible for maintaining these price targets by adjusting the following on-chain parameters: BaseRelaysPerPOKT & StabilityAdjustment.
As the famed philosopher Robert Plant once sang: Blockchain infrastructure projects succeed when App Developers can afford a “whole lotta requests’’.
Background Info
Why the DAO delegates price adjustments
For a commodity service like Pocket, it is important for the price of admission to be relatively stable and comparable to the competition. This is difficult when the price of the service is denominated in POKT, which may fluctuate in value, and we can’t use on-chain oracles. For these reasons, the DAO has measures to manually adjust the relevant pricing parameters in response to fluctuations so as to rebase the cost of an App Stake.
There are two “off-chain” parameters that the DAO can signal their preferences over, which will set a price target for relays in USD terms:
-
USDRelayTargetRange: the range of USD/relay prices the DAO doesn’t want the real price to exceed, accounting for the USD price of POKT
-
ReturnOnInvestmentTarget: how long it should take for the USD/relay price to be achieved, since the cost basis of a relay decreases over the lifetime of an app stake
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 fulfil the USD targets.
6.6. The following parameters will be governed by the Foundation in order to fulfill the target values for USDRelayTargetRange and ReturnOnInvestmentTarget set by the Council: BaseRelaysPerPOKT & StabilityAdjustment. The Foundation will anchor around the Council’s target according to a 14-day average; if the actual relay price exceeds this target range temporarily, the Foundation can ignore it, but if the range is exceeded on average for 14 days, the Foundation must respond.
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.
This should also serve as a strong signal to prospective users of the network that the price of a relay will be stable and competitive.
Why the DAO hasn’t set price targets yet
Until now, the cost of an app stake was being subsidized by the Foundation, using the Foundation treasury to enable a free service that would further incentivize early adopters.
As we move past the limits of these subsidization measures and the inbound stream of application users grows beyond the free tier, we need the DAO to set the price targets that the Foundation can adjust on-chain parameters around in light of the recent increases in the POKT price.
Motivation
The main motivating factor determining our price target choices should be ensuring that Pocket Network’s service is priced attractively compared to the competition, recognizing that it is a commodity service and therefore price is a major factor in purchasing decisions.
Another motivating factor is to make sure that there is a path to sustainable app growth for the benefit of the Node Runners. If we maintain the current parameters without setting a more sustainable USD price target, app growth would be prohibitively expensive and could have an adverse impact on our current Node Runners whose economics rely on the rewards that apps generate.
Rationale
USDRelayTargetRange = $0.00036 to $0.00059
We should ensure that the average cost of a relay is less than that of our competitors. The table below shows the approximate values for their mid-tier service for a full suite product (full node and archival nodes access):
| Details | Infura | Alchemy* | QuickNode |
|---|---|---|---|
| ~ Price/million requests/month | $475.00 | $760.42 | $530.77 |
| Price per relay (USD) | $0.00048 | $0.00076 | $0.00053 |
*Alchemy requests have been normalized from Computational Units to Requests
There are a few factors to consider in this decision:
-
Centralized services have historically been more convenient, though we are bridging the gap with our brand new Dashboard and other tools.
-
Pocket provides a decentralized service that has inherently more resilience, censorship-resistance and privacy. This should carry a premium.
-
Due to the disconnected nature of the economics, Pocket Network has the ability to bootstrap with little to no negative outcomes for the other side of the marketplace.
-
Users of infrastructure will generally be reluctant to be guinea pigs, which requires a discount.
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 in feature set 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).
| Details | Description | Value |
|---|---|---|
| USDRelayTarget | Price per relay for cheapest competitor | $0.00048 |
| Target Range Buffer | % above and below the target, that the range is set at. The higher the value, the more the variability, but less operational overhead. The converse has the opposite effect. | 25% |
| Lower value of USDRelayTargetRange | USDRelayTarget * (1- Targe Range Buffer) | $0.00036 |
| Upper value of USDRelayTargetRange | USDRelayTarget * (1+ Targe Range Buffer) | $0.00059 |
ReturnOnInvestmentTarget = 10 months
Calculating the ReturnOnInvestmentTarget parameter requires context on the pricing structure to deploy an App. For the alternative services, they charge App Developers on a per-month basis whereas Pocket Network has you purchase enough POKT for one stake that you can use in perpetuity. In this way, comparing our price structure is not an “apples-to-apples’’ comparison.
To account for these differences, we are basing our cost of a relay to a multiple of our competitors monthly rate. 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. Therefore, we should set the on-chain parameters such that the average relay price reaches $0.00048 after 10 months of staking.
One important thing to note that has not been factored into our pricing at this time is the recoverability of POKT costs for apps (selling POKT when the app wants to exit the network). Being unfamiliar with our business model, apps have been hesitant to factor this in at this time which is why it has been excluded in our pricing for now. In the future, as apps begin to factor this into pricing, this should be included.
Dissenting Opinions
We should leave the parameters at current levels
There is a material risk to leaving either parameter as is. Mainly it makes App stakes prohibitively expensive and prevents incremental relay growth to Nodes (prohibitively expensive being approximately 37-64x the monthly price of our cheapest competitors thus equating to a 3-5 year stake to effectively break even to opportunity costs based on the OTC spread as of May 2021). It is important to keep in mind that Apps currently running Pocket are subsidized with App Stakes that the PNF Treasury funds, and any funds being held back limit further investments into the Pocket Network environment.
Furthermore, having the USDRelayTargetRange undefined can distort the price discovery process that the upcoming Liquidity Bootstrapping Pool (LBP), wPOKT regen farming, and eventual process for exchange listing are building towards. Adjusting the MaxRelay formula will be a first step for many more Pocket Network developments. Left undefined, the parameters could limit growth and compromise any price discovery efforts underway for POKT.
Won’t this impact my current Node economics?
The only impact that this will feasibly have on nodes is positive, i.e. to help increase the number of relays going through the network, resulting in better utilization for each node. Until now, the service has been prohibitively expensive to apps as outlined in the previous answer, and the only reason this didn’t matter is the Foundation was subsidizing apps to bootstrap the network. Now more apps are asking about staking themselves directly, so we need to adjust pricing to be more in line with the competition and reduce barriers to entry.
We should activate ParticipationRate instead
At the core of this proposal, the DAO setting price targets unlocks PNF’s ability to adjust the BaseRelaysPerPOKT & StabilityAdjustment parameters. These are the main levers that the PNF can pull when we want to set the cost for an App to be deployed on the Pocket Network. While the Participation Rate (see appendix) can also be used, the DAO and PNF are not able to directly control it.
Additionally, the timing for activating the Participation Rate would introduce a lot of uncertainty in pricing. The Participation Rate (proportion of supply that is staking) may see a lot of flux as LBP, wPOKT and the POKT<>wPOKT bridge get implemented.
The USDRelayTargetRange and ReturnOnInvestmentTarget parameters are the most direct mechanism for which the DAO can set the price in familiar USD terms.
Implementation
Setting BaseRelaysPerPOKT
Until POKT is listed on exchanges, the Foundation will use the 14 day average cleared price for sales across the community OTC desks. If the Foundation Directors determine that the public cleared price data is not representative of the market due to the lack of public pricing data, it may choose to use the midpoint price between the best bid and ask offer across OTC desks.
Using this price, and the 10 month target for the relay price to equal $0.00048, we will then work backwards to a BaseRelaysPerPOKT value.
We have created a Calculator that holds both stability adjustment and participation rate constant, and computes the appropriate BaseRelaysPerPOKT based on 2 inputs - 1) the target cost/million relays and 2) the current cost of POKT token. The reason we use a target cost/million relays is to normalize across competitor cost structure and have a uniform comparison. This calculated value for BaseRelaysPerPOKT is the PNF controlled value that keeps the USDRelayTargetRange within the voted upon range.
Adjusting to Fluctuations
The Foundation will also calculate for which USD prices of POKT, on the low and high end, the USDRelayTargetRange would be exceeded.
The Foundation will then anchor around the target according to a 14-day average; if the actual relay price exceeds this target range temporarily, the Foundation can ignore it, but if the range is exceeded on average for 14 days, the Foundation must respond.
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.
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 Foundation to regularly adjust the parameter based on what the DAO votes on as an acceptable cost structure to Apps.
Stability Adjustment
The Stability Adjustment is an additional parameter that offers an alternative method of “smoothing” the costs of using Pocket Network, correcting Max Relays up or down in response to sudden spikes in the price of POKT.
For more details on the Stability Adjustment, see the documentation rebrandhere.
Participation Rate
The Participation Rate measures the proportion of the POKT supply that is currently staked. We have left the option to multiply the BaseThroughput by this value because in theory the proportion of supply staked should be a proxy for demand and/or the USD price of POKT.
The Participation Rate is currently dormant because we want to see how things shake out first before activating it.
For more details on the Participation Rate, see the documentation here.