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 burntransaction on the DAO’s behalf to burn the POKT - Demand-side fees can then be tracked on-chain by monitoring the
gov burntransactions.
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.
