The Road to Revenue – Accelerating Progress Towards our North Star

Overview

The Pocket Network Foundation (PNF) is proposing that the DAO begin charging gateway operators $0.00000085 per relay served by the protocol, in advance of activating automatic per-relay burns of app stakes in v1. The POKT collected from gateway operators will then be burned by the DAO using the gov burn transaction.

At current daily relay counts of 1.3B, this would equate to ~$33k per month in gross revenue. At current emission rates of 12%, this would equate to a Deflationary Threshold of 31B daily relays, i.e. capping POKT’s supply once we reach 31B daily relays. Moving forward, the DAO should think holistically about POKT’s economy, investing in R&D to cut gateway operating costs while continuing to aggressively reduce emissions. For example, cutting the emission rate to 4% would bring the Deflationary Threshold down to ~10B daily relays, and thereafter quadrupling the fee to $0.0000034 (assuming gateway operating costs allow for it) would bring the Deflationary Threshold down further to 2.6B daily relays.

The protocol will continue to have negative net revenue for as long as supply-side fees (emissions) exceed demand-side fees, i.e. POKT will be inflationary. However, as described in the forthcoming sections, making protocol revenue our north star does not mean we should turn on net revenue (deflation) overnight. As long as our gross revenue (demand-side fees) is growing, and thus our potential to generate net revenue once we cut the protocol’s COGS (emissions), we are making progress towards our north star.

For this reason, we would propose breaking the “protocol revenue” north star down into short-term, medium-term, and long-term metrics:

  • Short-term: Monthly Gross Revenue
  • Medium-term: Deflationary Threshold
  • Long-term: Monthly Net Revenue

We end this post with an implementation plan wherein PNI begins transferring the Gateway Operator Fee into the DAO treasury starting next Monday (May 1st) and the burn starts mid-May pending an approved PIP.


As shared in PNF’s recent ecosystem strategy thesis, and a DNA update before that, protocol revenue should be the north star that guides all of us working on Pocket Network:

Protocol revenue is the right guiding metric for Pocket because it best represents value creation and capture from across the entire ecosystem. It is a shared metric for which we are all responsible. It’s inherently focused on creating value for customers, and on closing the loop so that value flows back to ecosystem participants and to the POKT token. Revenue is the key building block for a sustainable network economy, which in turn is key to ensuring that Pocket is truly unstoppable… protocol revenue is what we will use as a network to track progress along our future path.

This post aims to unpack what it means to have protocol revenue as a north star - aligning on a definition of protocol revenue and charting a road to revenue that PNF will steward as one of our keystone projects. The DAO’s economic planning has focused mostly on the supply-side to date; we believe that the time has come to take a more holistic two-sided approach, which activates and scales demand-side fees in tandem with reducing supply-side fees (emissions), to accelerate our progress towards generating revenue as a protocol.

Defining Protocol Revenue

The first step in charting our road to revenue is to align on a definition of protocol revenue.

As a starting point, Token Terminal defines protocol revenue as what’s left over from demand-side fees after supply-side fees have been paid. They provide as an example a two-sided marketplace like Airbnb – demand-side fees are what renters pay to stay somewhere, supply-side fees are what the Airbnb hosts get paid, and what’s left over is the revenue that the Airbnb company, who facilitates the marketplace, books as their revenue. Protocols replace platform intermediaries with autonomous code but the same equation applies.

For Pocket Network, this would mean our protocol revenue metric can be defined under Token Terminal’s methodology as

protocol revenue = demand-side fees (POKT burned from apps) – supply-side fees (POKT minted to nodes)

Note that Token Terminal excludes transaction fees (e.g. gas) from the revenue equation, since they are secondary to the core service being performed by the network. In our case, transaction fees are simply paid directly to the block proposer and the DAO via the FeeCollector, not burned, so it makes sense to exclude these from the protocol revenue equation.

A more traditional way of expressing Token Terminal’s equation might be

net protocol revenue = gross protocol revenue (POKT burned from apps) – protocol COGS (POKT minted to nodes)

The POKT minted to nodes can be thought of as a Cost of Goods Sold (COGS) for the protocol, since it is a cost that is incurred by the protocol in the process of performing the RPC relay service (the POKT is minted to nodes in proportion to the number of RPCs they relay).

