Mint Incentivizing Network Transformation (MINT)


  • 2023-06-20 :
    • Fixed some grammar, thanks @Cryptocorn !
    • Clarified on/off chain parameters.
    • Added rationale on why this is presented in v0 and why it works on v1.
    • Added “Explain Like I’m 5” section (as named by @PoktNews )
  • 2023-06-22:
    • Added new resource, the MINT Playground.
    • Corrected more grammar (thanks @zaatar !).
  • 2023-08-14
    • Updated proposal text, simplified version is the default view.
    • Updated the parameters, now they are final.
    • Added mechanism to cap emissions to 5% of supply.
    • Updated the resources to reflect changes in parameters.
    • @zaatar and @Cryptocorn reviewed and suggsted edits.



We propose to change the POKT minting strategy to achieve:

  • Lower than 5% anual supply growth (inflation)
  • Boost the impact of revenue derived from relay growth depicted on Token Terminal and Web3Index dashboards.
  • Provide certainty on long-term pricing and costs of the network (both for node runners and those staking Pocket Apps)
  • Attract more gateway builders by showcasing a very low relay price


Currently, neither the future cost of running a gateway nor the income from running a servicer or validator node can be forecast (in fiat or POKT). While a rise in the number of relays is expected to produce an increase in both the fees charged to gateway operators and the incomes of network actors, there is uncertainty on how this will play out.

This proposal calls for setting a fee for gateways/Pocket Apps and a payment rate for network actors (currently servicers, validators and the Pocket DAO) that are as high as possible given current and foreseeable circumstances. Doing so will make it possible to project both the costs of running a gateway or Pocket App and the income of each actor (for V0 or V1). What’s more, defining these values will make it possible also to highlight the cost-effectiveness of the Pocket Network.

(In v0, gateways operate the Pocket Apps that provide dApps access to the Pocket Network; the DAO owns the keys to the Apps. A dApp, is an application, such as a wallet, that requires access to blockchain data. In v1, dApps will be able to self-stake and operate their own Pocket Apps.)


We propose to set:

  • Relay fee for gateways at 0.0000017 USD/relay, enforced after we reach 20 B relays/day. (This is double the current fee.)
  • Relay cost (paid to network actors) at 0.0000015 USD/relay, enforced after we reach 10 B relays/day. (This cost is about 3 times lower than today.)

MINT is intended to govern until Pocket Network reaches maturity (the point where relay volume is sufficient for gateways and Pocket nodes to self-sustain, eliminating need for DAO incentives). While one cannot say with certainty at what point maturity will be achieved, we believe that this will occur once there’s a small number of gateways and relays climb to 25 - 50 B /day. Post maturity, PNF could negotiate a higher charge to gateway operators, and the DAO could set a greater reward rate for network participants.

Implementation of this proposal should not affect the deployment of new gateways as the changes it involves are subtle. At the same time, however, the use of defined values will have a big impact on the numbers displayed by 3rd party dashboards: at 10 B relays/day, the network will report more than a 40% increase in revenue at Token Terminal and of fees at Web3Index. In addition, a supply decrease (not reflected on dashboards) will occur starting at 16 B relays/day.

Before 10 B relays/day, the difference between MINT and ARR, in terms of 3rd party metrics, will be small but growing rapidly. After 5 B relays/day it will become noticeable and at ~7 B relays/day this difference will help us surpass Tornado Cash in fees. At ~12 B relays/day the difference is so large that Pocket will overtake Instadapp in collected fees, something that would take 20 B relays/day if we were to keep ARR.

MINT renders unnecessary other supply control mechanisms; its adoption would mean removing ARR.

Under MINT, token issuance will never generate more than 5% of annual supply growth. Before adjusting minting to achieve the target price/cost per relay in USD, we ensure that any change to the RTTM does not result in annual supply growth exceeding 5%. For further detail see the RelaysToTokensMultiplier section under “Computation of parameters’”(in the deep-dive section below). See also the code provided by the spreadsheet

Dissenting Opinions

We have to wait for V1 research.

No need to do that. This proposal does not impact network tokenomics. It merely sets a competitive relay price for network actors and gateways/Pocket Apps.

This will add friction to the onboarding of new Gateway operators

The change will not affect current gateways (Pocket Portal and, soon, NodiesDLB) and will have little impact on new gateways as the changes it entails are subtle. At the same time, it will help attract new portal creators by providing certainty about the price of relays in the future.

The “sunken cost” of increasing gateways fees is too high.

Given that Pocket App stake levels may increase with v1, gateway operators should begin setting aside POKT to prepare for this possibility. If stake levels do rise, the DAO should not have to subsidize the operators’ associated cost increase.

Nothing should be done to increase supply-side gains. It’s best to just stick with ARR.

Node runners are the largest POKT holders. They will benefit from the growth of relays - and the consequent increased revenue and related narratives around the network’s success. This is key to sustaining node runners and the future of the network.

While we expect the success of the ecosystem to lead to token price appreciation, it is impossible to know the magnitude of the appreciation. Also it is important to note that many node runners (and other token holders) may have bought the token at a higher price and are currently in the red. Appreciation to a certain level would lead only to breaking even. The break-even level could be estimated by means of the average buy price of the tokens that are staked.

In any case, we argue that tying an important side of the network (supply) to a variable that we cannot control (token price) is bad for the system. This proposal seeks to avoid this negative effect.

For an optional deep dive into MINT and greater detail, click here.
  • All Parameters:

    • On Chain:
      • RelaysToTokensMultiplier
    • Off Chain / DAO Directives:
      • GatewayFeePerRelay
      • MaxBootstrapServicerCostPerRelay
      • ServicersBootstrapUnwindStart
      • ServicersBootstrapEnd
      • MinBootstrapGatewayFeePerRelay
      • GatewaysBootstrapUnwindStart
      • GatewaysBootstrapEnd
      • MaturityRelayCost
      • MaturityRelayCharge
  • New Values:

    • RelaysToTokensMultiplier, GatewayFeePerRelay: following a piece-wise linear function to match the bootstrapping limits of the ecosystem (New parameters).
    • MaturityRelayCharge : USD 0.0000017
    • MaturityRelayCost : USD 0.0000015
    • MinBootstrapGatewayFeePerRelay : USD 0.00000085
    • MaxBootstrapServicerCostPerRelay : USD 0.000005
    • ServicersBootstrapUnwindStart : 1.5 B Relays/day
    • ServicersBootstrapEnd : 10 B Relays/day
    • GatewaysBootstrapUnwindStart : 2.5 B Relays/day
    • GatewaysBootstrapEnd : 20 B Relays/day


