Protocol Economics Parameters for the Shannon Upgrade

The Pocket Network Economics Committee, composed of @RawthiL , @TracieCMyers , and with input from PNF, has created the following guidance for Shannon tokenomics. Please review and add your comments where necessary.

Main Mechanisms

With the Shannon update, the protocol leaves the open-beta phase and enters the initial stages of its maturity. In line with this natural growth, the relative prices of the Pocket Network economy (tokenomics) need to be adjusted and set to a level which positions the protocol as a real competitor in the market.

While the protocol aims to serve several protocols and data sources, there is currently a single type of traffic being transacted in the network: the blockchain traffic. In this context the analysis of the market that drives this document is focused only on that data type, and seeks to position the Pocket Network as a realistic alternative to the existing offers.

Minting Strategy

Starting with Shannon, the network supports on-chain and automatic burning of tokens to pay for relaying services. Also, it permits the staking of permissionless demand, and to enable this there is no other mechanism than to set the total minting equal to the application burning.

Initially, the Shannon upgrade will have no supply growth. However, if the DAO decides it is necessary, it can increase the total supply by using the reimbursement event in the Shannon protocol. This mechanism should only be used to mint in favor of the DAO treasury, as any other recipient of the burn-mint asymmetry can result in self-dealing. Implementing this strategy and accounting for the DAO share in all minting transactions will result in a liquidity reduction since:

Liquid POKT burned > Liquid POKT Minted

The Price of a Pocket Compute Unit

Many offerings center their price models on a so-called “Compute Unit” (CU), which is loosely defined as the cost of processing and transmitting a unit of information. This conception is highly arbitrary, but is useful to denominate the prices of the different services that can be offered, and isolate the cost of a relay from the price of the POKT token.

Starting with Shannon, we will set the price of a CU in the Pocket Network to:

1 COMPUTE UNIT = 1 x10^-9 USD

or

1 USD per billion CUs

PNF will ensure the USD-denominated price by periodically controlling the Compute Unit To Token Multiplier (CUTTM) parameter of the Shannon upgrade. Initially, this parameter will be set to:

CUTTM = 66667 pPOKT

It is important to note that the denomination of the CUTTM is in pico POKT (1x10^-12), while its Morse corresponding parameter Relay To Token Multiplier (RTTM) was in micro POKT (1x10^-6). This is necessary to allow for cheap services and token price growth.

Currently the base RTTM is 190 uPOKT per relay, which means that the cheapest relaying service in Morse would consume ~2850 CUs in Shannon. This definition will be useful during the comparison and later definition of the average cost of a service in the Shannon update.

The next thing we need is to define the number of CUs for an average relay in the Pocket Network. For this, we need to compare our current price scheme with those of our main competitors. The full analysis of the competition can be seen at the end of this document in section “Blockchain Relays Competitor”. The main takeaways from that analysis are:

  • Average Relay Price for Competitors : 6.58 USD/M Relays
  • Average Relay Price for Pocket Network Service: 14.3 USD/M Relays
  • Cheapest Competition Offer : 2.5 USD/M Relays

In this context, we see that the Pocket Network is currently ~2x above the competitors (on average and in the comparable services). To remain competitive, the prices must match those of the competitors. Taking into account that the cheapest competitor offers a price of 2.5 USD/M Relays, in a plan that is pay-up-front (as opposed to Pocket Network that can be seen as a Pay-As-You-Go service) and that the service offering of the Pocket Network is in general much larger than the competitors, we propose to set the new average price of the Pocket network to:

Shannon Price per Million Relays (Average) : 2.50 USD

The execution of this will be done by setting the new base CUTTM to 495 pPOKT, translating into a reduction of all RTTMs by 5.76x and rounding down in the current network. This new price scheme will make most Pocket Services much cheaper than the competitors (from 30% to 75% reductions).

Others will remain higher (like: Harmony, Solana, opBNB and Kaia), which will need further adjustments, but the service-specific tuning of prices is out of the scope of this proposal. While the new per-services changes can change the target of the 2.5 USD/M relays, they will probably respond to negotiations between supply and demand, and the DAO should not interfere with this.

The general rule is that the DAO won’t be enforcing prices on services after this initial correction. The DAO will limit it to act on the market with the strength of its treasury and nothing else. The end-game for the Pocket network is to provide a free market for data sources, not to set prices.

Volume Rebates Schemes

The launch of the Shannon update means the final transition to maturity of the network, however this transition cannot be done in an open-loop fashion. The DAO is aware of the bootstrapping needs of the supply side and will make its best effort to keep the main traffic generators on track to meet their goals.

The main difference from the Morse approach to bootstrapping is that the supply won’t be increased in order to bootstrap actors. This strategy can only get us so far, and has been abused in the past to bootstrap the supply side. And, endless inflation only reduces the total value of the network, resulting in a net loss (see current market activity). Starting with Shannon, the bootstrapping of the demand will take the form of volume rebates.

The proposed rebate strategy is:

  • Average less than 250 B CUs/day (approx. 105 M Relays/day) : Full price (no rebate)
  • Average more than 1250 B CUs/day (approx 525 M Relays/day) : 40 % Percent rebate, resulting in burn cost of 1.5 USD / M Relays.
  • Between these traffic levels, the rebate will be a linear function between 10% and 40%. The more relays you do, the higher the rebate you receive.
  • The total rebatable CUs to be paid by the DAO will be capped at 128 Trillion CUs per quarter.

The rebate will be paid every quarter on the trailing averages for each of the gateways that request a rebate. Gateways requesting a rebate will need to register with the Foundation and agree to an established set of standards and practices.

Here is a quick reference for the rebate scheme; please refer to the analysis section for more details:

Average Traffic on the last 90 days Rebate
B CUs / Day M Relays / Day
Lower than 250 Lower than ~105
More than 250, less than 1250 More than 105, less than 525
More than 1250 More than ~525

On each pay date, the total traffic for the last quarter is analyzed, and the gateways that requested rebates are ordered by the amount of traffic they received. The average CUs per day they processed is calculated from the total traffic in the observed quarter. The budget of 128 T CUs is then assigned to the requesting gateways in this order until all requests are fulfilled or the rebate budget is exhausted. All traffic that falls outside of the budget will be paid in full by the gateways.

The strategy of using a linear growth of the rebate level and a cap on the total rebateable claims aim to minimize unnecessary traffic on the network and maximize the runway of the DAO treasury.

Morse to Shannon Reference

Brief description of each parameter change, as seen from the Morse network:

  • Base RTTM : from 190uPOKT per relay to 495 pPOKT per CU (change in unit). This is (approximatelly) equivalent to a reduction of the RTTM to 33uPOKT.
  • Any other (non-base RTTM) : Morse RTTM divided by 5.7575 and rounded down.
  • Base Gateway Fee Per Relay: from 0 uPOKT to 495 pPOKT per CU or ~33uPOKT per relay.
  • Any other (non-base GFPR) : Follows the same rule, RTTM = GFPR.