Another component to consider is the DAO’s share of 10% of all block rewards, which sustains the DAO’s treasury so that it can reinvest in the R&D of the network. The DAO’s share cannot be considered revenue because it is not paid by consumers of the service but it can neither be considered supply-side fees (COGS) because it is not paid to producers of the service. The most logical way to treat the DAO share is as protocol expenditures (unrelated to the goods sold), which are unrealized until a payout is made to contributors. In this way, the DAO share would not factor into the revenue equation, but rather a broader “profit” equation, wherein the protocol’s “profit” could be defined as net protocol revenue less DAO payouts. We will therefore exclude the DAO’s 10% from any revenue modeling.

The State of Pocket’s Protocol Revenue

By the above definition, although Pocket Network, Inc. (PNI) (the sole gateway operator, for now) is currently committed to using 60% of their gateway’s gross revenue to acquire POKT, the protocol itself currently has zero gross protocol revenue, and negative net protocol revenue, because no POKT is burned on the demand-side. In other words, the protocol is currently operating at a loss to sustain its supply-side.

However, it must be emphasized that making protocol revenue our north star does not mean that we should immediately pursue net revenue. We could immediately slash emissions to near-zero, activate a small demand-side burn, and technically have positive net revenue, but we would decimate any growth potential. Two-sided marketplaces like Uber and Airbnb famously operated at a loss for many years to scale their supply-side to a capacity that could support their demand-side’s full potential; if they had prioritized their net revenue above all else, they would never have grown to the scale we see them today.

This bootstrapping dynamic is reflected in the original monetary phases that were envisioned for Pocket Network’s two-sided marketplace: “During the bootstrapping phase of the network, it is important to build a strong foundation for the service, securing as many individual entities running nodes as possible.”

It remains important to sustain our supply-side while we scale the demand-side to make full use of the supply-side’s capacity. However, we believe it is time to start generating gross revenue for the protocol, by activating demand-side fees. Getting to positive net revenue (demand-side fees exceeding supply-side fees) will require a holistic two-sided approach, reflecting our two-sided marketplace, that scales demand-side fees in tandem with lowering supply-side fees (emissions).

Activating Gross Revenue

Fee Mechanism Design Context

Before we dive into calibrating our demand-side fees, we should do a refresher on the design context of the mechanism.

Pocket’s protocol was designed with a burn/mint value transfer model to minimize the coordination cost of the protocol (by minimizing the number of transactions required to facilitate value transfer). The mechanism is as follows: apps stake POKT to buy a set throughput of relays, their stake is burned in proportion to usage, and POKT is minted to nodes in proportion to their proofs of work done. The only transactions that need to be validated are batched staking and proof transactions - the burn and mint are inherent to the protocol. Conversely, a microtransaction fee model, in which POKT is transferred from app to node for every relay, would create multitudes more transactions that need to be validated.

So why hasn’t the app stake burn been activated yet?

  • Initially, because we were bootstrapping the demand-side by providing free relays (it’s easy to forget sitting at 1.3B daily relays but we were once sitting at sub-10M daily relays)
  • Due to technical limitations - unpacked below

We have known for a while now that v0 has scaling and security limitations. This has been one of the main drivers behind the v1 project, which fundamentally re-architects Pocket with scaling and cryptoeconomic security in mind. v0’s discovered limits include:

  • v0 can only handle 250 active app stakes at one time - necessitating app stakes to be abstracted off-chain (“gigastakes” shared between many real apps via an off-chain gateway actor). For context, the budget for active app stakes depends on the nodes per session and session generation times (currently 24 and 1.25 mins respectively).
  • v0 does not have on-chain quality assurance, which necessitates an off-chain gateway actor to run its own computations to filter (cherrypick) the supply-side
  • v0 mints POKT to the supply-side in proportion to the relays they receive from the demand-side, which creates an attack vector for demand-side actors to self-deal
  • Relay proofs ultimately need to be validated in blocks. The more transactions that fill these blocks, the less relays v0 can serve. For context, currently proofs take up 67% of blocks and claims take up 22% of blocks.

Activating direct automated burning of app stakes in v0 would

  • Reduce the number of relays that can be served by v0, by increasing the number of transactions in blocks (a batched burn transaction per app per session)
  • Create the risk that an app stake will be unstaked if allowed to drop to 0 POKT, which opens up the app stake slot to bad actors