The RelaysToTokensMultiplier and GatewayFeePerRelay can be calculated using the following:MINT - RTTM and GFPR Calculator
The full analysis can be run here:
MINT- Analysis Notebook
The optional historical data can be downloaded from:
Historical data on RTTM and relay volume
A playground to test different parameter sets
The MINT - Playground


We propose to control the minting of the Pocket Network by means of two variables:

  • [Variable] RelaysToTokensMultiplier (RTTM)
  • [Variable] GatewayFeePerRelay (GFPR)

These variables are controlled by a set of parameters, defined below. Some of these are denominated in USD (out of necessity, to compete with the global market).

  • [Parameter] MaturityRelayCharge : The target price of a relay in the Pocket ecosystem at maturity. This value was set to 2x the current value.
  • [Parameter] MaturityRelayCost : The cost of a relay in the Pocket Network, how much the protocol will pay its actors (servicers, validators and DAO). Chosen to be a fraction of MaturityRelayCharge, to reduce the monetary base in the future (this is protocol revenue).
  • [Parameter] MinBootstrapGatewayFeePerRelay : The minimum price that gateways have to pay the DAO for processing their relays. This is the lowest rate acceptable by the DAO.
  • [Parameter] MaxBootstrapServicerCostPerRelay : The highest rate that the DAO will pay node runners in order to bootstrap the supply side. Selected to be 3.33333 x MaturityRelayCost. That should be observed while the Pocket Network is in the bootstrap phase or in “soft landing” periods. These periods are measured in Relays / Day, which align with the goal of every participant to grow the number of relays.
  • [Parameter] ServicersBootstrapUnwindStart : Below this value, the RelaysToTokensMultiplier is fixed to meet the MaxBootstrapServicerCostPerRelay cost per relay given the current exchange rate.
  • [Parameter] ServicersBootstrapEnd : Above ServicersBootstrapUnwindStar and below this value, the RTTM is calculated using the linear function described below. Above this value the relay price is set by MaturityRelayCost.
  • [Parameter] GatewaysBootstrapUnwindStart : Below this value, the GatewayFeePerRelay is fixed to meet the MinBootstrapGatewayFeePerRelay cost per relay given the current exchange rate.
  • [Parameter] GatewaysBootstrapEnd : Above GatewaysBootstrapUnwindStart and below this value, the GatewayFeePerRelay is calculated using the linear function described below. Above this value the relay price is set by MaturityRelayCharge.

Additional Motivation

Aside from the previously noted motivation, there is another issue with the Pocket Network that needs to be resolved, namely, the misalignment of the different actors and gateways/Pocket App with respect to the growth of the network.

Currently the minting and burning of relays is controlled in a way that misaligns the goals of node runners and those of gateway operators. Gateway operators are encouraged to process more relays in order to increase their income given the difference between the relay price paid to the DAO and the relay price on the open market. By contrast, node runners are encouraged only to increase their market share of relay volume relative to that of other node runners. They have no direct monetary interest in seeing the number of relays processed by the network go up (the success of the protocol) as they will earn the same amount of POKT.

Finally, if, as suspected, the demand that underpins the current value of the GatewayFeePerRelay is based partly on free relays, then the current system is unfair. Hence, as the ratio of free relays to paid relays diminishes, the gains of the gateway operators increase. Since the fees paid by the gateway operator to the DAO are based on a given number of relays, if the free portion of relays drops, the portal owner’s earnings go up. In this scenario, where only the minting is adjustment variable for minting, the supply side of the network (servicers, validators and DAO) end up absorbing the cost of the gateways bootstrapping by receiving lower rewards in an effort to reach net zero supply growth (minting minus burning).

We propose to shift the focus to the growth of the ecosystem, with all participants encouraged to increase the number of processed relays. Under MINT, node runners and gateway operators will both reap rewards from a rise in relays, while all token holders will benefit from a drop in total emissions.

This proposal is also able to:

  • Keep emissions fixed in terms of a foreign currency (USD)
  • Limit token supply growth in cases where the POKT exchange rate or the number of relays varies
  • Align the interest of all network participants, gateway operators and node runners alike, with network growth
  • Make it possible to identify which participant in the network is being subsidized by the DAO in the case of RTTM and by the DAO and PNF in the case of GFPR


Parameter Selection

Here we elaborate on the reasons behind each parameter selection. Some of them are chosen to provide continuity to current practices, others chosen due to external constraints, and some to keep the shape of the produced curves as smooth as possible.


his value is what we expect to charge for a relay in the ecosystem. To give Pocket Network an economical edge over its competitors, this value must be lower than the current market value of a relay.
This value greatly affects the Gateway operators (and app devs in V1), and for this reason the value was obtained as a result of talks with the current Gateway operators (Portal and, imminently,NodiesDLB). The proposed value was the highest possible one given current constraints; it is twice the current value.

MaturityRelayCharge = 0.75 x USD 0.0000085 = USD 0.0000017


Greater discretion can be applied in controlling the supply side of the Pocket Network. What the Network pays to its actors (Servicers, Validators and DAO) must respond to macroeconomic factors, such as the control of the monetary base and exchange rates. Given the high inflation that the Pocket Network observed in late 2021/early 2022, we set this value lower than the MaturityRelayCharge to create an effective reduction of the monetary base before the bootstrapping phases end:

MaturityRelayCost = 0.88 x USD 0.0000017 = USD 0.0000015


