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.
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.
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.
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).
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
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.
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.
Thanks for the feedback and I understand your points.
So⊠actually BASH provides a balanced version of ARR already, without staking. If you do not want to activate the staking requirement for gateways, and instead do that down the road, then it is already in BASH, while still providing balance to where ARR is lacking.
Balanced ARR
To show you what I mean, I created a page that only focuses on buring, with the staking elements turned off.
To take out the staking on BASH, I simply set the GFPR to $0.00000085 (which is the same as ARR) and set the Stake Ration to 0%. This means that gateways have to pay the full GFPR and there is no Burn Supplement.
Now let me show you how BASH accomplishes ARRâs goals better than ARR, even without the staking elements of BASH.
If POKT price falls below 38C, (which it already has) then ARRâs minimum servicer allotment of $250k get exponentially eroded by the time we hit 10B relays a day. Look at what ARR would produce if POKT hits 2C⊠only $114k for servicers
However, as you can also see on the left, BASH keeps the ecosystem as balanced as possible. Instead of having a -4.55% Emissions (which is far more than what we need in the short term), BASH properly balances the inflation so we still hit deflation at 10B relays a day, but with $219k still supporting servicers. This is because ARR is not balanced for lower POKT prices. Already today, if it were to pass, it would cut servicers much more than it advertises in the proposal itself.
BASH is the balance to that. It accomplishes all the goals of ARR, but in a balanced manner (even with staking turned off). If the price of POKT hits 15C then the servicer budget is only $86k with ARR, which is 1/3 ARRâs advertised servicer budget. BASH stays at $219k even with the price drop.
Complexity
While BASH has more algorithms, I would not say it adds any additional complexity (especially with the staking turned off for a later date). I would argue ARR is much more complex, not because of static 255k POKT per day it mints, but because it creates an unbalanced ecosystem that is dramatically effected by sways in price. Price drops exponentially hurt other ecosystem participants in an uncontrolled manner.
Adding balance in this case makes for a more involved spreadsheet, but it can provide a much more stable environment for the ecosystem.
ARR will require many more proposals in the future to create balance. Once relays hit over 10B, and POKT becomes deflationary, ARR is designed to just keep feeding deflation without providing any balance for other ecosystem participants. BASH provides balance that scales to infant relays past 10B.
My Ask
What are you thoughts on the Balanced ARR page of BASH, where the staking elements are entirely turned off for a later date?
We could propose BASH for the better balance and ecosystem predictability (while hitting all the goals of ARR), and hold off on the staking elements for now. What would you say to that?
This would just be a matter of submitting the BASH proposals with parameters that do not include staking (as they are in the Balanced ARR page).
ARR doesnât include a minimum servicer component of $250k. ARR is solely about reducing the RTTM to target 220k of POKT per day in daily issuance as per the following extract:
I think there is a misunderstanding in the quote above.
-7.7% deflation is a good thing for all of Pocketâs stakeholders. And is much better than 0% inflation/deflation. Deflation reduces our supply and naturally means that protocol revenue is high. A deflationary scenario where Pocketâs economy is burning more POKT than it is minting - in a manner that sufficiently incentivises all stakeholders, and accounts for the growth needs of the network - means that Pocketâs economy is healthy and sustainable. Provided these conditions for sustainability and growth are met, there should be no such thing as an âoverburnâ.
Furthermore, capping protocol revenue at a number that matches minting would actually mean our protocol revenue nets out to $0. As per:
All holders of POKT will benefit from a reduced supply, including node runners, as it is likely that their node rewards will go up as each unit of POKT they receive for the work will be more valuable (unless there is a USD cap, which is a separate conversation, and explicitly not part of the ARR proposal).
Iâm not sure where youâre getting these numbers from in the quote above? If the price of POKT goes up to 15c, then daily node rewards will be 220k POKT * $0.15 = $33k per day / $990k per month / $12m per year
This will likely be too high unless weâre talking about many more relays than 10B, but at those price levels, itâs a good problem to have. And when we make such decision - hopefully proactively, as opposed to reactively - we will be armed with much more data and consensus from the community.
As mentioned in my previous comment, we have much bigger problems if POKT falls to 2c. And neither BASH, ARR or MINT can fix such problems alone.
I largely agree that even the reduced inflation rate proposed by ARR is likely more than we need at this point in time in Pocketâs growth journey, but I am very wary of attempting to lock in a floor for node rewards right now.
What we do know is that inflation needs to be cut. How much we should cap node rewards to is more uncertain, and the decision was made when drafting ARR to push this decision further down the line. We are also not sure how much consensus there is around a USD cap on node rewards yet. And it will be hard to push for one without the results from the node runners survey and deeper market analysis, which will likely take at least another month to get all the data, analyse it and publish it.
I disagree mainly because ARR shouldnât be seen as a holistic solution to every problem in Pocketâs economics.
It sounds like you agree with the need to reduce inflation. So I think we should start there, as it feels like there is consensus around it. Voting for ARR doesnât mean voting against the additional parameters proposed by BASH, or MINT. Itâs simply a vote to reduce inflation. And to continue the conversation about everything else, such as:
whether or not a USD cap on node rewards is desirable, and if so, what that cap should be
the gateway fee, and how that should rise with relays, as well as the quality of Pocketâs overall service, along with the need to incentivise new gateways to join the network and drive demand
experimenting with a staking component for gateways (as will be the case for v1)
increasing minimum node stakes
any other bright ideas!
I agree that ARR will require more proposals in the future. Still, I actually believe that doing things in a step-wise fashion that everyone understands is much more preferable than trying to design the perfect complex system upfront when there are still so many unknown variables to work through, such as gateway incentives, the USD cap, staking, and so on.
And I will be much more comfortable agreeing to more complex changes if 1) they will contribute to our understanding of the economics for v1 and 2) we have sufficient data and analysis to justify them, including from the third party expert that is to start work soon on helping to define the minimum viable parameters for Pocketâs economic design in v1. (this last part is something that I hope that you @shane and @RawthiL, amongst other notable community economists, will play a significant role in)
In closing, ARR is simply a vote from the community on whether or not we should bring inflation down to c.4.98%. We are leaving the door open for all of the other interesting mechanisms and parameters proposed by BASH and/or MINT, and simply ask that we do this in a step-wise fashion. Cut inflation now, and buy more time for everything else.
For the record, BASH doesnât lock in a floor (like MINT), it just doesnât reduce inflation âmore than we needâ (unlike ARR). BASH just doesnât over cut (hurting servicers and validators) while still:
Being below 4.89% emissions Being deflationary at 10B
I must admit⊠Iâve been looking at spreadsheets for far too long. I meant 1.5C, which is down from my original number of 2C. I forgot the decimal. Apologies for the confusion.
We likely wouldnât be having these convos at 15C
TBH, not looking forward to having this be a constant conversation on where numbers should be depending on where the market is at That is why I made a dynamic model, so PNF goals can be achieved, with methodical balance. My logic was having a more balanced approach would actual save PNF from having to do new economic models, and not need more proposals (unless it gets really bad).
I understand that moving in a stepped approach can have itâs merits as well.
Ironically BASH was designed to lean into v1 elements now, like staking, in a measurable way. Iâm interested to know when models like BASH that have v1 merit will be able to be considered.
Also, @RawthiL is fantastic for 3rd party vetting. He was amazing with providing that to the ecosystem with a full audit that went through every single variable. He took my model, built it from scratch in python and validated that everything worked and balanced exactly as intended⊠and even pointed out areas that it could be improved (which I did). In terms of 3rd party vetting, you canât get better than that IMO. It was a pleasure working with you @RawthiL⊠great job
In terms of the other 3rd party vetting system, that is external of POKT folks, I look forward to hearing more about that.
I guess that was my problem, I took a holistic approach When times get tight, cut all waste⊠hence my approach of taking all the problems, and all the goals, and address them in an applicable fashion. In my mind, if less waste is produced, and POKT economics work more efficient, then it buys more time before needing more proposals.
Whenever the time is right to take a holistic approach⊠Iâd say put out a POP or open a Socket. I personally believe this should be a priority.
FIN
Thanks @Dermot for the detailed reply. We are aligned that there does need to be economic changes⊠though we differ on the scale that should be addressed now. Happy to have contributed to the conversation though. Happy also to continue this when the time is right (though Iâd prefer through a POP or Socket).
Thanks for your part in starting these discussions going with ARR
I like the âBalanced ARRâ model of BASH - without the staking for now.
But to talk about the above I think its a good idea to begin the discussion around V1 economic models but not try and force them into V0 which is a different protocol. Its a very cool idea to bring in gateway staking but it may overcomplicate the intention of a inflation reduction proposal (yours has other benefits besides just reducing inflation tho )
I think we have a discussions section in the V1 repo and you can open an issue in the V1 spec repo for any changes you want to make there. If you @ any of the devs using our github usernames we will be notified and can jump in the discussion but I think the more community members who help the better it will be. Devs shouldnât decide on economics alone and the more feedback we can have the better IMO.
Thank you @shane for all the time and effort that went into making this proposal. I know Iâm late to the discussion⊠this is the first Iâve had opportunity to give the proposal a good look.
Following is some feedback to take into consideration :
It is hard to evaluate your idea of requiring/incentivizing Gateway staking without more information on what that staking entails. You raise certain questions for discussion such as leaving the stake unproductive vs using the amount staked to stake nodes etc, but there are much more fundamental questions that need to be addressed, such as
âWhat is the purpose of the stake (staking for no other reason than to âcreate buy pressureâ is a recipe for failure best left for the realm of meme coins)
â What are the terms and conditions for the return of the stake to the owner for unrestricted use (this is important becase whatever âbuy pressureâ is created by requiring/incentivizing the stake always comes with an equal-and-opposite sell pressure when the unstake happens
âWhat concept of slash is being defined for this stake. Is the stake being tied to âgood behaviorâ by the Gateway in any way?
It is very questionable whether this staking feature will create any buy pressure until post 10B relay as current gateway operators likely have sufficient pocket in treasury to cover that stake (as long as their ownership in the stake is secure - see first question - , they can simply tx custody of their treasure from self-custody to DAO-custody to fulfill the staking component
It is rather unprecedented in the crypto space, as far as I know, to require an ever-increasing stake to operate as an ecosystem actor. If you have examples from other projects that do something similar to what you are proposing, it would help to have your staking idea taken seriously.
While v1 design decisions have been made to allow for the defining of âGatewayâ as a unique protocol actor in v1 separate from âAppâ I think some very top-level discussions are needed in the community on whether we really want to go down that road and what should it look like if we do⊠prior to embedding presumptions of Gateways as unique actors into a v0 proposal . I.e., all the questions being asked above about purpose of stake, events that could cause slashing of stake, etc. As far as I can tell, if the T&C of being a POKT Gateway is too onerous in comparison to v1 self-staking, business entities can simply operate unregistered Gateways via self-stake mechanisms. All that to say, we really need to give this area careful thought. Note that this is very different than PIP-29 and GatewayFeePerRelay. That fee and burn mechanism is explicitly a precursor to app burn, not the precursor of a v1 Gateway-unique mechanism.
I simply am not understanding how Burn Supplement is anything beyond âsmoke and mirrorsâ. Why would we go down the more complex path of minting more tokens only to send a portion to the DAO to be burned rather than the simpler and more straightforward path of just minting the desired amount of tokens?
Everything I said in the MINT proposal regarding USD-denominated supply applies here. I copy relevant portions of that discussion here. I think @RawthiL is starting to understand my concern and has expressed willingness to define an upper-bound on RTTM. I would challenge you to consider this issue as well and do likewise.
Unique to your proposal, the equation in cell B23 does not work. You have both a USD-denominated term and a POKT-denominated term. It is permissible to add unlike terms but not to subtract unlike terms in the manner that you current define. This is because when subtracting, there will always be some POKT-USD conversion rate at which the equation becomes negative and RTTM becomes undefined. See, for example, 20B relays and price $1. This is why, in the MINT comments, I suggested using a percentage less than 1 (rather than a subtractive element) to get mint to be less than burn once the subsidy portion goes away:
On a completely separate note, my personal view is that both the BASH and the MINT proposals, while starting some good discussion on path forward as the network grows, are distracting from the immediate question as to whether to leave the gradual reduction in subsidies in place as defined in SER or whether to make an aggressive reduction in subsidies via the ARR proposal.
Both BASH and MINT claim to be able to accommodate sub-5% inflation if that is what the community wants. Great! Letâs vote on ARR first to see if the direction the community wants to go and then circle back to the question of how to incorporate a non-subsidy component (e.g., see my last equation above) that scales up as relays grow.
You are failing to see the big picture past v0. As I said
V1 has always been expected to have staking requirement for app developers, and BASH starts that process now when relays are small.
It would be prudent to start a staking mechanism now while relays are small then to try and suddenly require staking when relays are huge at the launch of v1. We donât know the specifics of the staking economics, but BASH at least starts apps staking which makes a transition to v1 much more possible (while the details are being flushed out).
Comparing that to âmeme coinsâ feels quite disingenuous.
Iâve already put a few suggestions in a prior comment
You are welcome to provide your own suggestions a well.
App staking has always been about access to POKT, and node staking has been about âgood behaviorâ enforcement. So you are conflating the two, by thinking that slashing has to be a part of app staking.
However a slashing element could be introduced in v0, but it would on a contractual level between PNF and the gateway. If the gateway misuses the appstakes, they will incur a slash on the tokens that are staked on their behalf. Since there will be a lot of trust with those owning the appstakes, a slash mechanism would only be possible with BASH, unlike the other proposals.
I see that more of a part of PNFâs contract with the gateway vs being baked into a proposal though. Having a stake to leverage in the contracts would be worth considering.
You are mistaken on how much PNIâs and Nodies treasuries realistically have and what BASH requires of them. Using the BASH spreadsheet
Even pre-10B, neither PNI nor Nodies could constantly fulfill that amount of required POKT per month to burn and to newly stake without using the market.
BASH objectively doubles the amount of POKT gateways are required to relinquish each month compared to ARR (though without increasing the gatewayâs sunk cost). That is my point, and it is very rational that at these numbers, gateways will need to use the market to acquire POKT more than with just a burn mechanism like ARR.
You are correct that I do not believe anyone else has conceptualized or implemented this type of mechanism. It is new.
POKT is in a position where we need to increase the POKT buy pressure, and increase the amount of POKT staked to be in the best position for v1. For the past year, the percentage of POKT staked has been declining for a year, and this is a novel way to reverse that trend, which is why Iâm proposing it as a v0 mechanism.
If you desire to change the gateway spec in v1, then that should be a different thread. Itâs been well established for a very long time that they would be a v1 actor, so if you want to question it, then feel free to do so, though on a relevant thread.
This proposal is based on the existing v1 spec, and what PNF is already doing with v0.
Iâm open to simplifying this proposal, however you are missing how the Burn Supplement provides an enforcement tool for PNF to ensures gateways meet their staking requirement.
PNI has to burn 6M. If they lock/stake 3M, then 3M from the Burn Supplement is returned to them. If say PNI did not manage their POKT buy strategy and only stake 1.5M, then only 1.5M will be supplied to them from the Burn Supplement. The 1.5M remaining in the Burn Supplement is simply burned, resulting in 1.5M more POKT being burned because a gateway did not claim it with staking.
If a gateway does not stake, then BASH actually accelerates the burning of POKT.
I wouldnât call it âsmoke and mirrorsâ concept.
Could you provide a screenshot of the BASH spreadsheet that shows what scenario you believe BASH is not addressing?
Again, please show a screen shot of this scenario as well.
I have always understood the App stake to be to stay above X threshold in order to secure Y bandwidth⊠which needs to be topped off each month as tokens are burned via app burn. This creates double buy pressure only during the first month and then single buy-pressure there on out. Any desire to replicate that now would be great. However your proposed staking mechanism is entirely different, calling for an ever-increasing stakeâŠ
I will give this some thought⊠I think it is going to be easier to handle this completely within Gateway-to-PNF T&C and leave mint completely out of the picture. Iâll work though an example tomorrow
Thank-you for the screenshots! A picture is worth a thousand words
Exactly⊠we have no idea what X and Y will be, therefore Iâm suggesting we start progressively staking apps ASAP, so that there is already staked POKT once X and Y are established. Allow app to start accumulating POKT in v0 which can translate to a v1 stake.
By opposing staking in v0, and then springing a staking requirement on apps in v1, we place a much larger burden on apps during the v1 transition. Instead Iâm suggesting allowing apps to progressively stake each month, have a nest egg of POKT, which can be translated into their v1 staking requirement.
I believe POKT can have two good things at the same:
Allow apps to start staking POKT in preparation for v1.
Increase v0 buy pressure.
I donât agree with the notion we should not take any staking actions until we know exactly what X and Y will look like in v1. Worst case scenario is an app got POKT cheap and has more than they need to stake in v1⊠in which case they can do as they wish with the POKT when it is unlocked. But in the meantime, it prepares them for v1 and adds buy pressure during a critical time for POKT.
Now, regarding the scenarios and screenshots you provided
RTTM Cap (Extreme POKT Price Drop)
You are suggesting an extreme scenario where POKT is down -84% to -97% from todayâs value with no new relays added to the network. At that point a nuclear option proposal would likely need to put into place, as servicers are losing tens of thousands a month.
An RTTM Cap should likely be a separate proposal, so that regardless of what economic model is in place, there is that cap. I donât see that cap being a part of BASH specifically right now though, however it could accept a RTTM cap if the DAO decides on a limit as a nuclear option.
Negative RTTM (Extreme POKT Price Increase)
@RawthiL already asked about extreme price increase
TLDR: The reason it is a negative RTTM is because the default goal for Deflation is set 10B relays, which in the scenario you are suggesting, where POKT price increase by 3300%, requires a negative RTTM to hit deflation. To avoid a negative RTTM in this extreme scenario, then the deflation goal (B29) needs to be adjusted to above 20B relays or higher.
If POKT increases by 3300%, then a follow-up proposal would be needed to adjust the goal parameter⊠but again, we are talking about unrealistic extremes here. My focus currently is adjusting BASH for realistic market conditions.
Conclusion
Both of these scenarios are extreme, however param changes can be made to BASH to account for each.
Thanks for the example! While the Burn Supplement makes the staking optional, your suggesting bypassing it by making staking mandatory.
With mandatory staking the gateway is required to send two TX to PNF, one of for the burn and one for the stake. If they do not complete both, they are breaking the requirements to run appstakes and could lose their access to POKT for relays.
My original suggestion was making the staking optional, which does require one more TX from PNF to send the gateway their owed Burn Supplement, but it opens the door to more POKT being burned if gateways doesnât stake.
Optional staking also opens the door to app staking on their own behalf through something like wPOKT. This could take the gateway out of the picture if they are willing to pass on the savings to their apps, and not put their appstakes at risk if staking isnât done by the customer. That is part of the rational of keeping it optional, as there are ways to grow the POKT utility. However, I understand that it would take development on-top of wPOKT, which would take time, so it wonât be possible in the immediate future.
Regardless of making staking optional or mandatory, the both accomplish the same buy pressure with the same balance between rewards, burning, and the Annual Emissions Rate. Making the staking a mandatory requirement is a very viable option, so thank-you for the suggestion @msa6867
Your âoptionalâ staking, as it stands, does not feel very optional. It still mandates transferring $17 per million relays to the DAO rather than $8.5, just as in my effectively-equivalent âmandatoryâ example. If the combination of transfer for burn and stake is anything less than $17 per million, the gateway is breaking the requirements to run appstakes just as in my âmandatoryâ example. (If the staking portion can be optionally fulfilled by a 3rd-party custodian or via verified self-staking, that option can just as easily be added to the âmandatoryâ example). That is why I call the two scenarios effectively equivalent.
The reason they are effectively equivalent is due to the 1:1 reduction in required burn per amount staked. Sure, the gateway can altruistically instruct the DAO to burn the entire $17 per million rather than designate half of it to stake, but the same is true in my simplified âmandatoryâ scenario.
I am intrigued by the idea of incentivizing staking (up to an anticipated amount needed for âX,Yâ as discussed above) but to make it feel like it is a possibly viable option not to stake, the reduction in required burn must be less than 1:1
Hereâs an example of what I mean of a staking option that truly feels optional (meaning it is a reasonably viable option to choose not to stake):
âGateway burn is set to $12.75 per million relays. However for every dollar that is staked, the required burn will be reduced by 50 cents up to a maximum burn reduction of $4.25 per million relays)â
In this example, one gateway operator might prioritize reducing opex and thus stake up to $8.5 per million relays in order to reduce their burn bill to $8.5 per million relays, while another gateway operator might prioritze cash flow and choose to pay the full bill of $12.75 per million relays.
Thanks for the comment! I too really like the concept of providing a burn supplement or burn discount for staking, and I think some kind of mechanism would be beneficial for the POKT and even for v1. Staking has always been so binary⊠you stake X amount and you access to Y amount of relays, but it makes more sense to me that staking is used for discounts, instead of raw access, hence why I started down this road.
Thanks for adding more ideas to the mix around this concept
I originally didnât pursue a variable GFPR rate per gateway because then calculating each gatewayâs GFPR will be different each pay cycle depending on how much they decide to staked. This then also means that the amount of POKT burned each month varies depending on the staking of the providers, which means the the RTTM has to be changed, according to the staking habits of providers, to hit PNFâs specific goals they laid out in ARR.
I made a Varable GFPR per Gateway sheet (Iâm calling VGG for short) to show what I mean using your example rate of 50c discount on burn per $1 staked
Check out the RTTM when PNI decides to stake 50% of the max discount they could achieve. This is a middle ground strategy of keeping more USD, while still getting a discount.
Now, if PNI decides to stake the 100% of their discount, the RTTM must adjust to hit the deflationary goals, which means that Servicers, Validators, and DAO rewards actually get reduced since less POKT was burned and more was staked. Servicers loose $13k from PNI changing their staking strategy.
Open to thoughts, but my original intent was to have as consistency rewards as possible while still hitting very specific relay to emission goals, which is what the Burn Supplement provided. It didnât matter what gateways did or what the price was, POKT would always hit specific economic goals according to relays, period.
BASH lets you put in specific goals and then makes sure the ecosystem meets them with the most balanced approach possible. The VGG does seemly does provide less âcomplexityâ, but it become more variable, though far from the variability of ARR since BASH is still balancing to the best possible outcome.
Settlement Differences
The VGG also puts different responsibilities on gateways and PNF. With VGG, gateways must correctly balance their GFPR TX and their staking TX each pay cycle, while PNF acts an auditor. Since PNF doesnât have funds to supplement, gateways are responsible to calculate. With the Burn Supplement, gateways always know what the GFPR TX should be (since it is consistent), but can get a discount with a staking TX.
We are both achieving similar staking goals as you said, but placing the settlement responsibility on different parties. I am thinking of PNF as being the final settler, with GFPR being a universal parameter and have staking settled after the burn TX is sent. Your suggesting the gateways do their own settling by calculating the discount prior to burn TX, and then PNF auditing. Neither way is wrong, and it would likely come down to feedback from gateways and PNF on which path they would rather pursue, since I have no idea how burn settlements are even done now
I can address them specifically.
With unrealistic and unstable GFPR
Being below 4.89% emissions