We would therefore propose an interim demand-side fee (burn) mechanism for v0, which we can activate prior to the launch of v1 (which will have its own native fee mechanism). This interim mechanism would satisfy the following requirements:

  • Fees should be reflected by a POKT burn in order to
    • Follow industry standards for defining fees
    • Simplify the tracking of fees (verified on-chain)
  • There should be no protocol upgrades required

Proposed Interim Mechanism for v0

In the absence of an automated burn of app stakes, we can replicate the burn by collecting fees from apps off-chain and burning the collected POKT via the DAO’s existing gov burn transaction.

The sole gateway operator (PNI) is already abstracting away POKT in their SaaS pricing. Per-relay prices may vary depending on the subscription tier, but they ultimately collect USD from apps and use 60% of these fees to buy POKT. Notably, while this is revenue for PNI, this doesn’t translate into protocol revenue because the POKT is not being burned.

We will evolve from this status quo by introducing a new off-chain GatewayOperatorFee, charging the gateway operators a fee for every relay they send through the network. Now they will collect fees from their customers, buy POKT as they have been doing, and we’ll introduce the following extra steps:

  • The gateway operator will transfer POKT directly into the DAO treasury, corresponding with the total number of relays they have sent through the network
  • PNF will verify this amount through the on-chain relay data reported by POKTscan, then will use the gov burn transaction on the DAO’s behalf to burn the POKT
  • Demand-side fees can then be tracked on-chain by monitoring the gov burn transactions.

Calibrating the GatewayOperatorFee

Setting the GatewayOperatorFee is not as simple as benchmarking to the competition (e.g. Infura’s pricing) because the gateway operators have their own costs to account for:

  • Cost of Servicing: They perform a key quality assurance function in v0, commonly referred to as “cherrypicking”, wherein they sample the nodes they’re matched with and filter out bad quality nodes/requests.
  • Cost of Acquisition: They need sales and marketing functions to attract customers, which the protocol, in turn, benefits from. Free tier relays can also be considered a necessary component of acquisition costs for the protocol since the relays are work that needs to be paid for but must be free as an expected part of customer onboarding.

We can expect both categories of gateway costs to decrease over time as we launch v1 and Pocket’s ecosystem matures:

  • Cost of Servicing: The launch of v1 will see the quality assurance function move on-chain through the fisherman role. However, even if the entirety of the QA role is moved on-chain, the cost won’t be eliminated entirely; there will be a new fisherman actor to incorporate into our calculation of supply-side fees, although the hypothesis is that on-chain actors will be able to perform the QA function with a lower cost of coordination. Nevertheless, we can also expect gateways to continue playing a role in abstracting Pocket’s UX and real-time filtering of relays.
  • Cost of Acquisition: As Pocket’s ecosystem matures and early gateway operators prove the viability of the business model, it will become easier for new gateways to finance customer acquisition costs (e.g. free tiers), which means the protocol will not need to bear the cost as much.

Accounting for the above, the best approach to calibrate our GatewayOperatorFee is to look at PNI’s unit economics as the sole gateway operator to date. This will set our starting point from which we can scale the fee as we push the gateways to become more efficient over time.

PNI to date has charged an average price of $0.00000195 per relay. Their cost per relay (purely as a function of their gateway infrastructure bills, not accounting for cost of acquisition) is $0.00000417 per relay. They are currently “operating at a loss” in order to acquire strategically valuable customers that will have a compounding effect, with their lowest price for their largest customer going to $0.0000009. For reference, Infura charges $0.00000657 per relay (based on their Growth plan and add-on “Request Packs”).

PNF also believes that we need to onboard additional gateway operators as we ramp up to v1 (more on that to come in a future forum post) and, therefore, that the pricing model should provide new gateway operators with some breathing room to bootstrap (perhaps with the aid of DAO/PNF subsidies).

This leads us to propose a starting GatewayOperatorFee of $0.00000085 per relay.

This is a reasonable starting point that:

  • provides the protocol with monthly gross revenue that is very healthy in comparison to our Web3 peers (~$33k/month which puts us at the top of Web3Index)
  • ensures that gateways have the flexibility to offer bulk discounts of up to $0.0000009 per relay to acquire strategically valuable customers without incurring a loss on that customer
  • makes subsidizing brand-new gateway operators an option that will not break the bank for the DAO (e.g. 500M relays would be 259k POKT per month at a price of $0.05).