This is the minimum price that the DAO will charge a Gateway to process its relays. This value was actually zero before PIP-29. However, we think that burning is here to stay, so the value should be kept above zero. Since the current value is our only reference, we choose it as the lowest possible value:

MinBootstrapGatewayFeePerRelay = USD 0.00000085


This incentive is a new value that we created based on the maturity fee. It should be larger than the maturity fee since it is the maximum amount that the DAO is willing to pay to node runners to encourage them to join an emerging ecosystem. We set this at approximately 3x the MaturityRelayCost:

MaxBootstrapServicerCostPerRelay = 3.3333 x USD 0.0000015 = USD 0.000005


The bootstrapping of supply-side actors starts at zero relays with a cost of MaxBootstrapServicerCostPerRelay per relay to the network. This incentive will be paid until the service side of the network is mature. This value signals the beginning of that maturity; it is the amount of relays that the DAO considers to be enough to start the reduction of the servicers’ incentives. We chose this value to be around the current traffic volume, as the conditions for servicers are already too harsh, as evidenced by the recent departure of node runners from the network (e.g., Thunderhead and Blockspaces).

ServicersBootstrapUnwindStart = 1.5 B Relays/day


This signals the amount of daily served relays that the DAO considers enough to stop the incentives for the servicers. This value and ServicersBootstrapUnwindStart define the velocity in incentives reduction. The selection of this value is discretionary; it was selected to provide a relatively fast reduction of the incentives, without creating large incentive-misalignment periods (in relays/day terms).

ServicersBootstrapEnd = 10 B Relays/day


The gateway bootstrap starts at zero relays with a cost per relay of MinBootstrapGatewayFeePerRelay (what the gateways pay to the DAO to be burned). This value should start to climb at a given point, as gateways’ traffic starts to build and their margins grow. This value represents the point where the fee that the DAO charges for gateways starts to climb; it was selected to obtain a smooth change in gateway fees.

GatewaysBootstrapUnwindStart = 2.5 B Relays/day


Once the gateways have enough volume (and margin) to pay their DAO fees, their incentivization should stop. This value signals that point, where the volume of relays is considered great enough to enable the gateway operators to fully pay the fees charged by the DAO. We selected this value to avoid drastically changing the landscape for existing gateways and, instead, produce a slow drop in their earnings per relay while maintaining a steady increase in their gains. The side effect of achieving this “smoothness” for gateways is setting the supply decrease threshold at around 16 B relays/day.

GatewaysBootstrapEnd = 20 B Relays/day

On the timing and implementation of this proposal in V0 and its projection to V1

We choose to launch this proposal now since the basic building blocks of supply and demand are already in place. Unlike previous proposals like WAGMI, FREN, SER and ARR, today we have the demand side (burning) to counter supply (minting). This enables us to develop more stable minting strategies that are apt fit to last longer and align better with the spirit of the Pocket Network.
With this proposal we try to avoid setting parameters with disregard to the mechanics that tie them to other parts of the network as that would produce many undesirable effects, such as under/over minting. We believe that ARR makes this mistake, but we understand that it comes from a simplicity-first approach.
This proposal is as agnostic as possible in terms of the Pocket Network version. Regardless of the version, the ecosystem works by producing and selling relays. Produced relays have a cost (MaturityRelayCost) and they are sold for a price (MaturityRelayCharge); this is true in V0 and will be true in V1.
The tokenomics research of V1 should deal with how we distribute the MaturityRelayCharge among the different supply actors (servicers, validators, watchers and DAO) or if we mint more than what we burn, but it won’t deal with how much we charge. Setting the value of a relay in USD is part of setting a competitive price to make the protocol viable.

The main (minting) differences that we see between V0 and V1 are:

Parameter / Concept V0 V1 Comment
Number of Actors that require minting 3: DAO, Validators, Servicers 4+ : Adds Watchers (at least) The proposal makes no assumption on this.
Minting Control RTTM Salary distribution + Score card modulation The total to be minted is deterministic, all perfect score cards, the total to be minted can be modulated as this level using the RTTM as the full relay price
Burning Control GFPR Application Burn Rate The burning will be directly applied to the Apps stake, same concept as GFPR. Modulation of relay costs can be done on top of this parameter, anyway there is no specification for this last feature yet.
Bootstraping thresholds 4 parameters - Off chain Not implemented This is the only thing that has no V1 parallel, but it does not need to have them, as all of these parameters are actually DAO guidelines that can be implemented in V1 seamlessly.

This proposal can be carried over to V1 without changing its spirit.

We believe that there is no current impediment to starting to plan overall minting in the mid- to long term, and to change the paradigm from short-term contingency plans that need constant reviews, to more systemic approaches to the Pocket economy.

Dissenting Opinions

You are not addressing the reduction of the network cost, which is the main driving force of the POKT depreciation as per your macroeconomic paper…

We do not mention the network cost directly because we cannot control that. Also, as we say in the paper, emission control policies won’t drive up the token price.

We do not claim that this proposal will affect the price in any way. The anticipated effect of this proposal is an increase in the incomes of the Pocket Network supply-side actors from total relay volume growth, which can be boosted by marketing to expand the user base. In addition, it is anticipated that the knock-on effect of increased investment and decentralization (more gateways and node runners) from the cost/fee predictability that MINT introduces will invigorate the network and the value of POKT.

In the future, when we determine the cost of the network (by means of the PNF survey or any other method), we can adjust the MaturityRelayCost with more precision and the other parameters (as needed).

You are denominating everything in USD after you advocated for a POKT-centric economy.

This is true, but we did this out of necessity. The current token exchange rate is very volatile, so an external reference is needed to be able to compete on the open market. In the future it may be possible to directly denominate the values MaturityRelayCharge and MaturityRelayCost in POKT and to remove the exchange rate $\epsilon$ from the formulas.

How is this different from a fixed emission rate in USD?

A fixed emission rate in USD provides no horizon for servicers that are currently operating at a loss. Servicers are at loss and will continue to be after reaching 10B, 30B or any number of daily relays.
Generating positive expectancy for the supply side is necessary to push through the gateways bootstrap phase.

