Burn And 🥩 Harnessing (BASH) Deflation Economic Model

shane · June 23, 2023, 11:54pm

UPDATE 1 - 6/25/2023 See logged changes here.
UPDATE 2 - 6/27/2023 See logged changes here.

Burn And Stake Harnessing (BASH) Deflation Economic Model

PNF recently submitted PUP-X: Accelerating the Road to Revenue (ARR) - #31 by JackALaing to provide a path to deflation and POKTScan released Mint Incentivizing Network Transformation (MINT) - #37 by RawthiL as an alternative approach.

I’m now submitting yet another to consider, built in part on the strengths of their works

Pros and Cons of ARR and MINT

ARR

Deflationary by 10B relays a day
Consistant USD cost per relay for gateways (very important)
Minimal direct buy pressure incentive
No staking incentive
Relay growth doesn’t expand node ecosystem
Doesn’t account for USD (too low of a price and the network begins fail)

MINT

Relay growth can expand node ecosystem
Can achieve deflation by 10B a day (with the right tweaking from my understanding)
Can account for POKT price (at least I believe so… but not entirely sure)
Minimal direct buy pressure incentive
No staking incentive
Raises cost per relay for gateways (could hinder gateway growth)

BASH

Now I’d like to introduce BASH, which clearly wins because it has more green

BASH

Deflationary by 10B relays a day
Relay growth can expand node ecosystem
Consistent USD cost per relay for gateways (very important)
Accounts for POKT price
Direct buy pressure incentive
Staking Incentive
Uses inflation to create deflation

CHECK OUT THE SPREADSHEET: Burn And Stake Harnessing v3 - Google Sheets

The Design

Structurally, it doesn’t look much different than what ARR offers, but with it has two unique components

Burn Supplement
Stake Ratio

Burn Supplement & Stake Ratio

The main difference with BASH is it creates an incentive for more POKT to be bought and staked on the network. It does this by having two requirements for gateways:

Gateway are required to burn an amount of POKT per relay they send through the network (AKA: Gateway Burn per Relay).
Gateways are to stake POKT to have their Gateway Burn reduced (AKA: Burn Supplement)

Burn Supplements - is a fund that is part the block rewards (like DAO, Validator, and Servicer rewards). No code changes are required on the network, as the Burn Supplement will actually just be part of the DAO’s cut and PNF will separate it for burning. If a gateway stakes their expected amount of POKT, the Burn Supplement will be used to supplement a percentage (AKA: Stake Ratio) of the Gateway Burn.

Stake Ratio - defines the amount of the Gateway Burn that the Burn Supplement will cover.

Example

In the image below you will see the Stake Ratio is set to 50% and the Gateway Burn per Relay is set to $0.00000170 (the two red arrows). This means that the Burn Supplement will cover 50% of the $0.00000170 Gateway Burn if they stake 50% of their Gateway Burn.

It is easy to see how this plays out with the highlighted PNI example on the right. PNI did 1.3B relays a day over the course of a month and is expect to burn $67,184 (in POKT obviously). However if PNI stakes 50% of the Expected Burn ($33,592), then Burn Supplement will cover 50% of the Expected Burn. This means that the end of the month PNI has:

Staked $33,592
Burned $33,592

However, looking at the network, the Burn Supplement covered 50% (or $33,592) of PNI’s Expected Burn, which you can see with the blue arrow. So technicaly, at the end of the month, the POKT Network has:

Staked $33,592
Burned $67,184 (PNI’s Burn + the Burn Supplement)

ARR Comparison

As an comparison, ARR has the Gateway Burn per Relay set to $0.00000085 which results in $33,592 being burned with 1.3B relays a day. With BASH, the network burned $33,592 of PNI’s existing tokens and $33,592 of tokens that were minted for the Burn Supplement. This means that both ARR and BASH burn $33,592 worth of existing tokens. The final results:

ARR End Result:

Burned $33,592 existing tokens

BASH End Result:

Burned $33,592 existing tokens
Staked $33,592 existing tokens

The result is BASH doubles the amount of existing tokens through burning and staking combined, resulting in double the potential effect on the buy market. This effect compounds as the network grows in relays. See the effect if the network hits 10B relays a day.

Under The Hood Effects

Deflationary

Above 10B relays a day, POKT would become deflationary. Play with the spreadsheet to see what the Annual Emissions Rate would be at different market conditions.

Accounts for POKT price