New Rebate Mechanism:

  • A traffic of less than ~105M Relay/day (in the current network) will mean no rebate.
  • Starting at 105M Relays/day the rebate will be 10% and grow linearly until 40% when passing the 525 M Relay/day.

Supply will be stable at the level it reaches when the Shannon migration is finished.

Relay minting share:

  • Servicer: 78 % (no change)
  • Validator: 14 % (no change)
  • DAO : From 8 % to 5 %
  • Owners : From 0% to 3 % (DAO will be the initial recipient of all owner rewards)

A proposed change of minting shares to increase validator incentive is being researched, but will not be in effect at Shannon go-live.

The Minimum Stake per Servicer will be increased from 15,000 POKT to 60,000 POKT, since more than 80% of the nodes are already staked at this level and Shannon does not have a stake multiplier system (aka PIP-22).

Analysis and Projections

In this section we will present the details behind the proposal, including data sources and calculation of the different parameters. Some basic projections of the DAO treasury evolution are also presented.

Blockchain Relays Competitors

The analysis of the Pocket Network competitors was centered on 4 operators: Alchemy, Infura, QuickNode and Chainstack. While these are not full competitors, they provide reference for the market price of several services available in the Pocket Network. The analysis was performed on 25 blockchain RPC services, and for each of them we tracked the lowest price given by all competitors.

As a general rule, we found that pay-as-you-go services are around 12 USD per million relays, and that the cheapest way to access these services is by paying upfront, where the price can drop to 2.5 USD per million relays.

Also, for each of these services, we calculated the price of the Pocket Network in the current price and RTTM conditions. Then we obtained the difference in price of the current status of the network and the market:

USD for 1M Relays DIFFERENCE USD for 1M Relays
Chain POKT Network CUs POKT Network Price (lower better) Cheapest Competitor
Solana (F025) 1932 $28.98 1059.20% $2.50
Fraxtal (F011) 694 $10.41 -16.72% $12.50
opBNB (F01F) 2375 $35.63 1325.00% $2.50
Harmony-0 (F014) 1932 $28.98 1059.20% $2.50
Sui (F026) 1049 $15.74 -37.06% $25.00
Ethereum (F00C) 606 $9.09 263.60% $2.50
BNB Smart Chain (F009) 606 $9.09 263.60% $2.50
Polygon zkEVM (F029) 606 $9.09 263.60% $2.50
Kaia (F016) 1932 $28.98 1059.20% $2.50
Fantom (F010) 960 $14.40 476.00% $2.50
Polygon (F021) 429 $6.44 157.40% $2.50
Arbitrum One (F001) 1049 $15.74 529.40% $2.50
Avalanche (F003) 1049 $15.74 529.40% $2.50
Base (F005) 473 $7.10 183.80% $2.50
zkSync (F02B) 694 $10.41 316.40% $2.50
Near (F01B) 1932 $28.98 -7.26% $31.25
Blast (F008) 872 $13.08 423.20% $2.50
Optimism (F01D) 694 $10.41 316.40% $2.50
Oasys (F01C) 517 $7.76 210.20% $2.50
Gnosis (F013) 429 $6.44 157.40% $2.50
Celo (F00B) 340 $5.10 104.00% $2.50
Scroll (F024) 473 $7.10 183.80% $2.50
Moonbeam (F019) 340 $5.10 104.00% $2.50
Celestia Archival (A0CA) 190 $2.85 -88.60% $25.00
Bitcoin (F007) 253 $3.80 51.80% $2.50
Osmosis (F020) 2375 $35.63 42.50% $25.00
Averge Relay CUs Average Relay Price Average Relay Price
914.76 $14.31 $6.59

It can be seen that the average price of the network is around 14.3 USD per million relays, making Pocket an average player for a pay-as-you-go business, however the limitations of the network (namely ease of access and QoS triage) make this price too high for the actual service.

In this context it is proposed to reduce the price of the network aiming for a 2.5 USD per million relays, a very competitive price for a pay-as-you-go service. With this change, the network prices are seen in the following table:

USD for 1M Relays DIFFERENCE USD for 1M Relays
Chain POKT Network CUs POKT Network Price (lower better) Cheapest Competitor
Solana (F025) 5033 $5.03 101.32% $2.50
Fraxtal (F011) 1808 $1.81 -85.54% $12.50
opBNB (F01F) 6188 $6.19 147.52% $2.50
Harmony-0 (F014) 5033 $5.03 101.32% $2.50
Sui (F026) 2733 $2.73 -89.07% $25.00
Ethereum (F00C) 1579 $1.58 -36.84% $2.50
BNB Smart Chain (F009) 1579 $1.58 -36.84% $2.50
Polygon zkEVM (F029) 1579 $1.58 -36.84% $2.50
Kaia (F016) 5033 $5.03 101.32% $2.50
Fantom (F010) 2501 $2.50 0.04% $2.50
Polygon (F021) 1118 $1.12 -55.28% $2.50
Arbitrum One (F001) 2733 $2.73 9.32% $2.50
Avalanche (F003) 2733 $2.73 9.32% $2.50
Base (F005) 1232 $1.23 -50.72% $2.50
zkSync (F02B) 1808 $1.81 -27.68% $2.50
Near (F01B) 5033 $5.03 -83.89% $31.25
Blast (F008) 2272 $2.27 -9.12% $2.50
Optimism (F01D) 1808 $1.81 -27.68% $2.50
Oasys (F01C) 1347 $1.35 -46.12% $2.50
Gnosis (F013) 1118 $1.12 -55.28% $2.50
Celo (F00B) 886 $0.89 -64.56% $2.50
Scroll (F024) 1232 $1.23 -50.72% $2.50
Moonbeam (F019) 886 $0.89 -64.56% $2.50
Celestia Archival (A0CA) 495 $0.50 -98.02% $25.00
Bitcoin (F007) 659 $0.66 -73.64% $2.50
Osmosis (F020) 6188 $6.19 -75.25% $25.00
Average Relay CUs Average Relay Price Average Relay Price
2383.24 $2.49 $6.59

In this new scenario the network is very competitive and leaves margin to create business on top of the base price.

It must be noted that all the price analysis had to be done as a function of the publicized prices from centralized services, since we were not able to obtain cost metrics and prices from the majority of the Pocket Network players.

Rebates Scenarios Analysis

In order to promote bulk traffic on the network during bootstrap of the demand side, the DAO agrees to provide rebates on large amounts of traffic. However, in a fixed-supply scenario, these rebates must come from the DAO treasury. Since the DAO treasury is finite, a strategy must be reached that maximizes the DAO treasury longevity and minimizes the risk of premature draining. To do this we analyzed how much time it will take to drain the DAO treasury by 50% under different rebate levels and total traffic.

The following graphics are heatmaps, where the Y axis represents the rebate levels, the X axis the total traffic that can be rebated the DAO and the color of each pixel represents the amount of days until the treasury is drained by half. The graphs also have two isolines, one in the contour of 360 days and the other on the contour of 180 days.