This fee would be charged to gateway operators for every relay they send through the network, regardless of whether they themselves are charging for those relays or providing them as part of a free tier; it would be up to the operator how much they want to subsidize free relays to incentivize their own customer acquisition pipeline. We considered having a free tier at the gateway level, but this is not enforceable by the protocol, and, in the interest of establishing a precedent that can easily be inherited by v1, we decided it is more elegant to calibrate the GatewayOperatorFee to a level that gives gateway operators the flexibility to manage their own customer acquisition strategy. If new gateway operators need more help bootstrapping, and the DAO feels they would add value to the ecosystem, the DAO can subsidize them using DAO treasury grants.

Our Pricing vs Infura Price Per Relay ($)
GatewayOperatorFee 0.00000085
PNI’s lowest price 0.0000009
PNI’s average so far 0.00000195
Infura 0.00000657

Note: Infura is the benchmark because they are the original RPC provider and also price in relays. Other notable alternatives like Alchemy price in compute units, which complicates comparisons.

Modeling Gross Revenue & Deflationary Threshold

With a fixed emission rate (independent of relay count) and a variable demand-side fee (proportional to relay count), there are economies of scale where at a certain threshold of paid daily relays, the protocol begins generating net protocol revenue, i.e. POKT becomes deflationary.

It is helpful to model this Deflationary Threshold so that we can understand how different parameters may make the road to positive net revenue easier or harder.

Note: you can see all of the data behind this analysis at this spreadsheet.

Assumptions:

  • Fixed emission rate
  • POKT price $0.05

Scenarios outlined in the table below (in order):

  • Starting Point: this is where we would be starting today - with 12% SER emissions, a Gateway Operator Fee of $0.00000085 per relay, and 1.3B daily relays
  • Grow to 10B daily relays: if we scale to the expected capacity of v0 with upcoming protocol upgrades, we scale monthly gross revenue to ~$258k
  • SER Feb ‘24 (8.7%): once SER’s current schedule has run its course, with a Gateway Operator Fee of $0.00000085, the Deflationary Threshold decreases to 18.9B daily relays
  • Emissions 4%: if we slash the emission rate to 4%, with a Gateway Operator Fee of $0.00000085, the Deflationary Threshold is a more attainable ~10B daily relays, which also happens to be the theoretical limit of v0 (pending some upgrades). If we aggressively grow our daily relays, and slash emissions, we could theoretically become deflationary before v1.
  • Quadruple Operator Fee: assuming we can lower the operating costs of gateways, and correspondingly scale the operator fee, we can slash the Deflationary Threshold. For example, quadrupling the operator fee brings the threshold down to 2.6B daily relays.
Emission Rate Gateway Operator Fee Daily Relays Monthly Gross Revenue (Demand-side Fees) Deflationary Threshold (Daily Relays)
12.00% $ 0.000000850 1.3B $ 33,632.89 30.7B
12.00% $ 0.000000850 10.0B $ 258,714.50 30.7B
8.70% $ 0.000000850 10.0B $ 258,714.50 22.2B
4% $ 0.000000850 10.0B $ 258,714.50 10.2B
4% $ 0.00000340 10.0B $ 1,034,858.00 2.6B

How would our Monthly Gross Revenue modeled above compare to the wider industry?

Project Monthly Gross Revenue ($) Source
Filecoin 5.2M Token Terminal
ENS 1.2M Token Terminal
Helium 162.5K Token Terminal
NEAR 41K Token Terminal
Polkadot 32.1K Token Terminal
The Graph 31.8K Token Terminal
Livepeer 26.6K Token Terminal
Storj 22.75K Web3Index
Algorand 4.8K Token Terminal
Akash 1.73K Web3Index
Gnosis Chain 1.7K Token Terminal
Sia 0.79K Web3Index

At our starting point of $0.000000850 per relay and 1.3B daily relays, we’d be doing ~$33k per month in gross revenue, which puts us at the top of the Web3Index and at #22 on TokenTerminal for a basket of related sectors (L1 Blockchains, Infrastructure, Liquid Staking, MEV Marketplaces), above projects such as Polkadot, The Graph, Livepeer, ICP, Tezos, and Algorand.

If we scale daily relays to 10B, we’d be doing ~$258k per month in gross revenue, which puts us at #14 on the same TokenTerminal basket, above projects such as Cardano, Helium, Cosmos, and NEAR Protocol.