One of BASH’s main features is it anchored to a USD constant without producing waste. This is achieved by allowing the Gateway Burn per Relay (which is USD derived) to define how the rest of the parameters change.

In the case of POKT hitting 10B relays a day with a POKT price of $15c, ARR would crush the Servicer economy and produce significant overburn (Annual Emmisions Rate of -7.73%). BASH on the other hand, is able to maintain the Annual Emissions Rate goal of 0% (making POKT deflationary) but still maintaining a realistic node economy.

Node Ecosystem Growth

BASH also enables the Node Ecosystem to grow as relays grow once 10B relays a day is achieved, regardless of the POKT price. Prior to 10B relays a day, there are two options:

Adjust parameters to reduce node rewards now (takes some custom configuring)
Allow nodes rewards to decrease gradually until 10B relays

Both options are possible with BASH, but after 10B relays, POKT would continue to become more and more deflationary while also increasing node rewards and increasing the amount of burning and staking of existing POKT.

Direct Buy Pressure

In order for gateways to stake POKT, they will likely need to regularly purchased it, especially once relays pick up. It would make sense that revenue from customers could be used to purchase the POKT.

If customer revenue is buying the POKT, it would make sense for gateways to allow the POKT to be staked on behalf of their customer, providing bit of a POKT rebate for using their gateway services.

Example:

In the spreadsheet, I have included 3 customer examples.

App 1 would be charged $167 per month, but $26 of that would come back to them in the form of POKT being staked on their behalf, meaning the actual cost had a 15% savings. Allowing the app developers to own staked POKT would provide:

Great marketing opportunities (diferenciates POKT from other services
Allow app developers (who actively use POKT) to own staked in POKT (a real benefit leading up to v1)

NOTE: PNI already does something similar to this on their own, (I believe it is 60% of their customer payments to go towards POKT purchasing, though not sure if that has changed since the burn went into effect), but with it integrated into our economic model it will be more easily tracked, and more importantly, required for all future gateways.

If you think about it, app developers would make the perfect node staking clients. They are using the service and getting value from it directly without expecting significant POKT return rewards. The more app developers we can get to join the node economy through a mechanism like this, the more stable and healthy I believe the node economy will be.

Implementation

There is some solutioning that will be required to make this possible. Between POKTscan, PNF, and others in the community, I believe it can be done efficiently.

Monitoring/Tracking

Just like there are monitors for PNI’s weekly burning, there would also need a monitor to track the POKT being sent from gateways to stake. This ensures that everyone burning and staking as required by PNF to operate gateways.

Gateway Staking = DAO Staking

BASH requires gateways to stake POKT and there are a few ways it could be done, but the best way to me would through what I call DAO staking.

DAO Staking is where gateways must submit their POKT to be staked. Ultimately they are submitting it to PNF who is representing the DAO, but the idea is that it is being held by a third party, apart from the gateway. The DAO (via PNF) can commission node providers to stake the tokens on behalf of the gateway.

The rewards could go to the DAO, go the gateway, the app user, be burned, or just sit dormant. There are some options.

With the coming of wPOKT, this could actually be a very clean process where all gateway stakes are done via wPOKT. PNF would regularly take the wPOKT from the designated account and send it through the bridge and stake it on behalf of the gateway/user. Some custom development work would likely be needed to make this possible, but it could be a worthy endeavor as it would provide direct wPOKT utility and potential volume.

With the proper tooling it could be easy for gateways to submit wPOKT (or POKT if need be) for staking in a mostly automated fashion.

Transactions

Similar to SER, this model would require regular governance transactions by PNF. To account for it’s unique calculation, the following parameters would be regularly adjusted in accordance to the BASH model:

RTTM
DAO Block Reward
Validator Block Rewards
Servicer Block Rewards

V1 Potential?

The more I play with this model the more I feel that a continuous burn + staking requirement could be viable v1 mechanism. It allows the burn to be lower, while still providing token lockup.

Conclusion

This is either my economic magnum opus, or I have one variable wrong and it all falls apart I’d encourage anyone able to push the spreadsheet hard and verify that it is producing correct outcomes.

If it is all correct, then I believe this is a worth while economic plan to consider. I know that for me I feel this hits everything could hope for right now. GRIP is welcome to do their thing. I’m doing this as a pre-proposal because I need more economic eyes on this to know it works.

I will still continue playing with it and will let everyone know of any updates, but my brain is fried from the amount of hours I have put into this. Going to the beach tomorrow to heal

giphy

Credits

This is actually a combination of PNF and POKTScan proposals with a mix of PNI’s strategy of using customer revenue to purchase POKT. I was able to put them together with my own twist, but major kudos for the work they have all been producing on the economic front to make this possible. Open to any feedback

spenc · June 24, 2023, 12:07pm

I played with the spreadsheet and maybe I am missing some key aspects, but would this be still deflationary if the price keeps falling down? On the other hand it seems to work nicely if we consider market correction for $POKT, then it might not even require to have 10B relays to become deflationary.

Just out of curiosity - would it be possible to extend similar mechanism on service providers as well? For example introducing another adjustable parameter, so nodes that stake less than $x of POKT would be burning y% of their rewards, which means also node runners would be incentivised to re-stake on price drops.

SteveO · June 24, 2023, 5:50pm

BASH is well thought model, I like it very much.

Cryptocorn · June 25, 2023, 6:44pm

This is an interesting approach and it’ll be interesting to follow the discussion in the coming days.

A few questions:

Is there a staking minimum lock up period for Gateway staking? Or can they stake and then immediately unstake the POKT and rinse/repeat?
I assume Gateways can determine what Node-runner(s) they want to stake with and communicate with the DAO?
Turning the staking aspect into a marketing plan I would suggest caution with. PNI offered something similar with their PAYG model and the market didn’t react well to it. While the deals are indeed lucrative for the end customer, it introduces a new level of complexity that many just don’t want to deal with. Maybe a specific Gateway can offer a deal to those dApps that are happy to spend the time understanding Pocket and the benefits of holding etc, but if we are selling a commodity, simplicity is key imo.

I see the staking subsidy as an alternative way the DAO subsidizes Gateway fees, that I am in favour of during the Gateway bootstrapping phase. However in this case it comes with a caveat of additional staking needed by the Gateway.

shane · June 25, 2023, 8:06pm

This is why I suggest a 3rd party control the stake on half of the gateway. By using the DAO (and in extensions PNF) to manage the stake, the gateway does not have the ability to unstake until the proper time, which could be:

Some time or milestone after v1
After the gateway hits a relays per day milestone (say like 10B). This way the gateway is incentives to grow the relays they send to POKT. If they have alternative services that don’t use the POKT protocol, this provides incentives to favor the POKT protocol, because staked tokens will start to be unlocked.

If the DAO/PNF is the managing party of the stake, then the DAO/PNF decide what node runners, not the gateways.

I personally have never seen marketing around crediting POKT tokens to customers from PNI or from PNF. After doing some digging just now I found this:

To be fair, this does sound confusing because no one, even within the POKT ecosystem, knows how app staking will work in v1. There is no economic plan for v1 yet, so any messaging around “staking for relays” will be confusing and could even be inaccurate.

The messaging I’m talking about was shared in my post.

That is saying exactly how much they are saving each month through POKT crediting. It’s not confusing and straight forward. By stating that unstaking will only be available after a milestone, should be really straight forward as well.

Yes, it will still be deflationary with a lower POKT price. This is what happens when I set it to 1.5C.

It would only be practical if it was baked into v1, and I’m not sure that is a good mechanism for node runners in the first place. To do this Burn and Staking in v0, it requires an entity like PNF to send POKT from the Burn Supplement to the gateways… which there will only be a max of 3 in v0 most likely. If they had to do that for potentially hundreds of nodes… that would be chaos.

Not sure it is a good mechanism to have in the first place, but could be considered when v1 economic research is underway.

shane · June 25, 2023, 10:06pm

UPDATE 1

I added a new page called “Immediate Inflation Reduction”. This page has B23 modified to follow the path of ARR, where inflation never goes above 4.98%. If being sub 4.98% inflation is an immediate need, like ARR, the Immediate Inflation Reduction drops inflation immediately but has l the extra benefits and balance of the BASH system.

Both still hit deflation by 10B and scales indefinitely.

spenc · June 25, 2023, 11:19pm

I see I was thinking about this incorrectly (burning is redundant) as I actually didn’t mean to introduce another Burn Supplement for node runners, just burn part of rewards of those who’s stake is below certain USD value threshold. So node runners would be incentivised to re-stake during the price drops, otherwise their rewards would be simply reduced in order to match deflation rate.

I’ve mentioned this idea in this thread

Introduce a mechanism to gradually raise the average stake to $15k or 15000 POKT. Right now, we have 20700 nodes, 870M POKT staked, and 608M POKT liquid, averaging about $1600 per node. A new node costs $600 to stake and Lean Pocket reduced HW costs drastically, which ultimately means decreasing the token rarity.

Silly example: Let’s say the nodes agreed on a minimum $5000 stake. That would imply $103M worth of POKT staked, covering the entire token supply at a $0.07 price, eliminating all liquid POKT.

It may sound outlandish considering we can’t predict how many nodes would unstake or re-stake. But regardless of the outcome, the game theory principles apply. If half the nodes exited, the remaining would enjoy doubled rewards, drawing in new nodes.

shane · June 26, 2023, 5:46pm

Ah, I see what you mean.

I do not believe a mechanism like that would be possible in v0 for sure.

However, the concept of adding staking pressure on the node side is worth considering in the v1 economics. I’m not sure how feasible it would be to tie it to the price of POKT though. That would mean there would have to a serious oracle element baked into v1 that can determine price. Not sure how feasible it would be to achieve that.

It’s also important to note that I’m not sure any node staking requirements will result in significant consistent buy pressure, since nodes generate POKT. Any staking pressure on the node side would just encourage locking up POKT rewards they have already generated, most of the time.

Open to flushing out the concept under another v1 thread when it’s time

RawthiL · June 26, 2023, 7:43pm

Thanks @shane for creating all this. It is always interesting to see how the builders in our community imagine POKT economy.
Please take my comments as constructive feedback, you always tend to think that what I write is much more negative than it is

This will be quite long…

Some clarification on MINT flags:

Supply reduction before 10B is guaranteed unless the parameters are changed to continue bootstrapping after 10B relays. The same happens to this proposal if the parameters are changed. MINT should be green or BASH should be yellow.
If you believe that it can account for POKT price, why not green? It is easy to see in the spreadsheet and MINT playground.
The buy pressure incentive is lower in this proposal (in the long term), as the GFPR (named Gateway Burn Per Relay here) is only 2x the current one and we propose values that are higher than this. In the short term it would be higher (I think) but it is lower overall. Anyway, Im not even sure if the actual GFPR is 2x, but rather the same as before but we are only minting more…

General Notes

It is not clear to me why this proposal creates more buy pressure. As I understand it, it will double the RTTM to make room for the additional burn supplement. That additional minting will be staked for the gateway? not sure how this is working exactly…

It would be very helpful if you adjust the format to MINT and ARR. Specifically the sections. It is not easy to find how many parameters are required and how will they change with this proposal, it makes overall comparison harder to do.

You use Gateway Burn Per Relay (GBPR) instead Gateway Fee Per Relay (GFPR) a term that was created in the burn proposal. I would use the same name to avoid confusion. I understand that it has almost the same use.

Please try to avoid using “inflation/deflation” for supply growth/attrition. This can get very confusing when mixed with price drops (often also referred as “inflation” by the community).

Im not sure on the meaning of :

I understand that BASH is tied to the price of POKT through the GFPR that is one of the control variables of the proposed method. BASH was designed (“hardcoded”) to create supply attrition at 10 B relays by day. I don’t know why it is a weakness of ARR to produce attrition before this mark. There is nothing special around this number of relays.

The gateways stake seems will need that PNF is made responsible of all the stake on behalf of the portals, this has other complexities (legal ones I think)., maybe I’m wrong but people from the USA might have better understanding of this.

This is a valid point. The strategy seems similar to PNI with apps and it was not well understood/received (as far a s I know).
However I wont argue around this point, it all depends on how it is communicated.

Conclusions (I put them first so you can skip Greece)

The mechanism of staking may or may not create additional buy pressure, I’m not convinced that it would happen. After reading the explanation and going through the spreadsheets I’m still hesitant to say that it will create any buy pressure.

I think that the proposed method tries to create a simple curve in the supply growth chart, something understandable (linear), but it fails to take into account the effects of this linealization (complex USD incomes curves). I believe that the income curves are more important to kept simple than that of the supply growth, as investments rely on them.

The original model (“Deflation Focused”) is very sensitive to price changes in the low relays zone (actual state of the Pocket Network), resulting into high growth rates (~25%) at POKT prices of USD 0.015 and 1.2 B relays per day. For this reason I think it is not viable.

The introduced limiting of the supply growth (“Low Inflation Focused” mode) fixed the previous matter but introduced an explicit misalignment between ecosystem growth and servisers gains. Servicers earn more as the number of relays goes down and the price up, or (after 10B relays) the servicers earn less if the number of relay goes up and the price goes up. This is what we try to avoid in MINT. I think that we should all push to the same goal.

And finally (but not less important to me), the model relies in a series of operations that I fear that are not well defined (many hard-coded values without explanation). This results in difficulty to understand and tune the model and also in unforeseen effects (as shown previously).

Welcome to Greece…

I went through the provided spreadsheet and reconstructed the mathematical model that was created.

While the model make use of current division of rewards between DAO, validators and servicers:

S_DAO = 10%
S_Validators = 5%
S_Servicers = 85 %
They need to be modified in the blockchain. Their actual values now depend on a new parameter, the Burn Supplement:
S_Burn Sup = 50%
This parameter actually rules over the others, defining their in-chain values:
DAO share modification:
Validators share modification:
Servicers share modification:

The model is in fact driven by the total POKT burnt by month, which is calculated by means of:
imagen

This value is derived by projecting to months the number of daily relays (30.4 * R_{B by day}), multiplying by the GatewayBurnPerRelay (GBPR) and converted to POKT using delta (POKT price in USD).
The GBPR was set to twice the original GFPR, probably to make-up for the changes in the rewards divisions and to make room for the burn supplement:
GBPR = 2 GFPR = 0.0000017
The POKT price is delta = 0.031 (inverse of epsilon in MINT)

Using this amount of POKT to be burned by day the model proposes two ways of calculating the total POKT to be minted in a month:

The “Deflation Focused” mode:

imagen1032×132 8.52 KB

Here the POKT minting is tied to the POKT burned by month (function of the POKT price) and the number of relays if the number of daily relays is below 10 B. Once the threshold of 10 B relays is reached, the model changes and apply a linear function, controlled by the number of daily relays and with a floating bias controlled by the POKT price (the total burnt by month).

The “Low Inflation Focused” mode:

imagen1170×126 10.8 KB

Here the linear behavior of the POKT minted after the 10 B daily relays mark is kept constant, the change is introduced for the low relay counts.
With less than 10B daily relays, the model seeks to achieve 5% supply growth at approx. 0.1B relays and then decay linearly to (almost) zero in the 10B mark.
This mode also requires the monetary base at the time of implementing, which is:
M_B = 1626069.513

Both “modes” have a large number of parameters that are unaccounted in the proposal. They seem to be chosen to reach the described goals, but they are difficult to classify (functionally).

Once a given mode is selected, the model calculates the Relay To Token Multiplier (RTTM) that satisfy the conditions (similar to SER concept):
imagen

Then the earnings of each actor can be calculated as:

Burn Suplement Minting
Total to be minted by month for each Participant

Projections and Plots

In order to judge this model using the same tools as MINT, I created the same plots that were created for that proposal.

The “Deflation Focused” Mode

This mode has an evident weakness, that is that it creates a rapid supply increase rate in the current number of relays when the POKT price is 1/2 or lower than the current:

The fuchsia lines correspond to POKT prices of ~0.015 USD and ~0.009 USD respectively (the lower the price the higher the supply growth). The dashed blue lines ar higher POKT prices. The bold line is the current POKT price.
These supply growth rates are regarded as high by many (myself included).
For this reason the author created the second mode, which we will analyze further.

The “Low Inflation Focused” Mode

This mode introduced a modulation of the POKT to be minted that ensured a bounded supply growth.
The supply growth rates are now bounded and decaying linearly:

Note that now the POKT price changes do not affect the minting. This happens due to tying the mint to the POKT price in the total POKT minted by month calculation.
This is nice, however if we analyze the income of the servicers and gateways we see some unexpected behavior:

The servicers will actually earn more if the number of relays remain low and the price go up (dashed dark blue lines). This create total misalignment with the rest of the ecosystem.
If the ecosystem is above 10B daily relays, the servicers earn less if the prices goes up (dashed line, dark blue).
There is a big discontinuity at 10B daly relays, which is larger when the POKT price is larger. This discontinuity is too big, 9.99999 B relays and 10 B relays are almost the same but they have large earning difference (I suspect that this is due to a hardcoded 0.1 around there).
If the number of relays is below, the servicers earn more if the price goes up, and this is boosted in lower number of relays.
Moreover, today the servicers earn ~2K USD per day, that amount wont be reached until ~11 B daily relays.
Finally, the servicers income grows lineally and much faster than the rest of the ecosystem actors (DAO, servicers and validators).

Model Code:

All the python code in a Colab

shane · June 26, 2023, 11:32pm

Very much appreciate the feedback @RawthiL. I’ll try and address each point

I have to admit, I don’t understand how everything is working with MINT, so my apologies if I misunderstand something I’m more of a dynamic spreadsheet guy, where I can try and follow how everything works under the hood… which you are more of a python guy. While it has a price input, it doesn’t seem to balance other parameters automatically from what I can tell. It take a lot of manual changes to account for price, which I’m not sure how to do (hence the yellow). With BASH, changing the price updates all parameters accordingly and maintains the best balance possible (which is what I meant with green).

Right now for MINT, I would just be trusting that others understand how it works, which is why I wanted to see if I can take parts of your model and make it into something that I do fully understand. However it doesn’t produce workable outcomes when I use the spreadsheet, so I’m just going on what the spreadsheet shows.

Yeah, they are the same thing, but I found when trying to explain BASH in my post, I’m constantly having to switch between saying “burn” and “fee”, which can be confusing for some folks. So to make everything clear I just stuck to only using one term, which was burn since that is what it is.

By requiring gateways to burn and stake it doubles the amount of POKT they have have each month, when compared to ARR, as I explained in this section. Requiring more POKT per month fundamentally would effect buy pressure. At 10B relays gateways would need to have 19M POKT in hand each month… which no gateway will have for more than 1 month, even if they have a staking business.

For me, it is safe to say 19M would create significantly more buy pressure than 8.5M.

This is a fundamental flaw with MINT right now. As I mentioned in my comment before, the MINT model doesn’t work for gateways at all.

MINT does get to 0% Annual Emissions Rate at 10B relays, but at a GFPR that is completely impossible for gateways IMO. The cost per relay is almost as much as what PNI charges customers. It would make sense for gateways to use their own hardware (or even ANKR) instead of the POKT protocol.

Every other RPC market is designed where if you bring more relays, you get a discount. MINT proposes the opposite that if you (or some other gateway) brings more relays, each relay gets more expensive. For me that concept itself is a no go.

Relays need to stay at $.00000085 to be competitive to running off of your own infra. POKT’s economic model needs to take the game theory of gateways into account, and BASH and ARR are designed to do that.

For contrast, this is BASH with 10B relays and 20B relays while still being deflationary, grown node rewards, requiring double the buy pressure, and consistent (and reasonable) USD costs for gateways.

Wow… this section makes me look really smart! I’ve never seen one of my spreadsheets “in the greek”

Seriously, great job breaking it down the mathematics. Though I may get lost in it, it is great to know that someone is really breaking things down.

Where are you seeing large discrepancies or large earning differences between 9.99999B relays and 10B relays? Please show screenshots, because that is not what is in the model from what I can see.

From what I can see, BASH perfectly hits it’s goals without any radical changes, regardless of where POKT price or relays go. Please show screenshots of the spreadsheet because I believe your python scripts are wrong.

Yep, the whole thing is hard coded to hit specific goals. I went into it with these goals

Deflationary by 10B relays a day
Relay growth can expand node ecosystem
Consistent USD cost per relay for gateways (very important)
Accounts for POKT price
Direct buy pressure incentive
Staking Incentive

Just like SER and ARR have hardcoded elements to them, so does BASH. However BASH took many of it’s design ques from PNF (their desire to hit sub 5% Annual Emissions Rate ASAP, be deflationary at 10B, and constant USD price per relay), while adding other goals that I feel are worth taking into consideration (POKT price, growing nodes, additional buy pressure).

V1 is the opportunity to limit the amount of hard coded goals needed, but for POKT in this market, the it’s very important to account for as many elements as possible… hence my attempt at BASH.

RawthiL · June 27, 2023, 12:56am

My models are never wrong (?) lol

The problem is that it was lower or EQUAL not lower strictly. The non-continuity is actually between 10 and 10.00000001 B Relays:

I will get the rest tomorrow!

shane · June 27, 2023, 1:46am

Take note, that I amended my comment above since you last saw it regarding MINT. It had a GFPR max that was not being honored with a calculation. My main point that GFPR is significantly too high IMO still stands, but I’ve corrected the information

Much thanks for screenshots You are absolutely correct that at 10.00000001 (not 9.99999) there is a bump I did not notice because the train is switching tracks. The pre 10B track is focused on getting to deflation by 10B with minimal hit to the servicers, while post 10B then on growing servicers while still maintaining a deflationary projection.

However, the transition should be fluid, so I updated cell B23. Now it works without any jumps.

Thank-you for pointing out the issue

h5law · June 27, 2023, 11:59am

I really like ﹠ have yet to play with your spreadsheets but I love the idea.

RawthiL · June 27, 2023, 12:25pm

So, the gateway will have to buy twice the amount of POKT (compared to current situation), but it can choose to stake half of it instead of burning the 100%.
So, it will burn half of it, by sending it to PNF, the same as today, but the other half can be staked (through some mechanism, not the point anyway). If the portal locks this other half, then the PNF will use the burn supplement funds to burn that other half of the tokens?

I do not agree this, that number is derived from a very specific situation of the Single-Portal Pocket network, it does not have to rule the economics of the protocol.

Anyway, maybe I’m getting this wrong, but doubled that value:
GBPR = 2 x GFPR = 2 x 0.00000085 = 0.0000017
So, even if the portals are only burning half of that, the immediate price they have to pay is doubled, because they have to buy for burning and staking. No matter that they will recover that in the future.

Yes, the initial parameters of MINT are probably not accurate, I’m working to get correct data and updating them. I will ping you from the MINT post when I have an updated parameter set (and a new spreadsheet page).

I see that you change the condition in the “Low Inflation Focused” mode:

with G_max = 0.0498 (max growth allowed) and R_attr = 10 Billon relays per day, the target of supply attrition.
The condition is just measuring both behaviors (prior and post 10B), so I can imagine that the hardcoded numbers are actually named now (0.052 and 10 in the previous post, wonder why you were aiming at 5.2% supply growth).

The discontinuity is gone but the problems here remain (mentioned in the original reply):

The “Deflation Focused” has the same discontinuity, and this condition wont fix the problem. If you plan to keep it as an option you should also update that condition.

shane · June 27, 2023, 12:49pm

Exactly. The process is not really different than it is today. Instead of a gateway only sending a burn transaction to PNF, they will also send a stake transaction to PNF. Implementing this at it’s core is super simple.

You are correct that is requires gateways to have double the amount of POKT on hand each month… however only half of that POKT is a sunk cost, while the other half can generate rewards for them. If the sunk cost of gateways is too high, the game theory would lead to gateways deploying their own infra. Staking is a way to increase POKT demand without being a sunk cost. With POKT being at an ATL, there could be significant upside for gateways to hold POKT now, and this mechanism makes it straight forward.

Also, app staking has always been considered a part of v1, so this is emulating the stake side during v0 and would allow apps (or in this case gateways) to more easily transition into v1 (if there is a staking requirement). Since we don’t know what the economics will be like yet, this could be a good practice to have in the meantime.

Could you please show me on the spreadsheet what problem you are referring too? Apologies, but I’m not tracking what you are talking about.

Deflation Focused does not seem to be as popular as Low Inflation Focused which hits all of PNF’s goals. Unless there is a real desire for the Deflation Focused one, I’m just going to focus on perfecting the Low Inflation Focused model.

I’ve re-orded the pages so Low Inflation Focused is the default.

shane · June 27, 2023, 2:37pm

UPDATE 2

A few updates have been made:

Fixed B23 to create a fluid reward transition post deflation thanks to feedback from @RawthiL (See comment here)
Added a Goals panel at the bottom which can be adjusted. Once deflation has been archived, The Post Deflation Accelerant Curve determines if it is best to focus on faster deflation or growing the Servicers, Validators, and the DAO economy. Adjusting this variable will adjust how fast deflation accelerates.

image820×201 18.9 KB

Also, I have made the Low Inflation Focused page the default as that page is what meets more of PNF’s goals. I will not be updating the Deflation Focused page unless there is desire in the community.

Happy to get any feedback from PNF
CC @Dermot @JackALaing @b3n

RawthiL · June 27, 2023, 5:34pm

Here is the updated part of the model

You see how you are getting close to the five questions that I use in the MINT playground? You added the PDAC, which is the Protocol Share… But lets not discuss this here.

I will break down two scenarios, a possible one and a great one (but terrible for BASH)

Pocket Success!

In this scenario I compare the current state of the network with one where the POKT price gets to ~3x . Both of them with current number of relays and ~3x number of relays

This is the earnings and payments graph that governs this experiment. The colored arrows signal where each spreadsheet screenshot was taken (color of spreadsheet marks correspond to points in the curve).

POKT current price (0.033) and current relays (1.2 B)

imagen847×702 94.2 KB
POKT current price (0.033) and ~3x relays (3 B)

imagen860×719 96.7 KB

All good, more relays —> more earnings
POKT ~3x price (0.1) and current relays (1.2 B)

imagen871×717 96.3 KB

Great, price up, more rewards!
POKT ~3x price (0.1) and ~3x relays (3 B)

imagen867×711 96 KB

Now that we have more relays I will be ri… oh wait! Lets not grow so fast maybe…
POKT ~3x price (0.1) and ~0.5x relays (0.5 B) BONUS Track

imagen868×714 94.1 KB

Maybe I should start claiming less relays, wdt felow node runners?

Pocket Rockets, holder making lines to buy Lambos (or at least a nice Chevi)

I dont need to explain much, POKT is at 1.15 USD…

Lets see the red mark in the spreadsheet

Node runners are actually paying to be able to serve relays…

shane · June 27, 2023, 8:11pm

Fantastic comment! Thank-you for using the spreadsheet I can address them specifically.

The scenario you are creating is:

Green Scenario - POKT price 3x and relays do not increase
Blue Scenario - POKT price 3x and relays relays hit 3B
Pink Scenario - POKT price 3x and relays drop by 60%

First, off, I do not believe those are realistic scenarios with POKT skyrocketing to 3x without meaningful gateway activity. It seems the entire POKT ecosystem believes that meaningful buy pressure will only come from gateway adoption, and these scenarios are the opposite of that.

However, say that POKT does hit a new price trajectory, without the help of gateway traffic, BASH already can follow the path of ARR and increase services rewards on the way to deflation. First lets see how ARR does.

With ARR’s original 38C projection, it will start to hit deflation by 10B relays (similar to the default Goal in BASH).

However if the price were to essentially 3x to the 10C, as you are proposing, then ARR no longer hits deflation at 10B. It instead will have 3.07% inflation. Deflation would instead be hit by 26B relays a day.

This is because with ARR the deflation point always changes according to price. If the price of POKT doubles, it hits deflation with double the relays… and if the price of POKT is cut in half, it takes half as many relays. This exact thing can be done with BASH.

With BASH, if the price of POKT does a 3x increase, and you want to favor servicers with more rewards and not hit deflation by 10B, then you can change the Deflation Goal to 26B to be on par with ARR.

MINT on the other hand is able to make sure servicers always get increase rewards in a cleaner way, but it does it:

With unrealistic and unstable GFPR
With uncapped inflation (meaning it does not have a 4.98% cap as PNF has suggesting).

The “Deflation Focused” model of BASH does act similar to MINT where it doesn’t have an inflation cap. However, from what I’ve gathered, folks want to hit PNF’s goal of sub 5%. If the community doesn’t care about capping inflation and just cares to hit deflation by a set number of relays, then the other model does that.

I’m not entertaining the other model at the moment, while the community push seems to be hitting sub 5%.

lol… well that will only help if POKT would 3x. If doesn’t skyrocket, then you are just missing out on rewards

lol… if we hit 1.15 USD, then we don’t need to worry about deflation at all… just set deflation goal to 6 trillion and ride that reward train

In Conclusion

BASH is about setting specific goals in terms of an emissions cap, deflation, and maximum buy pressure (burning and staking). If the price of POKT falls, then each goal can still be met WITHOUT over diluting servicers. If the POKT price were to suddenly increase substantially, and we want more rewards to go towards servicers, then the deflation goal simply needs to be moved from 10B.

Dermot · June 27, 2023, 8:27pm

Thank you @shane for all of your awesome work on this.

Notwithstanding your extremely helpful contribution to our collective knowledge, I do not support BASH (at least for now) for the following reasons:

Time is of the essence. We need to reduce inflation now to give confidence to those outside of this community that we care about economic sustainability. Otherwise, we will fail to bring in new contributors, and attention towards this project and POKT itself will continue to wane. The gateway parameters need much more thought and debate. Portal staking is going to happen in v1 and we are just about to kick off a 6 month research workstream, including some outside experts, so we can ensure the adaptability, dynamism and sustainability of Pocket’s economy. Whatever we do now, will most likely change pre v1. So if you agree with the inflation cut, why not agree to that now and then we can work on parameterising the gateway fee in a step-wise fashion by working on it in parallel and putting it up for a future proposal in a month’s time, or however long it takes?
Additional complexity. In addition to the point about the necessary debate around gateway incentives, there are also some new parameters included here that we need to understand more deeply. While I really appreciate how much more simple this proposal is to grok than MINT (which, for the record, is also a very impressive contribution), there are clearly some edge cases that we need to understand better before pushing this to a vote.

RawthiL · June 27, 2023, 9:13pm

This worries me a little…