Why not keep ARR and only increase Gateway fees?

If ARR is kept and gateway fees are increased we will reach a reduction of the supply faster than would occur following adoption of this proposal. However, the ARR mechanism is not well prepared to handle a fixed relay cost denominated in USD. Also the ARR mechanism does not align servicers with protocol growth, only with POKT-to-fiat exchange-rate increases. This is undesirable, as all actors of the network should be aligned with traffic increase.

We need to reduce emissions faster.

The proposed values introduce sufficiently strict control over emissions.

We believe that one of the main virtues of this system is not the immediate reduction of emissions, but rather the ability to project future gains and the alignment of servicers’ incentives with protocol growth that was lost with emission-control mechanisms (necessary at the time).
Finally, emission reduction proposals have shown no direct correlation to increases in the USD value of POKT; keeping focused on emission reduction for its own sake is unwise. This proposal will keep emissions low and enable cost and price projections (which can attract investment).

Make burning = minting

That would mean that the servicers are paying for the bootstrapping of gateways , which is both unfair and unsustainable at the current level of (reward emissions * POKT price) which would ultimately lead to servicers leaving the ecosystem and hurting the ability of Pocket to achieve its purpose of processing relays. The only way that we can reach that “equilibrium” is for both parties to pay the full maturity price. Forcing the gateways to pay full price is currently not possible, so setting the burning = minting today is not workable.

Why do the net emissions grow with relays? Can’t this just be a linear reduction?

This is the price that we need to pay to keep the model simple. If we wish to keep the net emissions in a state of steady decline until maturity we would need to convert the update mechanisms of RTTM and GFPR into polynomial expressions, which will be harder for the community to understand. We believe that non-linear net minting during the bootstrapping phase is an acceptable price to pay for model simplicity. (“Polynomial” means an expression of more than two algebraic terms.)

This has too many parameters!

This proposal has only one on-chain parameter, all the other things that you see are DAO directives. (When ABR replaces GFPR in v1, it will have two on-chain parameters.)


This is only 2 linear functions and 2 ifs.

A very dark corner

You clicked it, now don’t complain.

Computation of parameters


The GatewayFeePerRelay (GFPR) controls how much POKT is burned per relay. This is a parameter that takes the place of the ApplicationBurnRate during Pocket Network v0. This parameter controls the amount of Pocket that is destroyed (burned) per relay; it is the main instrument to create network profit and organic demand for the token. Per this proposal, this value should vary as a linear function of the total number of relays that are processed per day in the network. Also, the exchange rate (epsilon) of POKT to USD will affect the GFPR value, since the parameters are (currently) denominated in USD. The resulting function is a piecewise linear function with three segments: the bootstrapping, the BootStrapUnwind and the maturity:

The parameters $A_{RTTM}$ and $B_{RTTM}$ are those of a linear function. They are computed as:

This results in the following behavior, for different POKT exchange rates:


The RelaysToTokensMultiplier (RTTM) parameter controls the amount of tokens (POKT) that is minted per completed relay. This parameter is the main lever that controls the network minting (discounting only the DAO share, currently 5%). We propose to control this parameter in a similar fashion as the GatewayFeePerRelay, only that this one works the other way, decreasing as the bootstrap phase of the network unwinds. Again, we propose a piecewise linear function to describe this behavior:

Where $A_{RTTM}$ and $B_{RTTM}$ are the parameters of a linear function. They are computed as:

Finally the value of the RTTM is obtained by implementing the supply growth hard cap:

Where RTTMc is the maximum RTTM that creates a supply growth of 5%:

Where G = 5% is the target supply growth, Mb is the monetary base at a given point and R x 365.2 is the annualized amount of relays.

The behavior of this equation is shown below for different POKT exchange rates:


Web3Index and Token Terminal Positioning

In the following figures we show, respectively, the Web3Index and Token Terminal positioning as a function of the number of processed relays.

The Web3Index shows only projects related to web3. For this reason the number of projects that are shown alongside Pocket Network is reduced (only 4). To reach the top of the Web3Index we need only reach a constant number of relays above ~2.2 B relays/day. For this reason, both ARR and MINT will have no difference in scaling. However, it can be seen that after 2.5 B relays/day, the proposed MINT method shows a faster growth. This growth is more evident in the Token Terminal chart:

When we select “Infrastructure” in Token Terminal’s market selector, the Pocket Network appears along with many other projects. Due to the prevalence of projects like Flashbots and Eth Name Services (ENS), the Pocket Network is sunk in a long tail (6th place) and its volume does not seem to be very different from the rest. Climbing in this chart is far more difficult and here the effect of this proposal is pronounced:

(Flashbots was removed due to its large volume)
It can be seen that with ARR, we would need to have more than 20 B relays/day to enter the top 3 of the chart (surpassing Instadapp). However, with the current MINT proposal we would reach that position at ~13 B relays/day. We would even reach second place with fewer than 30 B relays/day, an objective that is very difficult to reach with ARR (something like ~50 B relays/day).

RTTM and GFPR evolution and comparison

In the figure below the evolution of RTTM and that of GFPR evolution are plotted together for the current (at the time of writing) exchange rate of 0.025 USD/POKT, along with lower and higher exchange rates for each (thin dashed lines). The current values of RTTM and GFPR are plotted as the horizontal dashed lines in red and green respectively

It can be seen that the proposed values represent a reduction in the emissions per relays compared with current values (red dashed line) as the number of relays increases. The proposed values will create larger RTTMs only when the token value decreases, but always constrained by the supply growth cap (hence the non-linear behavior for lower token prices). On the other hand, if the token appreciates, the emissions will be reduced accordingly and keep the expected linear change.

Minting in POKT

The minting in terms of POKT tokens is shown below. The solid blue line shows the net minting (minting-burning) of the protocol as a function of the number of relays per day. The dashed blue lines present the same information for lower exchange rates (producing more minting) and higher exchange rates (producing less minting). The red and green dashed lines present the same information given the previous minting mechanism: (SER) and the current (ARR).