If we then increase the Gateway Operator Fee to a level of $0.00000340 (as an example), we’d be doing ~$1M per month in gross revenue, which puts us at #11 in the same basket, just behind Solana and ENS.

The DAO should invest in reducing gateway operating costs

We expect current gateway operating costs to be the highest they’ll ever be. PNI currently spends $150k per month on gateway infrastructure. If they can innovate and bring that number down, or other gateways can innovate and share their knowledge, in the same way that we’ve seen the supply-side ecosystem build and share cost-saving innovations, this creates more room to scale the Gateway Operator Fee. The DAO should therefore invest in R&D to cut gateway operating costs. Doing so will move the needle significantly on the protocol’s gross revenue and the corresponding Deflationary Threshold.

Emission controls should holistically target a Deflationary Threshold

As illustrated above, activating and scaling demand-side burn in tandem with a fixed emission rate means that there is now a Deflationary Threshold, where a certain level of daily relays will trigger a flippening as burning exceeds minting. So far the DAO’s economic proposals have focused on controlling emissions to prevent them from spiraling out of control. Now that the DAO can control emissions to target a specific Deflationary Threshold, all emission control policies should be evaluated with this in mind.

Community members have recently proposed pivoting to a variable relay-driven emission model (RDI), wherein emissions are set to be proportional to relays, denominated in USD. It should be noted that this breaks the Deflationary Threshold that arises out of economies of scale. Both demand-side and supply-side would be denominated in a USD price per relay, which means no matter the volume of relays, the network won’t become deflationary if the supply-side unit fee exceeds the demand-side unit fee. Rather than a matter of economies of scale, becoming deflationary involves manually increasing the demand-side fee (negotiating with customers to charge more and negotiating with gateways to reduce their take), while manually decreasing the supply-side fee (negotiating with node operators to reduce their take).

SER is also not perfectly compatible with the Deflationary Threshold model because it is vulnerable to fluctuations in the POKT price. Demand-side fees are denominated in USD, out of necessity, so that the price of our RPC service is comparable to the alternatives. In contrast, with SER, the supply-side fees are denominated in POKT because we’re setting a fixed emission rate relative to the POKT supply. This means that increases in the price of POKT would extend the Deflationary Threshold by increasing the USD value of supply-side emissions relative to the USD value of demand-side fees. For example, in a world where we have a 4% emission rate, Gateway Operator Fee of $0.00000085 per relay, and a Deflationary Threshold of 10B daily relays (which assumes a POKT price of $0.05), a price increase to $1 would extend the Deflationary Threshold to 200B daily relays.

Taking the above analysis into account, PNF would recommend pivoting to an emission control policy that has the following principles:

  • Sets emissions to a fixed rate to maintain a fixed supply-side expense so that we can target a predictable Deflationary Threshold through economies of scale,
  • Caps the POKT-denominated annual emission rate to 4-8%, so that we can bring the Deflationary Threshold closer to 10B daily relays (according to the parameters in the model above),
  • Caps the USD-denominated annual emission rate so that price increases don’t lead to overspending on the supply-side (i.e. POKT emissions reduce as price increases), while ensuring we maintain the minimum USD spend needed to cover supply-side operating costs for a given relay volume
  • Derives a cap-and-collar range from the above which the DAO can adjust as needed to increase/decrease our supply-side capacity to meet the needs of our demand-side

Eventually, we may also want to explore de-dollarizing the demand-side, such that gateways can still present USD prices to their customers but gateways’ protocol-level fees are denominated in POKT. However, we believe this will require a more mature ecosystem with less risk to gateway operators who would need to manage the volatility of POKT.

Refining our North Star

The protocol will continue to have negative net revenue for as long as supply-side fees (emissions) exceed demand-side fees, i.e. POKT will be inflationary. However, as we said above, making protocol revenue our north star does not mean that we should turn on net revenue (deflation) overnight. As long as our gross revenue (demand-side fees) is growing, and thus our potential to generate net revenue once we cut the protocol’s COGS (emissions), we are making progress towards our north star.

For this reason, we would propose breaking the “protocol revenue” north star down into a short-term, a medium term, and a long-term metric:

  • Short-term: Monthly Gross Revenue
  • Medium-term: Deflationary Threshold
  • Long-term: Monthly Net Revenue

Implementation Plan

So now that we know what the road to revenue looks like, how are we going to embark on the journey? Below we outline an implementation plan.