A valid rebate strategy is that in which the coordinate pair (rebate, traffic) remains below the 360 days isoline. Values above this line jeopardize the health of the DAO treasury.

The first figure shows this information as a function of the traffic in units of relays by day, a commonly used feature for traffic.

However the most important one is the second graph which tells us not only the rebate, but the total amount of CUs that can be rebated in a quarter. This limitation is key, since the treasury cannot support an arbitrary amount of gateways pushing a given rate of relays by date, it can only rebate up to a total amount of units per quarter.

DAO Treasury Evolution Under POKT Price Variations

The selected rebate levels:

  • Starting at 10% for 250 B CUs per day
  • Ending at 40% for 1250 B CUs per day
  • A total rebate of 128 T CUs per Quarter

Will work in the following ways:

Gateway Traffic Average Traffic Expected Rebate Remaining Budget Rebatable Effective Rebate
T CU / Quarter B CUs / Day M Relays / Day T CUs T CUs
Gateway A 78 866.67 363.65 28.50% 50 78
Gateway B 30 333.33 139.87 12.50% 20 30
Gateway C 25 277.78 116.55 10.83% -5 20
Gateway D 23 255.56 107.23 10.17% -28 0
Gateway E 15 166.67 69.93 0.00% -43 0

In this example we see 5 Gateways (from A to E) that requested rebates. They are ordered by the total number of CUs they received in the last 90 days. We see that the first two, Gateway A and B will receive a rebate of 28.5% and 12.5% according to the linear interpolation (see last column).

Gateway C, while still meeting the lower threshold of 250 B CUs/day, will not receive the expected rebate of 10.38% (see column “Expected Rebate”). This is because the budget was exhausted by 5 T CUs (see column “Remaining Budget”). In this case the rebate applies only to 20 T CUs (see column “Rebatable”) from the total 25 T CUs processed, resulting in an effective rebate of 8.67% (lower than expected).

Gateway D has no rebatable CUs left in the budget, and as a result its effective rebate goes from 10.17% to 0%.

Finally, Gateway E has not even reached the minimum of 250 B CUs/day, and consequently receives zero rebates.

With the selected rebates mechanism we can estimate how the DAO will evolve in dynamic scenarios. To do so we created a mildly positive scenario, where, within a year, the total amount of relays increases from 0.8 B/day to 5 B/day, and the amount of organic traffic (not requesting rebates) increases from 5% to 10% of the total. For these estimations we test 3 different price levels, one where the price declines to 0.007 USD, one where it remains stable at 0.015 USD and a third one where it increases to 0.05 USD.

After reaching these end values within a year (365 days) we keep them stable for another year (until day 730) to observe the evolution in the absence of changes.

The first graph shows how the DAO treasury sees a constant reduction, that is highly non-linear. The price going down can accelerate the exhaustion of the treasury but a growing price keeps it in a very healthy position.

The second graph shows the same information but now projected to USD, we can see now that a growing token price will increase the net DAO holdings in USD, greatly increasing the longevity of the treasury. In this case the lines are more linear, since the majority of the DAO expenses is denominated in USD.

5 Likes

Thank you for posting. I’ll review over the weekend.

This seems largely sensible, assuming enough Node-runners can still profitably run infra at these levels.

I appreciate there will always need to be tradeoffs in decision making, but I dislike the instability in future cost projections the 128 T Cu rebate cap/quarter brings.

I see the logic in rewarding the largest contributors first, i.e. Grove, but question how much this might disincentivize smaller gateways from participating if they believe they won’t be able to avail from the rebate program and as such face higher costs.

I don’t think there is an easy solution to this issue, but I’d like to see some debate on it if possible.

2 Likes

Hi all - this is targeted at the community at large since Fred and I already had a conversation with the economics committee and PNF about this over the weekend. We agree that we need to turn on token burning, and not just in a symbolic way, so we are throwing our support behind this proposal.

The goal of this post is to give everyone an understanding that this may affect Grove’s book of business.

Presently, we charge $2/mil requests, which doesn’t yet fully cover our costs of operations (but we’re getting close). Adding $2.50 on top of that as the fee to the protocol will change our cost structure that we’ll be passing onto our customers. We’ve won or retained most deals due to being competitive on price, non compute-unit pricing, and the large selection of chains Pocket provides. We’re not ignorant to the fact that this has only been feasible because all token holders have been subsidizing relays through endless inflation.

We also know that the goal of the Grove, an open source and engineering-focused R&D team, is to:

  • Build the protocol
  • Build PATH ← Growing decentralized demand on Pocket
  • Monetize PATH ← We’re going to pivot here later this year

B2B/B2C sales of raw RPCs may no longer be viable for us, and that’s OK, because we’re an R&D shop. Our goal was to prove we could build a protocol like Pocket and that people would pay for the service on top of Pocket. We’ve proven both and now it’s time to mature the whole network to make the protocol viable.

We’re not going to give up the RPC business. We’re going to raise our prices for our paid tier and add the ability to pay us in POKT (these are hypothetical):

  • $5/mil requests (if you pay in USD)
  • $4/mil requests (if you pay Grove in POKT)

Doing it this way will give customers the opportunity to add buy pressure on the open market. It will also push Grove to sell PATH. This will include building ancillary features that we need to build for PATH, such as staking POKT automatically on an application-level basis, POKT-based payment processing and others needed by users.

In the event we lose relays, the Foundation is working on a staking program with node runners to make sure the stability gained with F-Chain subsidies and previous RTTM changes continues to keep the network stabilized.

Finally, we believe we’ll be able to justify this price increase because PATH guarantees Enterprise-grade Quality of Service on top of Pocket Network. We’re proud to share preliminary data showing that PATH’s QoS is on-par, if not better than, centralized, vertically integrated RPC providers. Below is an example of a load test on PATH through Shannon - latencies are REALLY low.

With the quarterly refund, raising prices, and our work on lowering our infra costs that we had slated for this month and next, we believe we should still be able to hit profitability on the RPC business this year given a bunch of other changes we made in the first quarter of this year.

4 Likes

