A new parameter will be introduced, the GatewayFeePerRelay, which will specify how much USD-equivalent POKT the gateway operators owe for every relay they send through the network.
This parameter’s initial value will be set to $0.00000085.
Sunset Parameters
The USDRelayTargetRange and ReturnOnInvestmentTarget parameters, which are currently set according to PUP-23 (and PUP-7 before that), will be sunset.
As far as the protocol is concerned, there will be only one parameter to care about - the GatewayFeePerRelay - which determines the protocol’s own revenue. It will be up to the gateways how they price their service to end users.
Note that this proposal will not make any changes to the BaseRelaysPerPOKT parameter. BaseRelaysPerPOKT determines the relay throughput of a given app stake and is therefore independent of the fee that we would be levying on gateway operators for every relay they send through the network. BaseRelaysPerPOKT may be updated separately as part of PNF’s “decentralizing the gateway” initiative, and will definitely be updated in v1, but is out of the scope of this proposal.
Fee Collection & Burning Process
Fees will be collected from the gateway operators and burned according to the following process.
At midnight UTC every Sunday, the POKT amount owed by the gateway operators will be calculated using the following inputs
GatewayFeePerRelay
7-day trailing sum of relays from Monday-Sunday, based on Poktscan data, which sums relays from all blocks based on the UTC time of the blocks
7-day trailing average price of POKT, using the daily close price on Coingecko
The gateways will then be required to transfer the POKT into the DAO treasury account by 12pm EST every Monday
The gov burn transaction will then be executed by PNF on the DAO’s behalf, for exactly the same amount of POKT that was transferred into the DAO treasury account, by midnight UTC every Monday
All burns can be tracked by monitoring gov burn transactions.
Rationale
The Fee Collection & Burning Process outlined above requires no protocol upgrades, which minimizes the effort required to activate burning
Batching the calculation, payment and burn together on a weekly basis, rather than doing daily payments then weekly burns, will minimize the slippage in USD value between payment and burn
The process can be easily automated using scripts, the POKTscan API, and the Copper API
All steps in the process are represented by on-chain actions, which makes it easy for data aggregators to measure protocol revenue
Viability
PNI’s Protocol team has tested the gov burn transaction on testnet and confirmed that everything worked as expected.
Implementation
PNI have already begun making payments into the DAO treasury in anticipation of these measures being approved
If this proposal is approved, burning of all payments will be authorized and every payment made so far will be burned retroactively
You’re thinking what we’re thinking! But I agree with @RawthiL about us needing to ensure that Web3 Index and Token Terminal are tracking the burn, so we can point to where Pocket is on the relevant leaderboards.
Waiting for a couple of weeks of data might make the most of the announcement
While I certainly agree that having good data and somewhere to point people to is very helpful, we would need a 'catalyst ’ for the story to be relevent.
‘Network activated burn several weeks ago’ is a far harder pitch to sell to journalists than ‘Burn was approved today’.
If we can find an appropriate catalyst or ‘hook’ for journalists to use in relation to this - first big burn post voting maybe, then the story can still be effective.
Alternatively:
put a plan together to categorise which outlets are more interested in the headline, and which will care more about data- and then create a strategy around pitching A) and B) appropriately on the day of implementation and then at a second pre-determined catalyst point to maximise reach of the important announcement.
While this obviously falls under the ‘Head of Marketing’ role that is currently being advertised, I’d strongly suggest allocating a temporary person to fill this roll or allocate enough time from an existing member of PNF to focus on this - it’s a big deal and we need to maximise ROI with appropriate budget of time + money.
With the right strategy, this will be one of the most important events in Pocket history.
I appreciate that I didn’t include much in the way of nuance in my last message. So apologies for not giving more detail at the time.
We have our kickoff meeting with a Tier 1 PR firm tomorrow afternoon. Needless to say, a strategy around how best to maximise the impact and awareness about this upgrade to Pocket’s tokenomics, as well as the fact that Pocket will soon be one of the leading revenue-generating protocols, never mind infrastructure protocols, will be top of the agenda.
We will marshall all the resources necessary to make the most of this and every other great event happening in this ecosystem over the coming weeks and months. We also have an offer out for the new Head of Marketing, so additional support is on the way soon too.
Thanks team! Absolutely support this proposal. A few thoughts:
(1) Can you incorporate some guidance into the proposal (even if it is non-binding) as to your intentions with this new parameter as we transition into v1. Eg., "GatewayFeePerRelay will initially survive into v1, as a v1 parameter, but the intention is to ramp down and retire this parameter in the months following mvp as on-chain app burn is turned on and ramped up, "
Or is the intention that this remains a non-zero fee even after on-chain app burn is ramped up to final values?
It should be noted that in the transition period between turning on v1 and retiring this parameter (if that is the intention) that treatment between gateway service and self-stake service will not be the same, as there is no practical way to collect this fee from self-stakers.
(2) The weekly rhythm outlined here makes sense. Outside the scope of this proposal, but as a note to PNI: PNI should not constrain POKT purchases that may be needed to meet this fee to Monday afternoons, lest unintentional periodicity be introduced into the marketplace that can be used by some to game the timing of market sell orders.
(3) Have you considered doing something similar on the demand side to what you are suggesting in your whitepaper be done on the supply side - namely creating a two-sided bounding of the fee as a function of price - , e.g., " Gateway fee of max($0.00000085, 15uPOKT) per relay? I think it is worth looking into, especially if this is the direction your are leaning on the supply side
(4) From a purist perspective (not to mention SEC and regulatory perspective), I think is is best for this DAO parameter to be denominated in uPOKT rather than USD. PUP-7/23 were bad precedence in this regard but are being sunset with this proposal, so we can start fresh and avoid USD-denominated parameters. from now on. Even if it is off-chain, it is a protocol parameter, and as such should carry the native denomination of the chain, especially in all documentation. Practically, nothing changes, as the PIP can still give guidance to PNF to set the value weekly based on price such that the value is equivalent to $0.00000085 of the previous-week average price, etc.
v1 is outside the scope of this proposal. v1 completely rearchitects Pocket from the ground up, including a new economic model with a native on-chain gateway actor, and any calibration of v1 economic parameters should be in the context of a holistic view of v1’s architecture. This is an R&D workstream that the Foundation will be leading on this year as we move towards the v1 launch, working closely with the protocol devs and economists in our community.
Given that there is planned to be an on-chain gateway actor, I would anticipate this off-chain parameter to be replaced by an on-chain parameter that determines the fees imposed on the gateway actor.
This feels needlessly complex given that we can quite easily calculate weekly fee amounts on aggregate using:
the average closing price (the standard method we’re using for DAO payments per this post) and
the total relays from the last 7 days.
If nothing changes, and we’re going to be adjusting the uPOKT denomination of the parameter on a weekly basis in order to anchor it to a fixed value of $0.00000085, why add this extra layer of complexity? Take a step back and ask what it is the DAO is approving. The USD value of $0.00000085 is the fixed value that is being approved - therefore this is the relevant value for the purposes of this proposal.
It is not in the least an added layer of complexity. If anything it is a bit simpler. It is certainly more natural… It is for the sake of how the parameter appears in the documentation, not so much how it appears in this proposal. The only wording change I suggest is as follows:
All I’ve done is removed “USD-equivalent” in the first sentence and added “POKT-equivalent” in the second sentence. This way, the parameter can be added to the documentation as a POKT-denominated parameter, in keeping with every other similar parameter and making it a natural forerunner to the v1 app burn parameters, which will be pokt-denominated, not usd denominated.
Regarding it potentially being a SEC/regulatory concern, this is well outside my realm of experience, so it may be good to get someone knowledgeable in this area to weigh in. Here is my line of reasoning: The SEC recently issued guidance that pure utility tokens will likely be exempted from the SEC’s push to classify most crypto tokens as securities. It is not known what tests will have to be met yet in order to be classified as a utility token, but obviously POKT will be a prime candidate to be considered as such and thus to be exempted from SEC oversight. I figured that keeping everything in our documentation self-consistent to only reference the native token without reference to US Dollars is the safest route to take in the face of uncertain future litmus tests in this regard.
I completely agree that the new on-chain burn parameters eventually supersede this off-chain parameter. The reason I ask about the transition is that I anticipate v1 to set initial values to several new v1 parameters - including the new on-chain burn parameters - to null at v1 turn-on and then stagger the transition to non-null values over a period of time to ensure system stability etc. It would seem beneficial to not have a gap in collecting this fee during this transition period.
I am not going to make this change to our proposal, for a few reasons:
For all practical purposes, even your modified description implicitly sets $0.00000085 as the relevant (fixed) value that the DAO will be voting to set and may later modify in future PUPs (pre-v1)
Being an off-chain parameter, the week-to-week effective uPOKT value of the parameter (as a function of a variable POKT price and the fixed $0.00000085 value) has no practical relevance. We define most other parameters in uPOKT because they are on-chain and thus need to be understood by the chain (practical relevance). In the absence of the need for the chain to understand the parameter, there is no need to introduce this complexity.
It is absolutely an added layer of complexity. No-one communicating about the parameter will reference the variable uPOKT value, they will reference the fixed USD value that the DAO has set, for a few reasons, 1) it is more consistent, 2) it aids comparison to other RPC services (which are typically priced in USD per relay), 3) it aids forecasting of protocol revenue (which is denominated by data aggregators in USD). Using a different denomination in the documentation will obfuscate and confuse this. Not to mention the question of who will go in and manually submit the edits to the docs every week; we’d be creating extra overhead for dubious value.
Even if v1 will supplant this parameter with a uPOKT-denominated parameter, v1 is such a significant upgrade, and thus discontinuity to the concepts we’re used to, that modifying the denomination of a parameter during that switch will be insignificant in comparison. Any questions about the continuity of fee collection and the initial parameter values of v1 can be answered closer to the v1 launch - they are outside the scope of this proposal.
All that said, there’s nothing stopping POKTscan from automatically calculating the uPOKT value of the fee in the dashboard that they will inevitably create to display the ongoing burn. There’s also nothing stopping community members from making a conscious effort to always communicate the uPOKT value, likely relying on POKTscan to keep them apprised of what it is from week to week. However, where this PIP and future PUPs about this parameter are concerned, we should focus on the fixed value that is being agreed to.
This proposal passed with 26 yays and 0 nays. Snapshot
The first burn has been completed with the latest transaction batch, corresponding with 3 weeks of gateway fees paid by PNI. Governance Transaction Notice – May 16th