Success Metrics

  • Short-term: Monthly Gross Revenue
  • Medium-term: Deflationary Threshold
  • Long-term: Monthly Net Revenue

Stakeholders, Roles & Responsibilities

Stakeholder Roles & Responsibilities
PNF Facilitate this implementation plan; Governance transactions (parameter changes and burns) on the DAO’s behalf
Gateway Operator(s) Sell relays; Reduce operating costs
Economists Build more robust models of all of the ideas outlined above, to help the DAO make informed decisions; Design an updated emission control policy as described above
Voters Evaluate and approve/reject the proposals stemming from this plan; Govern demand-side and supply-side fees
Protocol Incorporate lessons from GatewayOperatorFee era into v1 design

Deliverables, Stakeholders & Timeline

Deliverable Stakeholders Timeline
Finalize a fee collection and burning process PNF, PNI This Week
Audit legacy parameters/proposals that may need to be formally overwritten (e.g. PUP-9, PUP-23, PUP-7, USDRelayTargetRange, ReturnOnInvestmentTarget) PNF This Week
PNI to start transferring POKT into the DAO treasury, in advance of approved PIP to activate burn PNI May 1st
Publish PIP to introduce and activate GatewayOperatorFee and burn PNF, PNI May 1st
Pending PIP approval, test burn transaction then begin burns PNF Mid-May
Build models of the ideas in this post to help with analysis Economists Q2
Design an updated emission control policy as described above Economists Q2
Confirm our interpretation of protocol revenue definition with data aggregators (Messari, Token Terminal, Web3Index) PNF, Economists Q2
Update POKTscan to track gov burn transactions, create a dashboard similar to https://ultrasound.money, and create API endpoints for tracking cumulative burn POKTscan Q2
Liaise with data aggregators to incorporate new burn data into their dashboards (Messari, Token Terminal, Web3Index) PNF Q2
Incorporate The Road to Revenue into PNF’s PR strategy PNF Q2
Continued reporting to the DAO on gateway cost reduction efforts Gateway Operator(s) Q3 onwards
Continued refinement of demand-side and supply-side fee parameters Economists, Voters Q3 onwards
Incorporate lessons from GatewayOperatorFee into v1 Protocol Q3 onwards

Thanks to @ArtSabintsev, @RawthiL, @msa6867, @Cryptocorn, @poktblade, @Jinx and @jdaugherty for their constructive comments.

12 Likes

Having spent time with all of the principals involved here, I know we can get this implemented quickly.

And the network add-on effects cannot be overstated here. Instantly hitting the top of the web3 index, being listed with solid numbers in token terminal, and showing real data on the Messari dashboard FINALLY put us in a place where we get broader visibility with appealing numbers in trusted platforms.

LFG.

9 Likes

Hi all!

@JackALaing and I have been discussing this in the background for a few months now and I am excited that we’ve finally reached a point where we have plan in place to turn on burning!

On behalf of PNI, I am confirming here that we will be paying the gateway fee of $0.00000085/relay starting May 1, 2023, and will continue to do so on a weekly basis.

We will be sending tokens to the DAO treasury from this wallet; https://www.poktscan.com/account/ff9ada66cda37f8d09556d36f22d7051639f221d

12 Likes

It is very good to hear that PNI is on board with turning on this fee!

That being said, I would like to see something formalized, not just unilateral action as a result of a white paper. Not sure the right existing mechanism. I think a PIP creating a new off-chain parameters would be best, eg somehting like GatewayFeePerRelay (and retire PUP7/23 as noted in this white paper). Of course PNI is free to pay the fee before it is formalized just that we shouldn’t skip “making it official”

I’m excited to see this turn on. Perhaps it is a bit lower than I was hoping we could start with, but it is in the right ball park . Being able to show real revenue in the marketplace will be a big plus.

I note that this continues down the path of dollarizing the demand side. At the client-facing direction of the gateway, this can’t be helped; indeed part of the value-add of a gateway is to abstract away blockchains and tokens to make life as simple as possible for clients. At the protocol level, however, it is my hope that in time we can peg relays to $POKT rather than to USD, fulfilling the very raison d’etre for having a POKT token. I understand the time for that may not yet, but at a minimum it is helpful for us in the community to at least "know the numbers " as readily in units of POKT is in units of USD… sort of like a technical person in the US or UK having to be handy in both English and metric units.