It can be seen that the minting rate will increase compared with ARR values and will be lower than end-of-SER values for most of the trajectory of the curve (given current exchange rates). The “equilibrium” (minting = burning) is achieved close to the GatewaysBootstrapEnd as expected. While this is expected, it does not translate into a negative metric, as any additional minting is canceled out by the additional burning. The supply reduction threshold is moved to ~16 B relays/day, which is approximately twice that of ARR. This is the price that is paid to keep the gateways’ bootstrapping phase as smooth as possible.

A chest

You found a Small Key!

Minting in USD

The minting in terms of USD is shown below. This figure presents the same information as the previous one, with the only difference being that the values are expressed in a fiat currency (USD). The ARR emissions for different exchange rates are presented as thinner lines. Higher curves represent higher exchange rates, and lower curves, lower exchange rates. The dashed blue lines represent the minting for the current proposal at different exchange rates (0.00625, 0.0125, 0.05 and 0.1 USD/POKT), with higher lines showing higher exchange rates.

The proposed method creates a mostly fixed USD-rated emission for a given amount of relays. Almost all curves representing the emissions for different exchange rates overlap (represented as a tick line). The only moment when the minting in USD is different from what’s expected is when the supply growth cap is reached. It is important to note that the supply cap affects low POKT exchange rates, meaning that more POKT is minted when the exchange rate is high, which creates a positive feedback loop that drives the profitability of the servicers during the bootstrap phase. In other words, if servicers dump tokens making the price go down it will result in less USD denominated gains for them.
The ARR emissions (current system) vary notoriously with the exchange rate, which is undesirable given the current market volatility and failing to achieve network gains (negative USD emissions) at some exchange rates due to the GFPR and RTTM being decoupled.

Supply Growth

The minting curves in POKT can also be presented as a percentage of the current supply. When projected to a year, it produces the supply growth over the year. Considering the current supply of ~1.5 B POKT, the supply growth at value of “relays per day” is calculated.

Under MINT, supply growth cannot exceed 5%. It only reaches pre-SER values for exchange rates below 0.01 USD/POKT and traffic above 10 B relays/day. After the bootstrap phases are over (actually, a little earlier) the supply constriction starts and accelerates slightly. The speed of the supply reduction is related to the supply increase. This means that higher supply increase rates are matched with higher supply decrease rates after the bootstrap phase ends. Compared to the current projection based on ARR, this proposal takes twice as long to achieve supply reduction, but in contrast we provide an increase in reported fees to Token Terminal and Web3Index while keeping the impact on gateways as small as possible.

Network supply side earnings and Gateways payments in POKT

One of the most interesting things to observe in this model is how it provides an uncapped growth of gains for node runners and payments for the gateways. The first is important as it keeps focus on the long term viability of the project, and aligns ecosystem growth with the servicers’ gains. The second, gateway payments, defines the period when the gateways are being incentivised and promotes the creation of new gateways.
The figure below shows the earnings of the servicers and the payments of the gateways (denominated in POKT). The higher thinner curves represent lower exchange rates of USD/POKT and the lower thinner curves represent higher exchange rates. The SER dashed lines present the gains of servicers in the current system. The gold-orange dashed line is the current gateway payment (fixed rate).