There are some items for which I would like to get further clarification before I feel prepared to comment:

  • Can you please clarify and cleanup the proposal with respect to consistent and uniform usage of parameter names; this will help me and others to understand and ask directed questions regarding the proposal. I assume there is a missing vector parameter name something akin to “RTCUM” (Relay to CU Multiplier) that is a function of chain ID and that this is what is meant to baseline to 495 (rather than an implied 2850 if doing a 1:1 porting of values from Morse), eg:
    ** MORSE: mint_chainID = relay_chainID * RTTM(chain_ID)
    **SHANNON: mint_chainID = relay_chainID * RTCUM(chian_ID) * CUTTM

  • Please clarify the timescale and trigger for adjusting CUTTM and the array that, as a placeholder, I am refering to as “RTCUM(chain_ID)”. I think I understand you to say the following, but want to make sure before I comment further:
    ** CUTTM would be initially set to 66667 (implying a current POKT price of ~ $0.015) and adjusted “regularly” (what time scale?) to maintain near-parity of 1 CU ~= 1 E(-9) USD
    **Evolution of base (smallest) value of “RTCUM” (proposed initially to be 495) is TBD. The proposal is silent on this point, and is an important considerations for Shannon tokenomics. Please provide guidance. Eg, keeping it fixed versus systematically ratcheting it down over time may have implications on the potential price trajectory of POKT in the marketplace.
    ** Regarding the relative values of RTCUM amongst the different chains, I read the proposal to say that this would remain fixed to Shannon-initial values for the foreseeable future and the trigger for reconsideration would be if/when something arises to make it a high-enough priority item to warrant DAO attention. Is this reading of the proposal correct?

  • Re: " to enable this there is no other mechanism than to set the total minting equal to the application burning". Can you please clarify this statement. Are you saying that the code actually does not allow for mint>burn or simply that mint=burn is the only sound policy? If the former, is it true only on the aggregate over all chains or is it coded to be fixed mint-burn on a per-chain basis? (In other words, can we “overmint” on some chains as long as this is counterbalanced by underminting on other chains such that mint=burn in the aggregate…) Can you please dm me (or place here) a link to the relevant area of the code; I would like to understand this functionality better?

  • Re: "if the DAO decides it is necessary, it can increase the total supply by using the reimbursement event in the Shannon protocol. ",Under what conditions might the DAO decide it is necessary? Again, I would much appreciate if you could dm me or place here a link for the relevant section of the code.

  • Re: “The Minimum Stake per Servicer will be increased from 15,000 POKT to 60,000 POKT”, can you please clarify the number of chains a servicer will be allowed to service upon staking 60 kPOKT. Nine? One? Unlimited? This is an important consideration in deciding if 60kPOKT is an appropriate number or not.

  • Re: " Owners : From 0% to 3 % (DAO will be the initial recipient of all owner rewards)" Is this actor synonymous with what previously was called “Fisherman” ? If not, can you specify what role this actor plays

Hi @msa6867 I will get this responses if you (and @PocketFoundation ) don’t mind.
I cannot edit the main post, but I added a TODO for PNF, but not much editing is needed I think.

Is it possible to think of such a parameter (RTCUM) as part of the transition from Morse to Shannon. However such parameter does not exist. In Shannon the minting is calculated as:
mint_chainID = cus_chainID * CUTTM
(see this section of the code)

The parameter you mention, RTCUM(chian_ID), could be something like the compute_units_per_relay parameter (see the code here). This is set on Service creation. and is the content of the column POKT Network CUs in the second table of the “Blockchain Relays Competitors” section.
This wont be controlled by the PNF, except during migration and the bulk creation of the services. Later this parameter will be set by permissionles entities that wish to add new data sources to the network.

The example you mention, the baseline of 495 is just a transitory value, emerging for the average values of the services’ compute_units_per_relay. As opposed to Morse, where this value was the base RTTM, there is not such thing in Shannon.

In conclusion, speaking of a RTCUM will bring confusion I think.

(TODO @PocketFoundation : Add clarification of this)
The CUTTM will be adjusted at least weekly, but there should be constant watch on abrupt price changes that trigger imidiate updates . PNF migh even create software to alert and propose changes to the signature holders.

As explained before, the RTCUM(chain_ID) does not exist as a DAO controllable parameter. The values that this parameter refers to are the compute_units_per_relay of each service (chain_ID), they will only be set once, during the migration. After that, changing them can take the shape of creating a new service or the owner of the service deciding to edit them (if the owner is the DAO, then a proposal will take place).

Weekly or less if the price volatility is high.

This will be variable (due to being permissionless) and based on the free-market dynamic that we hope to create in Shannon.

Yes, provided that the RTCUM is the same as compute_units_per_relay, this will be treated like this for DAO-owned services.

For the sake of clarity I will repeat that as new services can be added in Shannon in a permissionless fashion new compute_units_per_relay (RTCUM) will appear at arbitrary values that make sense for the service’s data types (blockchain, singal, llms, diffusion models, etc…).