Toward that end:
This proposal calls for a fee of approximately 20 to 25 uPOKT to be collected and burned per relay ( given recent price action).

By comparison, emissions are at about 500 uPOKT/relay, falling to a projected value of between 100 and 350 uPOKT by the end of SER (Variability depending on daily relays. Note that increasing the demand is by far the single biggest contributor to reducing per-relay emissions under the SER construct (350 uPOKT /relay assuming 1.2B relays per day vs 100 uPOKT/relay assuming 4.2B relays per day. (In time, the SER construct itself should be retired in favor of returning emissions to a fixed number of uPOKT per relay. Turning on this fee collection and burn is a major first step toward making that possible.)

Definitely it beyond time to retire PUP-7 and 23 ( USDRelayTargetRange and ReturnOnInvestmentTarget).

Not sure about BaseRelaysPerPOKT (see PUP-9) - at first blush it seems this parameter doesn’t get changed or affected by the current proposal. PUP-9 itself was a one-time temporary action that is past-tense, so I don’t see PUP-9 needing to be rescinded. In v1 the whole Gigastake goes away, but I think we are sort of stuck with it for now.

4 Likes

have not been in the chat or forum for a few weeks. This proposal appears in a fast and decisive way. And it is definitely a valid economic strategy for market value management.
There are many Pokt coins sinking in the account, and people need to stir and let the unused (unstaked) token circulate a little bit. Now I am looking forward to seeing the bridge and Dex.

3 Likes

I have little to say, this is great news and a step in right direction.

I want to add to this comment:

While it might be too soon to think in $POKTs, we need to keep the $POKT economy in track and avoid simplistic views where the token is only a weird way to measure things (like Reaumur degrees or inches/miles ). The DAO should have in mind that we have a token, and that part of the goals of a successful and powerful Pocket economy should be able to drive the relay market with a $POKT central economy.

5 Likes

100% agree. Burning wouldn’t move forward until the DAO approves a PIP to adopt a GatewayOperatorFee and authorize a burn. This is outlined in the implementation plan.

PNI is committing to paying the fee in advance of it being formalized, then their fees paid up to the time of approval can be retroactively burned.

It’s a healthy baseline. We can keep an eye on the operating costs and average sale prices of the gateway operators and increase the GatewayOperatorFee over time.

1 Like

This is a very clear and compelling announcement.

@JackALaing One set of questions re: determining the Operator Fee, Deflationary Threshold model , and the following quote:

How does the fee work in instances when the DAO’s share of block rewards is changed?

i.e. - if we vote to decrease the DAO Share (and increase share of POKT minted to nodes), would the net protocol revenue decrease according to the Token Terminal equation you quoted? Assuming demand stays the same, but now supply-in-circulation increases. (note: this is an unrelated concern from the thread in Poktopus Den that discussed burning 5% of the DAO share)

Conversely, if the DAO voted to increase the DAO share and reduce POKT emitted to node runners, would the net protocol revenue increase? Assuming demand stays the same, but now supply can effectively be taken out of circulation.

Context is that I am trying to understand any second order effects of the DAO share % using this model.

3 Likes

Your interpretation is correct.

Lowering/increasing DAO share doesn’t affect overall minting, it just affects the servicer’s share of minting (and thus the volume of supply-side fees), since

Servicer Share = 100% – DAO Share – Validator Share

The DAO share is an unrealized expenditure that’s excluded from the revenue equation. The servicer share is a supply-side fee (COGS) that’s included in the net revenue equation (gross revenue minus supply-side fees). Therefore, increasing/lowering the DAO share, which lowers/increases the Servicer Share, actually lowers/increases supply-side fees and thus increases/lowers net revenue.

3 Likes

Last night, we remitted 193,923.35 POKT to the DAO. Full breakdown of the how we came to this number can be found in this twitter thread: https://twitter.com/ArtSabintsev/status/1652865913170051073

11 Likes

Web3Index have now updated their POKT listing to track our gateway fees. With the last month of fees we’re sitting pretty at #2. This is an important milestone in our Road to Revenue!

8 Likes

I’m happy to share that Token Terminal have now completed their integration!

Our listing can be found here Pocket Network (POKT) - Key metrics | Dashboard | Token Terminal

and the first monthly data update can be found here Pocket Network fundamentals - Projects - Token Terminal

Thanks to @Jorge_POKTscan for supporting Token Terminal with the integration :heart:

6 Likes