One of the main things to note is that the proposed system will encourage node runners, who will see a ~2x in their gains if the goal of 10 B daily relays is met (and constantly growing). Also it is clear how the current system disfavors node runners, as the price that the DAO is currently charging the Gateways is artificially low. The difference between the orange-solid and orange-red dashed lines is the indirect incentive paid by the DAO to the gateways. It can also be seen that shortly before the 16 B relays/day mark is reached, the amount paid by the gateways will be higher than the payments that go to the servicers, creating protocol profit that can be controlled by varying the ratio between GFPR and RTTM (by changing the MaturityRelayCharge and/or MaturityRelayCost.

Servicers earnings and Gateways payments in USD

Once more, we present the previous figure in terms of USD. In this graph we added the Gateways Earning trace (solid green line) that represents the earnings of the gateways if they charge the end user an average price of 0.000004 USD/relay.

As expected, the USD emissions of the protocol follow the same path regardless of the token exchange rate. On the other hand, the ARR-controlled emissions are highly dependent on the token exchange rate and create no incentives for servicers to grow the ecosystem, as their gains are tied only to the exchange rate of the token and not relay volume.

Please, please, add support for latex equations to the forum…


Thanks for taking the time to put this together. I will review over the weekend


Is this being proposed as an alternative to PNF’s PUP-X: Accelerating the Road to Revenue (ARR)?

Complete Side Note

I feel that dropping 5 economic posts, regarding varying areas of the network, all at one time is far too much for everyone to digest. I do not have the bandwidth to meaningfully consider all these proposals all at the same time, and I would have a hard time thinking many would. I would suggest not posting everything all at the same time and adopt a progressive approach so discussions can be focused.



re side note, I will respond in the macroeconomics thread to keep this one about a simple minting mechanism


This is a lot of information to parse. Can you dumb this down a bit?

1 Like

At first read, this seems to make a lot of sense. Cutting emissions, incentivizing Node-runners & Gateways to optimize paid growth and giving future rewards prediction stability.

I look forward to read @msa6867 and @shane’s thoughts amongst others.

Without getting too ahead of myself, I’d be interested to see this as part of a ‘Grand Bargain’ to also change the Era budget to increase subsidies for Gateways and then incentivizing Gateway growth both to process more paid relays + start other revenue generating activities.


For MaturityRelayCharge:

Is it expected that Gateways will be free to charge end clients their own price structure, perceived to sit somewhere between the differential of the 75% - 100% of Infura’s costs?

I.e. so they would be expected to charge 85% of infura’s cost, making 10% and their customer ‘saving’ 15%. At maturity.

If so, how does Infura bulk pricing affect this?

1 Like

Yes, but that number is arbitrary. Using Infura as a benchmark might not be the best and maybe 75% of their rate leaves to little space for gateways. So, this number can be discussed and modified.
We are more interested in the concept of setting a MaturityRelayCharge than the exact value. We actually expect to reach some consensus about that in this thread and I look forward @poktblade and @ArtSabintsev comments on that (and any other potential portal operators).


Let me try…

Think of this as setting up two milestones and two relay prices:

For Node Runners

  • Set a value that you wish to pay them per relay (MaturityRelayCost)
  • Set a number of relays per day that signals the end of the “bootstrapping” (ServicersBootstrapEnd)

So, the idea is that you know how much the protocol will pay node runners after you have more than ServicersBootstrapEnd relays per day. Before reaching this threshold the DAO will pay the node runners more to build up the supply side.

For Gateways

  • Set a value that you wish to charge them per relay (MaturityRelayCharge). This is the amount of POKT per relay that they will be paying the DAO to be burned.
  • Set a number of relays per day that signals the end of the “bootstrapping” (GatewaysBootstrapEnd)

The idea is the same, until you reach the selected number of relays per day (GatewaysBootstrapEnd) you will charge them less in order to help them kickstart the demand side of the network. After you reach the selected threshold, you charge the full price.

What about all the graphs and stuff?

The rest of the post shows that this approach will not mint more than the current scenario (SER) and explores different situations.
Also, we show that we will reach “deflation” at less than 10 B relays a day (the current proposal of PNF targets this value).
Finally we show that with this approach the node runners will be interested in the relay growth of the network, as opposed to the other proposals.

Are the relay prices that you give definitive?

No. We actually care more about the model of the MINT strategy than in the actual values. Fell free to propose new value sets.


Hey @RawthiL thanks again to you and the POKTscan team for all your amazing contributions over the years, and almost every week at this stage.

And this is another genuinely impressive contribution, even if I believe that this proposal isn’t what Pocket needs right now, as it will cause more harm than good if introduced.

In responding here, I am also bringing some of our private conversations to the public sphere.

Unclear Purpose

First off, my main concern is that it’s unclear what the actual objective of this proposal is. If it’s simply to prevent inflation from dropping as low as 4.98% (as per the ARR proposal), then it would be better to argue about this directly rather than introducing so much complexity and governance overhead by way of the introduction of 10 new parameters to govern and update over time. Notwithstanding how thoughtful this proposal is, it will still be way too unwiedly for new contributors to grok.

Further, given that we are about to start a major first principles review of Pocket’s economics as part of the economic R&D workstream for v1, it is unlikely that this newly proposed system will be relevant for v1, or even in a few months. So the cost/benefit is unclear.

Doesn’t fix inflation concerns

Secondly, in addition to the point above, it is highly unlikely that this proposal will achieve our primary aim at PNF (with the ARR proposal) to:

Partly because this proposal has so many parameters, so it will be harder for the message to cut through, but also because MINT allows net inflation to increase again in the future, even though it is expected that such a higher number of relays, meaning more protocol burn and more demand for Pocket’s service would result in a higher price of POKT, which could mean even additional increases in payments to Pocket’s supply side, in terms of both the quantity and value of POKT, without clear justification for doing so.

Node runners are some of the largest holders of POKT; if they don’t care about the network’s success, then we have much bigger problems to worry about. Can you explain why node runners wouldn’t care about the growth in the value of their POKT?

The supply side benefits from capital appreciation from their POKT stakes and revenue growth from servicing relays in the network. So I disagree that the supply side won’t benefit from the network’s growth and success.

This proposal hinders the growth of our demand-side

Thirdly, the attempt to program the protocol fee for gateway operators seems to be an unnecessary distraction prior to v1. In any case, it’s much harder to grow demand than supply. And any attempt to reduce the incentive to grow Pocket’s demand side will cause us all to suffer. We see this in our conversations with new gateway operators who are worried about the cost of each relay they bring to the protocol. The protocol fee is clearly low, but it’s still a barrier to growth when Pocket currently has a tiny fraction of the market.

The fact is that no gateway operator is yet profitable. So this is an attempt to deal with a problem - excess profits of gateway operators - that doesn’t yet exist.

Is POKT money or capital or both? And what should we optimise for right now?

Lastly, I acknowledge that we have fundamentally different views of how Pocket’s economy should be designed and structured and how stakeholders benefit from their role within the ecosystem. For example, you have mentioned several times that you believe that POKT should be analysed in the context of money. This is a much longer conversation, but my main pushback on this is that without designing the Pocket ecosystem so that POKT becomes a true store of value - as opposed to a cryptocapital asset or a cryptocommodity - the velocity problem will make POKT’s value capture potential difficult, to say the least. I view POKT as a combination of a a cryptocapital asset and a cryptocommodity, and I refer you to the work of Placeholder in this regard, as my views largely reflect theirs - Value Capture and Quantification: Cryptocapital vs Cryptocommodities — Placeholder

The question of the sustainability of Pocket’s economics is genuinely holding back new contributors and capital providers from joining the community. Reducing protocol inflation in very clear and explicit terms will give confidence to the outside world that Pocket is on the right path, making it easier to incentivise more talent to join us and raise Pocket’s profile to the world-class level we are all aiming for.

Pocket’s supply side will get paid more and more in direct fees over time for their work and will also benefit from the capital appreciation in their stake. Excess rewards will get competed away by other more efficient networks, and the more we overpay the supply side, the more we risk causing another unsustainable boom and bust cycle, just like last year.


The purpose is not just to bring down inflation, it is specifically about adding “something else”. We used the 5% reference to make sure that this proposal is not regarded as a greedy proposal coming from a node running company.

The intention is to reduce inflation and more importantly give perspective and projection.

The V1 research will be way more complex than this proposal, simply by the number of network actors that it must include.
I dissagre that this proposal will be irrelevant in V1. We tried to avoid making assumptions about the distribution of the relays incomes (servicer / validator / DAO splits) and we focus solely on the Pocket Networks export product price, the relay.
In V0 and as well in V1, the only source of incomes that the protocol will have is the commercialization of relays. The relays being sold to the public will be paid in POKT at a price given by MaturityRelayCharge and the protocol will incur in costs for producing them given by MaturityRelayCost. This mechanic exceds V0 and is completely applicable in V1.
The research in V1 will have to deal (among other things) in how to distribute these rewards among the new actors.

As I understand it, this argument can be summarized as:

Node runners are POKT holders and they will benefit from the increase of POKT price.

We disagree with this because:

  • Makes assumptions about node runners POKT treasuries.
  • Bounds success of supply side to a non-controlled variable such as POKT exchange rate.
  • Works against the attraction of new builders (the cited point), since new node runners have no “bags”. If the intention is to only attract gateways or other types of builders, then the quote should be modified.

They do care about the value of the POKT token, but they clearly dont care about how many relays are run through the network. This is observed in the TG chats, where relays ATH are disregarded (with a large amount of trolling) by holders and node runners alike.

This is indeed the main friction portion of this proposal, but we are trading what we think is a small amount of friction for a clear view of the mid/long-term operation of the network. As a gateway operator I would be more worried about the real cost of the relays than the actual one.
Anyway, the ones that should give their opinions on this subject are the current portal operations, PNI and Nodies.

I will answer this later in the main thread. The topic is indeed a long one, and the article you cite (and the larger one that is the base of its assumptions) is very interesting (contrary to our views tho).
(to everyone else trying to discuss the POKT token nature please refer there)


Before looking into details, here is some top-level feedback.

  1. The proposal will be cleaner and easier to follow if you do not introduce new DAO-governed parameters. The only two actual parameters being modified are RelaysToTokensMultiplier (RTTM) and GatewayFeePerRelay (GFPR) [introducing a new acronym for ease in the following discussion). Everything else is simply instructions to PNF on how to set the parameters on a week by week basis. This is consistent with how WAGMI, FREN and SER were structured, where RTTM is the single parameter being modified, but along the way intermediate concepts are introduced (target inflation in the case of WAGMI, target daily emissions in the case of FREN and SER

  2. This is a v0-era proposal (RTTM is not a v1 parameter and GFPR is set to be removed with v1). Description would be helpful on (a) why this is needed in v0 vs "can it wait til v1 and (b) what is the intended transition of the concepts contained here into the v1 context

  3. If at all possible, I suggest separating this into two proposals, one for setting GFPR and one for setting RTTM. If not possible, I suggest adding to the rationale section why it is absolutely imperative to set both parameters in tandem. As it stands, it seems like GFPR and RTTM are being set completely independent of each other, and their being adjusted jointly in a single proposal is mainly so that the net emissions are seen to be well contained. This makes it hard to do apples-to-apples comparison between your proposed methodology to set RTTM, and the SER and ARR methodologies. (Net emissions for SER and ARR would also look rosier in an environment of linear-increasing GFPR vs the current static $0.00000085.) I envision your having a GFPR proposal that is completely stand-alone without reference to any other parameter and a RTTM proposal that is competing with ARR and SER for methodology to finish out v0 that may have dependency on GFPR. The benefit is that (a) adequate focus is given on right-setting the value of GFPR which will be a highly-contentious topic and (b) an alternate RTTM methodology to SER and ARR can be discussed and considered even if the DAO is disinclined to adjust GFPR at this time.

  4. I think there is universal agreement that GFPR = $0.00000085 is a highly-subsidized rate , not a “maturity” rate. and that the goal is to raise this (on the on-chain app burn equivalent in v1) over time. The rationale I think you need in your rationale section is why we should consider defining, right now, the movement toward maturity vs simply letting the system settle down at current values and revisiting right-sizing GFPR some months down the road.

  5. Likewise, there is (I assume) near-universal agreement that in maturity emissions will grow, likely linearly, as paid demand (app burn and/or gateway fee&burn) grows and the the WAGMIFREN/SER/ARR construct of suppressing emissions from growing as demand grows is a temporary mechanism only to reign in inflation. The rationale I think you need in your rationale section is why we should consider reintroducing, right now, the growth of emissions as relays grow, versus holding off until RTTM is brought closer to maturity-level values.

A common theme of #2-5 above is to make the Rationale section more about why the DAO should choose the methodology outlined in this proposal vs keeping with the status quo or choosing a competing proposal (e.g., ARR), rather than about the specifics of parameter values. Perhaps the latter could go into a new section that includes not only the nominal value listed but also a ball-park range of what you see to be the “sand-box” of possible values to consider for the parameter in question.


I certainly empathize with the desire to reintroduce the growth of emissions as relays grow and we have discussed privately the deficiency of WAGMI/FREN/SER in regard to this decoupling. Have you considered the much simpler proposal of simply tacking on an extra component to emissions equal to a percentage (less than 1) of GFPR-based treasury burn; e.g., that could be a stand-alone proposal to modify SER or you could work with PNF to amend ARR proposal to include a percentage-of-burn component to emissions. This really is in keeping with the march toward maturity idea of burn&mint with an ever-decreasing subsidy,

On the other hand, I do think the misalignment of node-provider incentive to grow relays compared to gateway-provider incentive to grow relays is over-stated. Gateway providers are essentially wholesalers - the sales-people of the system. Their pay is entirely dependent on their sales effort. And their pay is naturally and singly tied to their ability to bring it sales at a cost higher than the wholesale cost they are being charged. Node providers are more like the widget makers of the factory rather than the sales people of the factory. Of course we want the “widget-makers” to be evangelists for the widgets they make, and the factory offers referral incentives etc, but ultimately the factory relies on it’s sales force to bring in sales. Of course, your point is that it is reasonable for the widget maker to expect to get paid based on the number of widgets it makes… totally true once the system reaches operational maturity, but in a period of time where the compensation is still mostly subsidy, I think it is equally reasonable for the widget makers to grow into fixed subsidies that are set in a way to optimize efficiency over quantity


Regarding the GFPR methodology you outline, it is a fairly sound approach (if potentially a bit premature) assuming a single-party gateway provider. However, in a multi-party environment, such as the one we are now entering into, it is not clear that the approach is tenable.

In a single-gateway environment, it is reasonable to reduce wholesale-price subsidies as a function of total system relays, as it is reasonable to expect the gateway provider to become less reliant on subsidies as it grows into its economies of scale. In a multi-party environment, the economies of scale each gateway provider is able to achieve is based solely on traffic handled by that provider, not on the traffic handled by the entire system. Therefore, there is no basis for setting subsidy levels on the total system traffic.

Since GFPR is an off-chain parameter meant to get us through the remainder of v0, perhaps it is possible to re-invent it as being able to take on different values based on gateway-provider-specific metrics. I.e., base the fee level not on total system relays, but on the relays served by each specific provider? That way greater subsidies can be given to start-up gateways to incentivize their start up period, with subsidies being reduced as they mature and achieve economies of scale.

@cryptocorn - Could you clarify this comment/question? The ERA budget contains some funds for on-off grants to help bootstrap new gateway providers (“this is a funding bucket for supporting their launch regarding legal, docs or any other small support needs they may have to go live.”). This is independent of and outside the scope of the manner in which “subsidy” is used in this proposal with respect to gateway providers, namely the charging of a wholesale rate that is below fair market rate for the protocol-level service being rendered to the gateway (wholeseller).

1 Like

I’m not a DAO voter so am mostly sharing this to illustrate how challenging it is to be faced with assessing a proposal like this. I feel quite aligned with the response of Dermot and MSA but am especially aligned with this comment:

The reason it resonates so much is because it’s just not clear what is the exact problem this is trying to solve for and it’s really really hard to land on “is this the right answer” if everyone is not crystal clear that we are working on the right problem.

I have shared this previously but I think proposals and debates are a lot simpler when we work sequentially through the logical steps:

  • Is this a need/problem? Go to next step:
  • Is it a need right now?
  • Is this the right solution?
  • Is this the right team/person (to implement, when relevant)?
  • Is this the right size/price (to pay, when relevant)?

Mashing it all together feels like a huge cognitive load and frankly I don’t think it leads to good decisions.

Personally I am still stuck at step one and find the “Motivation” section of this proposal quite weak because I don’t think it defines the problem well enough. If the problem statement is:

then it feels extremely lite in comparison to the solution offered; the solution offered seems so large and complex; and it feels like there is a deeply wrong assumption behind it all that somehow node operators aren’t encouraged to see network growth. If there is a node runner who does not believe 10B relays will be better for Pocket Network (and their bags) than 1B please can they explain: Why?

I appreciate the depth of intellectual rigour around the solution and I’m very open to being led to the conclusion that this is the right thing at the right time. But unless there is a real evidence that misalignment of incentives means we are not all invested in the growth of Pocket I don’t see why this needs to be done in the v-0/pre-v1 era, and I definitely can’t assess why 10 new parameters is the optimal solution.


Thanks for the answer - this is exactly what I was hoping to hear.

I continue to warm up to the methodology here, even if in the subsequent proposal some of the parameter current values may have to be changed, especially on feedback from Nodies/PNI on realistic numbers that would allow them to operate Gateway businesses effectively. I make the assumption that the proposal is relatively flexible to change the parameter values based on feedback.

@msa6867 - Without going too far off topic, the Era budget has ~$30k to help Gateways at present. I think that this number will need to be significantly increased to allow Gateways to flourish as we think will be beneficial to the ecosystem. While that debate belongs in the Era discussion, it move to the above with the question of ‘how and how much are we going to subsidise relays for Gateways?’ We could either keep the 0.00000085 price static for a longer period of time, or raise it earlier but then send direct subsidies to the Gateways to help offset these costs amongst others. Either way, the DAO is in effect subsidising the Gateways.

1 Like

Yes, not to distract from this discusssion but I will provide an update on this in the PEP60 thread soon


Thanks for the clarification. I agree that direct DAO-to-gateway-provider grants may be a better mechanism to help new gateways navigate the start up period than keeping GFPR artificially low. That would be in keeping with the proposal objective of " * Correctly identify which participant in the network is being subsidized by the DAO" and could help answer @Dermot 's objection of hindering the growth of the demand side


I think it’s also beneficial that by subsidising the Gateways from the DAO directly, the amount of POKT burned increases as the GFPR increases - so will help our placing on metric boards, instead of subsidizing at the GFPR level and lowering the amount burned.

Ultimately its going one way than the other to reach the same destination, but the optics and marketing are far better if we significantly increase the burn.

@b3n - I have been meaning to write some of the above on the Era budget proposal, but i’ll wait for your update. TLDR - more money to adequately subsidize the Gateways to fulfil their potential.


Thank-you @RawthiL for the model you provided! MINT - Calculate RTTM and GFPR - Google Sheets

While I don’t fully understand all the calculations behind each variable, this gives us a chance to see what the effect would be in different scenarios. I understand that sometimes a model can’t have simplified math, so having the math in an expressive form that shows the effects, is key. Much thanks :slightly_smiling_face:

From my initial glance, I love the concept of allowing growth in node rewards in accordance to relays. That was the intended design of POKT from the begining, and I don’t think any ecosystem can function in the long term without a common incentive… which for POKT should be driving relays.

However, I don’t see how this model will work. When I set the Projected Results to Month, set the Relays Per Day to 10B, the Gateway Burn is $1.4M+ a month. I added a few extra field to show the actual cost per relay, and as you can see, it’s only a few digits from what the Portal charges their customer per relay. With this high of a burn rate, gateways would have to increase their prices to Infura level prices… eating away the primary advantage of POKT, cheaper relays.

A gateway like Nodies already has infra that is supplemented by POKT rewards… so why would they use POKT at all, especially if the burn cost is that high?

It would also be significantly cheaper for gateways to just run their own infra instead of the $1.4M+ a month charge. I can’t see how that would work.

While I love the concept, but I don’t see how this high of a fee is possible at this time.

However, I’m not sold that we have to cut everything down to be deflationary at 10B a day. I’m not sold that it is the golden bullet to start us down the right path. I’ve maintained that I believe the greatest value to the ecosystem would be something that encourages folks to lock up POKT, in either staking or some other mechanism.