The network allow for mint>burn, the DAO wont enable it. And yes, we believe that mint=burn` is the best choice in the short-mid term.

The overmint mechanism mint>burn is global, meaning that affects all services (chains). As I understand, not 100% sure, there is no per-service modulation of the global mint module (this is the relevant code).

In any case, even if such mechanism would be possible it results in self-dealing problems. That is why the only incentive mechanisms that we see fit are rebates controlled by the DAO and we clarify that any supply growth that might be added in the future will be in favor of the DAO treasury and not a permissionless entity. This ensures that there is accounting on the recipients of inflationary mechanisms.

The conditions are not set, it is monetary policy. Given that the amount of liquid POKT now effectively limits the amount of total CUs that the network can process, the scarcity of the token might become an issue if the token price surges and the network has a high usage. Under such conditions the DAO might decide to create more tokens to provide lends at low rates to foster activity growth. This is a basic mechanism to avoid money scarcity to affect the economy.
In any case, supply growth wont be done in the near-medium term, and if it is enabled it will be low (less than 2.5%). But this is not happening in the foreseeable future and it was not taken into account in any of the treasury runway calculations.

The relevant area of code is the same as the former, but the tlmGlobalMint parameters would be set to 0% for all actors (supplier, proposer, service). I’m not 100% sure on the mechanics, but these parameters are set on the TLM module and retrieved here, and minted to the DAO here.

Any parameter not mentioned in the proposal will remain as it is today. The number of chains will remain in 8 per node, just like in Morse.

The minimum stake per node was not chosen due to its correctness, it is simply the path of least resistance to migrate from Morse to Shannon. If you want to discuss minimum stake in the Shannon era please create a different thread/proposal. Personally I think it might be to high, and I also want to change it, but it wont happen until the migration is done.

No, the “Owners” are the creators of the services (chains).
In Shannon the services are created via an on-chain transaction that fixes the parameters of the service (like the compute_units_per_relay), the ID and a description. The address that signs this transaction becomes the owner of the service. As proposed by Shane (if I recall correctly), we added rewards for the owners, because we want to promote the settlement of new, innovative, data sources in the Pocket Network. If you create a service and it attracts a lot of traffic the network will reward you.

The “Fisherman” role does not exist in Shannon, that feature is not included in the initial version of the network.

Thank you @RawthiL ; this is very helpful. I’ll be out of town tomorrow, so I will digest everything and comment on Thursday.

In the meantime, I have seen @ArtSabintsev response indicating Grove’s commitment to this framework, but I have not seen any other gateway or node runner comment similarly. I am sure you guys have had conversations with multiple suppliers leading into this proposal such that you feel confident that enough suppliers are committed to this process that we are not in danger of either dropping coverage/QoS due to insufficient nodes and/or dropping a path forward of demand growth from lack of demand aggregators selling the network.

Without breaking confidentiality, can you please provide some summary feedback you have received in your private discussions that can give assurance to investors that the business case closes in dropping all inflationary incentives at this time?

I ask because on the surface there seems to be a factor of 5 or so disconnect between what demand aggregators can charge while growing their client base and what network suppliers need to be paid in order to maintain needed QoS without being underwater

The following is my reading of this proposal. Please correct if I am missing anything or understand the proposal incorrectly.

  1. The initial setting of the tokens per average relay, ie, the product of CUTTM and the average value of compute_units_per_relay (proposal: ~ 158 uPOKT, down by a factor of ~5.7 from the current de facto Morse value of ~ 915 and down by a factor of ~2.4 from the intended value under ARR of ~370)
  2. The evolution of CUTTM, treating, for the sake of this proposal, the average value of compute_units_per_relay to be fixed after initial setting (proposal: set through ~weekly update to maintain approximate parity 1 GCU ~= 1 USD vs the Morse strategy of keeping it fixed)
  3. The manner and amount of DAO rebates for bootstrapping (proposal: 0-40% demand-side rebate vs Morse ~100% demand-side subsidies; proposal part 2: no supply-side rebates, but continuation of programs already in place in Morse to ensure adequate coverage/QoS on PNF-sponsored services)
  4. The distribution of mint from burn (proposal: same, initially as Morse mint distribution until non-PNF owners turn on and claim up to 3% of the distribution
  5. The amount and distribution of global mint (inflation) (proposal: initially set to 0 with the understanding that if it is ever set to nonzero, 100% of the distribution would go to the DAO.

My top-level feedback: The DAO treasury is woefully unprepared for the task at hand if this proposal were to be implemented as is. PNF must rethink its strategy for riding though what could be long period ahead before the network has the economy of scale to bridge the considerable gap between what the demand side is willing to pay and what the supply side needs to be sufficiently cash-flow positive to continue providing service.

When ARR was being debated I warned that passing ARR would likely lead to DAO shortfalls for meeting its funding obligations and steps should be taken in tandem with ARR to ensure adequate DAO treasury. I repeat the same warning here. The problem is not the 0-40% demand-side rebate for high-volume gateways (those numbers seem ballpark reasonable). The problem is the reserves the DAO should be holding to prop up coverage and QoS on sponsored services in the event of service-provider attrition (which I believe has a high probability of occurring if there is not discernable roadmap for service providers to achieve profitability).

The problem is not current profitability, or lack thereof. A business (aka node runner) can sustain long spells of loss if the hope for eventual profitability outweighs the current loss. This is the case under current tokenomics. While a node runner may be operating at a loss at $0.01 POKT and current mint rates, a rise of POKT price to $.10 or beyond can turn that loss into being profitable, and handsomely at that.

In the proposed tokenomics, however, the pegging of CU to USD eliminates a node runner who is currently under water from ever benefiting from POKT price increase. If POKT jumps from $0.01 to $0.1, his daily mint rate gets cut by a factor of 10. If he cannot achieve profitability at $0.01, then neither will he even if POKT reaches $3.

The only thing the node runner has left to rely on as a path to profitability is utilization/economy of scale. In the long term, the hope is that demand will grow sufficient to maintain a robust and diverse network of providers, but we are in a very depressed macro environment and movement to the promised ~10B level of relays/day may yet be years away. In the short term, it becomes a matter of playing a game of chicken with other node runners to see who will exit the ecosystem first.

As long as exiting service providers cause a rise of payout for those remaining sufficient to motivate them to remain such that needed QoS is maintained, all is well. It’s a natural feedback loop that is part of the ecosystem causing service to expand as demand expands and shrink when demand shrinks. The crux of the problem, as I see it, however, is that the drop in mint rate is so severe that the resulting attrition is likely to cause supply-side QoS problems that will need to be shored up by DAO spends.

It is my recommendation to not use the upcoming the major software upgrade as the occasion to introduce a radically new tokenomics paradigm. The proposal may be fitting for a program entering into maturity. We are far from entering maturity phase. The successful rollout of a major software upgrade does not magically cause Pocket to enter into maturing, anymore than Uber trying to force demand-supply parity when they are still a factor of 5x away from each other just because it introduced a software upgrade to its app. To me, it is wiser to go into Shannon providing closer continuity to current tokenomics, pull out all the stops on PR and marketing, selling the hype of a successful Shannon migration, and then when the dust has settled from the Shannon migration and (hopefully) the token price is on more solid footing and there is some traction on the demand side, only then begin the radical implementation of “ripping the bandaid off.”

My counter proposal:

  1. day-one CUTTM = 66667 is as good a value as any, so keep that as proposed by the committee
  2. set the average value of compute_units_per_relay to ~6000 This is very middle-of-the road choice between the existing values and the committee proposal. Eg, it is a factor of 2.5x higher than the committee proposal and a factor of 2.3 lower than the existing value.
    Note that this value is a fair value for the demand side – it implies an average cost per million relays of $6 which by the committee’s own words is a 50% discount to average competitor on-demand pricing and is 10% cheaper than average competitor pre-paid pricing.
    Note that this value also is fair to the supply side, as it brings mint back down to intended ARR levels
  3. Set Global mint to ~2k POKT per block (a 2.5x reduction of current inflation rate and a 10% reduction from intended ARR inflation rates. It could possibly be set even lower). Distribute this 100% to DAO for reasons outlined by the committee. It seems to me better to go into Shannon conservatively and overbuild a treasury than to advertise to the world that POKT has achieved mint=burn only to have to back-pedal later because the DAO treasury is being depleted trying to keep the bootstrap going. That could get messy from a PR perspective.
  4. Revamp the demand-side rebate scheme to account for the higher network burn rate (eg up the maximum rebate from 40% to 75% - this gives roughly the same net price to the gateway. 0.6 x $2.50 = $1.50 = 0.25 x $6.00) .
    Note that, as pointed out by @cryptocorn, the proposed rebate scheme needs to be revamped anyway as it too heavily favors the incumbent(s), thus making it an uninviting space to attract new gateways. With the above DAO funding, there will be sufficient funds to bump up the rebate from 40% to 75% and to expand the program to aid new gateways in addition to established gateways.

A completely separate topic that needs discussion is the handling of CUTTM after its initial setting. There are a number of strategies that are worth looking at that are beyond the scope of this reply. I’m still putting thought into this. But a quick summary of what is on my mind: too tight a pegging of CU to USD may cause instability in POKT price; I’d rather see sustained steady growth in POKT price than wild swings one direction and the other. Keeping the peg a bit sticky – as in no more than once a week, using trailing averages etc, may provide enough negative feedback to dampen too big of swings. Also, it is worth considering other strategies than pegging to USD, such as thinking of CUTTM as being formed from the product of two factors – the peg to the dollar and a coefficient that might start life as 1.00 and decrease over time. This can be useful, if for no other reason, than to keep up with Moore’s Law, but may (?) be useful to put a bit of upward pressure on POKT price over time (TBD).

1 Like

Your biggest concerns seem to be around the assumption that F-Chains (the DAO subsidized long tail chain support) program will continue as is. It will not. It is being replaced with a significant staking program which does not cost the DAO treasury monthly. The life cycle of the DAO treasury accounts for this in Ramiro’s math.

1 Like

I will try to answer this by parts

Yes, but for the record ARR was discontinued after Michael changed the tokenomics strategy.

Not sure if I understand this correctly but:

  • average compute_units_per_relay is going to be set once upon Shannon migration.
  • Value of CUTTM, 1 GCU ~= 1 USD, is going to be updated weekly or more often if necessary (conditions TBD).

The second part of this point: “… but continuation of programs already in place in Morse to ensure adequate coverage/QoS on PNF-sponsored services”, is not mentioned.
I do not know how the PNF will use the budget they have assigned, in the simulations it is set to a fixed level. However, as @Jinx mentioned, the current program is being replaced.


On the bulk of the reply

I agree that it is a bold move to push too hard into maturity:

  • At this volume levels, the current traffic is far from whats needed to keep current node runners’ income.
  • The gap between the current network supply minting and what we have observed that the demand is willing to pay is too large.
  • Pegging the CUTT to the USD means that there is no more speculative mechanism on the POKT price for node runners, what they earn depends solely on traffic.
  • A software upgrade is uncorrelated to changes in economic landscape for POKT.

All this was taken into account in the design of the proposal. I also advocated for higher prices for supply, even the first simulation I did was using an average price similar to what you are proposing. However it is not realistic to go trough with it.

In what you are proposing I see token price speculation as the main driver of stability:

  • High rewards not tied to proportional burn.
  • Higher rebates, resulting in:
    • Supply increase to fund DAO treasury.
    • More liquid tokens (DAO treasury → node runners).
    • Fake traffic from gateways to meet quotas → Questioning of real network adoption.

I think that that mechanism is exhausted. We played that game since Morse inception, it was very successful during 2021-2022, but after the bear of 2022 it was impossible to revive. Any effort we did to create new enthusiasm in the network failed and was expensive. Marketing is more expensive than coders (for my short experience with the price tags I saw) and result in ephemeral pumps. It is also worth noting that the only pump we had in 2023 was due to a tech partnership (Infura) and was terminated by a speculative movement (Upbit listing). What the Grove team did by betting on hard tech and real value generation with market integration was vaporized when the speculative crypto kids saw a new exchange to use as exit liquidity.
I, personally, had enough of these plays, speculation is over, if you were early into Pocket and minted a lot, congratulations, now it is time to hold. While mint=burn wont mean the end of speculative behavior it means the end of printing. This is like a resource war, if the speculative side do not have new tokens to dump then, at some point, it will no longer hurt the protocol.

While the Shannon upgrade wont by itself fix anything, it is an important milestone that we can use to start from scratch and re-launch Pocket. I think that we can use this opportunity to re-position as a bullshit-free network, simple to understand:

  • No free lunch.
  • Any minted coin is undoubtedly associated with real work.
  • Fake traffic makes no sense economically.
  • The PNF don’t care who you are, what data source you stake, supply or consume. Just pay the fees.

Node runners and Gateways Feedback

I just want to encourage all players to join this discussion. So far we only had Groove to respond. We had talks with other parties, and we keep on being open to calls, but at the end of the day the only way we shape the Shannon tokenomics is by public consensus.

2 Likes

I could not agree more with the body of this reply.

@Jinx , Thanks for the reply. No, I am not referring to F-chains, though I would be grateful if you could provide a link discussing the “significant staking program” that replaces F-chains so I can familiarize myself with this aspect of Shannon. I trust that what is foreseen has adequately been accounted for in the DAO budget.

The concern is not for long-tail chains but a breakdown of the network altogether. Using again the Uber analogy, it is the concern of what happens if driver compensation drops below the cost of gasoline in an effort to severely undercut taxi fares. The whole network of Uber drivers would fall apart. I’m not saying that this necessarily follows for POKT, as I don’t know the fundamental cost structure of node runners, just that this is the risk I am considering.

Let me digest @RawthiL response before continuing. In the meantime, feedback to by my first question/request would go a long way toward answering my concerns:

In other words: do a sufficient quorum of node runners (1) understand that under this proposal compensation drops to as low as $0.5 per Mrelay and average of $2.5 per Mrelays and does not increase or decrease with POKT price and (2) give commitment to provide node-running service in the ecosystem for the foreseeable future given this compensation structure.

Thanks @RawthiL for the detailed response. I understand the essence of the response, though I question a couple specifics:

I think you menat DAO treasury → gateways? There is nothing in what I proposed that has DAO treasury → node runners

I proposed 75% rebate rather than 40% rebate to registered gateways… In what sense does the increases from 40% to 75% suddenly open the floodgates to fake traffic. If the rebates are structured correctly, it will always be economically disadvantageous to introduced fake traffic, no matter if the rebate is 40% or 75%. Conversely, done incorrectly, a rebate can encourage fake traffic whether 40% or 75% rebate. (Currently, it is structured incorrectly so that fake traffic may be encouraged, but that is an easy enough fix and is a secondary concern.)

It’s not like I am proposing a continuation of outsized payouts to node runners. My proposed values are extremely competitive for the on-demand marketplace so that your last 4 guiding principles are preserved. If it were only for on-demand, there would be no need for inflation with my numbers. It is the desire to grow the pre-paid B2B market share that is the sticking point. In my counterproposal, I suggested ~4.5% inflation to fund the day-1 increase of gateway rebate from approx $1 per Mrelay to approx $4.5 per Mrelay. That level of inflation may be unnecessarily high. Perhaps half that amount of inflation is sufficient; I haven’t run the numbers yet.

Technical question: back in the day, the vision for Shannon included permissioned gateways as network actors, such that a volume discount in burn rate could be given to the gateways compared to on-demand burn rates. Did all that disappear?

Technical question 2. Can private services be set up? Can multiple services for the same chain be set up? E.g., can a public Bitcoin RPC service be set up with a burn rate of ~$1.67 per Mrelay and a private one be also be set up that can only be utilized by gateways registered with the DAO with a burn rate ~$0.67… that may be a solution to bridge the gap between what constitutes competitive on-demand pricing and what constitutes competitive B2B pricing.

If you’re not talking about the F-Chains replacement, then what leads you to believe the treasury is “woefully unprepared” when there is literally a chart showing the total burn? I’m not following your logic. Your suggestion to increase the rebate amount to 75% would present a far greater risk to the DAO treasury than the plan outlined here.

Yes, we talked to the existing gateways and they’re prepared for the burn. Like Grove, they’re factoring it into their decisions around what chains they deploy and how, but none considered it unreasonable.

I’ve also talked to a number of other ecosystem participants, and the economics of the network are the most important factor given that many of have stockpiled POKT. Several noderunners I talked to have never sold a single token. A multiple in token value from here driven by the stronger tokenomics that investors want to see will provide a far greater return for most.

Thanks; this is exactly the type of feedback I was looking for.

In answer to your question, and at risk of repeating myself, the unpreparedness I spoke of was to answer the potential risk of a mass exodus of node runners leaving the ecosystem leaving the network vulnerable to being unable to provide basic coverage and QoS, leading to the need to reverse course and increase mint . I agree my suggestion to increase rebate to 75% of $6 per Mrelay is a non-starter in a zero inflation system; that is why I had proposed it being funded through nominal inflation (~4% or less) Mine was a suggestion to go into the Software upgrade with some inflation which we could then reduce or bring to zero in a later step versus risking being too aggressive and then needing to backpedal later.

Setting all this aside, however, and shifting gears to supposing that the basic structure that the committee has outlined in this proposal gets implemented, I have some additional , secondary comments/questions/suggestions :

  1. I find the following argument presented in the proposal to be somewhat weak:

While this may be true over short time scales, in the medium to long term, DAO allocation is as liquid as any other allocation.

My thinking is that if you are going to go through the trouble of this drastic a change to the tokenomics, why not go the extra 1% to turn on net burn from day one by carving out 1 % of the mint to go to the burn address. Distrubution to one of the other actors would have to be adjusted according, either servicers from 78 to 77 (~1% reducitodn) or validators from 14 to 13 (7% reduction) or at start of Shannon and until owner allocation kicks in, reduce the DAO allocation from 8 to 7 (12% reduction)

If marketing is the most expensive DAO spend, as indicated by @RawthiL , then it seems that going this last extra bit would be well worth the cost (reduction to some other actor) by creating and controlling a very compelling PR and marketing narrative that indeed POKT burned > POKT minted. And it makes the case more compelling why existing investors should stay invested and new investors should invest, and why token consumers (demand actors) should stockpile tokens now rather than purchase just-in-time. All of this can lead to greater upward price pressure, just for the cost of that extra 1%.

  1. Seeing that POKT price is about 30% lower than when the proposal was drafted, is there plan to adjust initial CUTTM accordingly (e.g., CUTTM= 100000) or is the proposed 66667 initial value fixed?

  2. Re choosing the correct relative values of compute units per relay among the various chains: IIn most compute-unit based systems, the CU for various types of service is calculated based on actual cost of service, given some combination of processing, memory, storage and bandwidth utilization. I believe you indicated this approach is impractical to use for POKT, given lack of insight into proprietary node runner data, and that the plan is go into Shannon carrying over Morse relative values, simply for the sake of continuity if for no other reason. Do I understand that correctly?

Further, my understanding is that Morse values, while possibly being informed by some top-level guessing as to actual relative cost of servicing a relay are more a reflection of the DAOs desire to incentivize coverage for a particular service; is this understanding correct?

Have you considered other strategies for setting the relative values, such as one derived from and mirrors demand-side competitive analysis? Eg.,. set the value relatively higher where lowest-cost competitor is high or for which no competitor provides coverage and set it lower for where lowest-cost competitor is low.

Note that I am not suggesting this is a better approach; I just want to get an idea of what was considered and rejected vs what was not even considered yet.

This is the lowest risk factor in the analysis around this decision. An exit of service providers results in the growth of relays and rewards for the remaining providers, until an equilibrium is reached again which is satisfactory to the remaining providers. The current relay volume could be easily handled by far fewer staked supply nodes, so there is significant room to move here.

The original economics whitepaper and strategies outlined this mechanism as a real time response to supply and demand. Nodes unstaking around rewards not being adequate to incentivize stake is what is supposed to happen. The fixed reward emission strategy which was a transitional approach to reducing inflation created an artificial cycle which disconnected node rewards from actual work being done, and returning to the original economic model as designed restores that mechanism.

An inflation higher than what is outlined is simply a non-starter for investors and exchanges at this point. Investors have pulled cash out of Pocket because of the dilution of continued emissions with no correlating increase in market buy pressure. Exchanges are wary of listing Pocket (or of continuing to list Pocket, as the case may be) when the supply continues to grow while the total USD value of trading volume continues to decrease. The single greatest risk to Pocket is not a lack of nodes on the supply side, it is the complete collapse of the token trading market.

The total supply of the token value continuing to grow with a lesser total market cap means noderunners make less anyways.

Any calculation which ignores this fact, easily observable over the last two years, is an exercise in mathematics which ignores the realities facing the project. Without incoming capital speculating on the growth of the token value, Pocket will not survive, no matter what justifications are used for the economic decisions. And without a mechanism which effectively caps supply and creates an enforceable market demand for token buying, investors have made clear they are not interested in the project. They have made this clear in both words and actions, and our price reflects that.

It is due to this fact that both gateways and noderunners understand the need for the changes outlined above. The tokens they hold are worthless if the market goes to zero.

1 Like

Thanks @msa6867 for going deep into details, I can see that you understand the details of whats being proposed. Let me answer some particular points and then go back to the core of this issue, pricing.

actually DAO treasury → gateways → node runners, because the final recipient are the node runners. There is a 90 days buffer where gateways will need to use their tokens, but after that is the DAO treasury that refunds the gateways, witch will continue to burn to allow higher minting to node runners.

It all depends on where you set the initial threshold and rebate value. We selected 100 M relays a day for a 10% rebate, if you keep this, I agree that the expected “fake” traffic is the same. However, we chose a particularly high base level, only Nodies and Groove will have rebates, and none will reach the 40% rebate. If you wanted to effectivelly implement a 75% rebate on all traffic, this will probably need to change, setting a lower base amounf relays (less than 100 M/day) or higher initial rebate (higher than 10%). So, this will probably encourage gateways to meet traffic quotas, but we are not sure, as you say, it might not.

I don’t know why you say that, after meeting the initial number of relays (100 M/day) the cost for a gateway increases monotonically, fake relays make no economic sense (see the figure).
As I mentioned before, there is only economic incentive to reach the first mark of 100M/day, but as it can be seen in the image (small discontinuity at 0.1 B relays/day), the amount of relays that are “encouraged to be fake” is 10% of the base, meaning 10 M relays/day per gateways wishing to meet the quota.

Gateways ended being a permissionless actor, since they are a key innovation. They allow to use ring signatures which can become a very interesting building block for some applications. Keeping them as permissioned entities does not feel right.
The rebates mechanism, proposed here, is the off-chain version of that concept.

Yes and yes.

No, all services are permissionless and the minting mechanics are fixed. We cannot have different minting mechanics (like mint > burn) for some services.
What can happen, and we expect to happen, is that some services could appear with different price tags, like “Bitcoin” and “Bitcoin but cheaper”, that’s part of the free-market that Shannon enables. Which service prevails over others will depends on supply and demand mechanics only.

Correct, the liquidity attrition is only temporary, that’s why the rebate mechanisms are set to be paid every quarter, to press the liquidity as hard as possible.

This was also on the table, while we could implement this, it means more pressure on the supply side. I would not mind to go that way if everyone is aligned and willing to support the little extra effort to show a supply reduction in the charts.
I’m very open to hear other voices and the change wont affect much the numbers we present (as we concentrate on demand which will be unaffected).

Just to clarify, my knowledge on how PNF uses its budget is very limited and I don’t have insights on how much budget is used for marketing in the Shannon projections.
My take on this comes from the cost of the mediocre Messary coverage and some numbers on the cost of other campaigns, mentioned in the chats or community calls. So, I can be way off…

Yes, the value of the CUTTM in nPOKT will be different, depending on the price of POKT at the Shannon transition day. It will be set to reflect a val;ue of 1 USD = 1 B CUs.

and

The relative values of the services in Shannon are indeed transitioned from the Morse per-chain RTTMs. However, the Morse values (and by extension the Shannon values) do not come from a desire to incentivize a given chain, they come from the relative hardware cost of each chain. When the current F-chains were deployed, Groove conducted a sort of auction to bootstrap these chains, during this auction the node runners informed their costs to deploy and maintain some chains and Groove selected the lowest price tag for each chain. We use that information to set the relative RTTMs in Morse. While this might not be perfect, we have some confidence in the relative costs of the services and they are not arbitrary.

It is difficult to conciliate the advertised prices of the different actors (POKT gateways or centralized services) and what we know from hardware costs. Many business are willing to operate at loss on some chains and have very large margins on others, or selling additional services to recover.


General Answer

The issue with pricing is very difficult, and I dare to say it is impossible to solve by PNF.
(You will need to take my word for all this unless demand starts to post here)
The market for blockchain RPCs is brutal, there is no price for anything and clients jump around services continually. The cost they manage (USD per M relays) is much lower than what they charge, reaching values as low as 85c per million relays when you are in the bulk market (as POKT is).
If we match their advertised price, which is an average of ~6 USD (or ~14 USD for pay-as-you-go), there is no room for gateways’ business.
The feedback we had from the demand side (most of it after publishing this), was mixed, they agree that the price tag of 2.5 USD/M seems reasonable but that it is even a little high. The edge we have in POKT is the long-tail of chains, those that are actually cheaper and have low volume. They do not seem very interested in running ethereum on POKT, they are more interested in smaller chains. Moreover, they could use POKT’s ethereum as fallback (even paying more than 2.5 USD/M) if they have the long tail of chains to consume.

What they are interested is in being able to profit from whats cheap on POKT, and pay what they need to pay if their infra goes down. Whats the price model that fits these needs? I don’t know, it will only be settled by the market itself.

Another thing that I learned from the blockchain RPC space, is that they want to be able to consume without issues, simple onboarding and integration and zero commitment. I think that Shannon has this, and PATH is the missing piece that the blockchain RPC market is needing. In the end I think it is not that much on how we set the prices initially, as long as they are in the ballpark for large RPC providers.

2 Likes

Of course I understand all this and have spoken many times of this primary corrective feedback loop within the ecosystem, including in this post just a couple days ago:

My main concern is my follow-up sentence in the above quote:

Now I will walk back the word “likely” in the above quote, because I do not have a good sense yet how to quantify the risk.

Your assessment is that

Words like “easily handled”, “far fewer” and “significant room” may be accurate qualitative descriptions, but the “devil is in the detail” of the quantitative numbers.

When Blade and I looked at this problem space a few years ago, we estimated that QoS starts to break down above about 80% utilization (since traffic is spikey not smooth).

Suppose the current environment for the “average” node runner is that for current RTTM, breakeven is around 10% utilization and they are operating at or near the breakeven point. In this case all is well, and the risk I outline above does not materialize. Implementing the proposed tokenomics outlined by the committee will cause breakeven to jump to around 57% utilization. Assuming a nonsticky ecosystem, dropping payout by a factor of 5.7x will cause about 80% of the current nodes to exit the ecosystem, raising actual utilization to around 57% and the remaining node runners are happy to stay around at breakeven points with hope of turning profitable as aggregate demand increases, pushing up utilization even further.

On the other hand, suppose the current environment for the “average” node runner is that for current RTTM, breakeven is around 20% utilization and they are operating at or near the breakeven point. In this case, implementing the proposed tokenomics pushes the breakeven point to the theoretical but impossible level of 115%; the risk I outline above materializes and the supply side is at risk of collapse due to the inability of a node runner to operate profitably ever under any circumstance. (What I referred to, by anaogy of Uber payout to drivers being under the cost of gasoline).

Both scenarios above qualify for the qualitative description of “far fewer” “easily handled” and “significant room to move”…, but in one the risk is averted, and in the other the risk materializes.

The feedback you provided earier is significant in assessing this risk:

If the sentiment of a “sufficient” quorum of node runners is to stay committed to the ecosystem for at least, say, the next year or two, on the strength of their warchest , even if the nodes are not technically profitable at 80% (or 100% utilization, then the risk I outline above is sufficiently mitigated. That is why in my last post I suggested to table further discussion on committee proposal of average $2.5 per Mrelay vs my counterproposal of $6 per Mrealy and switch gears to discussing further details of the committee proposal assuming the $2.5 per Mrelay values. I understand all the arguments already given in favor of making the drastic switch in tandem with Shannon rollout vs my more cautious approach of moving toward it in phases, and do not need further arguments in this regard.

I will digest and respond to @RawthiL feedback above late tonight

The winner-take-all rank ordering of disbursements from a limited purse can cause a gateway to submit fake traffic in order to leapfrog a competitor in the rankings

That is good news. I was a vocal opponent of permissioned network actors back in the day…

I am confused by this anwer. It seems to be answering something I did not ask…

THIS is what I was asking… except for this being coupled with the lower-priced service being private (meaning on the demand side, not the supply side) such that the general public could not submit on-demand RPC requests on the lower-priced service that was meant just for the gateway’s use. Obviously, the mint on the lower-price service would match the lower burn, and suppliers would make their choices of servicing a potentially low volume but higher priced service or the potentially high volume but lower priced service or both.

Agreed that the reasoning to limit rebates to quarterly is sound.

Do you mean more pressure on the supply side? Explain? In either case, I also would like to hear other voices on this topic. I for one think the extra bit would be worth it, carving the 1% of distribution from either servicer or validator (TBD as to which).

That is excellent and more than sufficient for going into Shannon.

Thanks for the great summary

Not much here, just to respond specifics:

You are right, happy to modify that mechanic if needed.

This is related to the later “bitcoin” and “bitcoin but cheaper” example.
Both services will be permissionless and behave exactly the same:

  • Anyone can stake apps/gateways and request relays
  • Anyone can stake nodes and provide service
  • They both follow the same minting logic of mint=burn (or mint<burn), which is a global parameter (not modifiable per-service)

My bad, it should read “more pressure on the supply side.”. As long we achieve that by reducing minting (no by increasing the burning) it wont affect the numbers of the proposal.