An Open Letter to the Pocket Community on Economics

Since Pocket Network’s mainnet, our economic system has been largely static outside of the WAGMI system. It’s time to start a discussion around what can be implemented to better serve our holders, node runners, and applications. The changes proposed below are designed to alleviate many of the pain points experienced by the Pocket community in these market conditions, while balancing the need for sustainability.

For nodes, POKT is staked by node runners on as many nodes as possible which would net them the maximum token incentives possible. This design was created to maximize node count and token distribution until the time at which we could compete with centralized RPC providers. Mission accomplished: over the last few months we’ve become just as fast, if not faster than centralized alternatives, we are orders of magnitude more redundant, and way more cost-effective. There are no longer trade-offs when selecting Pocket Network as your web3 provider.

Given this milestone, it makes sense to turn the page and begin to think about how we evolve the tokenomics to better suit the needs of the network and its participants. At the present, we have too many “sources” and not enough “sinks”, one of the major critiques we’ve heard in the past. Sources are where POKT is minted or otherwise becomes liquid and sinks being systems that take POKT out of circulation.

WAGMI is designed to curb the main source, but it only addresses part of the problem and, in my opinion, doesn’t go far enough. It was the first step in the process to create sustainable economics, but WAGMI is not the end all be all. I view it as the first in a series of proposals needed to bring Pocket Network out of its bootstrapping phase.

We are working internally and enabling externally to author concrete proposals. To give you a sense of a recommended order of operations I would suggest a timeline that looks like this:

  1. Development of self-staking tooling on the Pocket Portal (already started)
  2. An increase of minimum stake and the associated coordination effort potentially combined by an increase in validator count (if technically viable)
  3. Decrease of rewards in proportion to the decrease in network cost
  4. Development begins of the stake-weighted session selection mechanism (not started)
  5. Stop-gap parameter changes are made to encourage consolidation of POKT stakes
  6. Release of self-staking in Pocket Portal
  7. Release of stake-weighted session selection mechanism and unrolling of the stop-gap parameter system (6-12 months)

I’ll begin by addressing sources and then I’ll speak to sinks that I think are worth focusing on, not necessarily going in the proposed chronological order. As a note, proposals could/should rolled back as long-term fixes are introduced by better proposals or by code-based fixes.

To maximize utility and value-driven to the token, we need to reduce the cost of the overall network which in turn can be used to dramatically reduce sources of POKT. Our tests indicate that nodes can handle far more than what they’ve been given credit for. At present, our engineers are estimating the ideal node count considering distribution and capacity to be about 15,000 nodes distributed across the globe near traffic sources. To be clear: this means we’re highly over-provisioned and can cut network costs without damaging the quality of service. During times of discovery, testing, and growth, this sort of over-provisioning can be useful, but we view it as unnecessary going forward.

To reduce the node count while maintaining effective sinks, we must move to a new model. There are a few options presented to us in this case. The first is increasing the minimum stake. This would be a large coordination effort to implement, but the juice is worth the squeeze for economic security alone, not to mention the effective sink that this would create. The exact numbers will require some debating to not hurt small node runners, but our initial thoughts are 2-3 times the current minimum stake of 15,000 POKT. Further, the count of validators could be increased to bolster the security of the network and encourage more diverse validation.

Secondly, we can design and implement a system that encourages the consolidation of large amounts of POKT on a certain number of nodes. In this framework, node runners would be required to concentrate POKT on fewer nodes. Without getting into implementation, this can be accomplished by code or parameters. The code implementation would increase the likelihood of being chosen in a session in proportion to the number of POKT staked. A parameter stop-gap implementation could encourage validating over servicing. There are pros and cons to both approaches and those should be discussed at length.

After you reduce the cost of the network, it’s simple to continue decreasing the mint rate of POKT in proportion to the reduction in cost (using WAGMI). This will impact many of the businesses built on Pocket Network, but those businesses have been surveyed and they are bought in on reducing the costs of the network and inflation in a way that creates long-term sustainability.

By implementing all of these changes, we can better balance our sources and sinks in the lead-up to Pocket Core v1.0. If we are successful, we can work toward becoming a minimally extractive network - a core guiding principle of the founders.

Further, it’s time to start encouraging applications to stake. Staking would produce three flavors of apps on Pocket Network:

  1. apps under the free tier
  2. apps that buy POKT on the open market and stake on Pocket Network
  3. apps that pay but don’t own POKT directly

Regarding the first, Gigastakes was effective at getting us to a billion relays/day, but is not designed to be a sink. This is a freemium model to get users hooked on Pocket and then convert them to “paying” users. Users can be converted in one of two ways as described above. Apps that bring their POKT are a simple matter of having them stake in one of the pre-staked slots on Pocket Network. This is the cleanest and simplest way to interact with Pocket Network. If apps want to pay with credit cards or stables, as proposed by Florida, a community member, a buyback program should be considered. Runners of Portals (you can too - it’s open-source) can charge apps a one-time or recurring fee and buy the POKT off the open market. Charging for app stakes is a simple cycle that gets POKT in the hands of developers and also makes the UX simple for anyone to use.

We understand that any of the ideas proposed above would lead to dramatic changes to the stakers of POKT network. This fact is not lost on me. I expect there to be many detractors of any change. Now more than ever, our ecosystem must take a long-term view on Pocket Network and do what’s best for the protocol over the interests of anyone individual or group.

For those that have weathered the storm with us for years, we :heart: you. For those that are newer and nervous, we understand. We’re doing everything to keep earning everyone’s trust on a day-to-day basis, and we’re going to keep building no matter what happens in the market.

As a reminder: the core team doesn’t control any of these changes - the voters of the Pocket Network DAO do. If you’d like a voice, we have a one-person, one-vote system. Have your say.

10 Likes

Would it be a good idea to activate pokt burning for app stakes?

We really need that pokt demand on the market and if the usage is valid, users should be paying for it, by buying pokt monthly

2 Likes

App staking is not enough, because we are creating poker rewards daily, those must be burned somewhere to balance supply/demand and defend the price

The concept of having pokt as right to execute 10 relays a session, should become the right to execute 10 relays a sessiob for a month

2 Likes

I generally agree with this. I have some concerns regarding increasing the minimum stake amount, as this could hurt decentralization not too far down the road. If it starts costing $45,000 or $60,000 to stake a node, that’s going to severely limit the number of people that can afford that - which would lead to more people staking in pools. Pools are great , but they don’t achieve the goal of decentralization, quite the opposite. Personally I think the carrot and stick approach of encouraging node runners to consolidate POKT on fewer nodes while reducing inflation via WAGMI would be the way to go. This would naturally allow the market to decide how much to stake based on network conditions, and also allow node runners to roll back and split into more nodes should relay demand require it.

5 Likes

Do you mean “validating over servicing” (no hyphen)?

Thanks for this post @adam. Clearly with the current market conditions everyone’s concern is understandable. However, I can’t help thinking that the market might naturally address some of the issues.

I absolutely agree with the Pocket engineers - the network is way over-provisioned and ~50K nodes aren’t necessary at this time. But given the current market conditions, some node runners will naturally choose to unstake for economic reasons. This will reduce the total number of nodes it seems. The existing node runners are likely the ones who are in it for the long haul anyhow and they will innovate to find ways to make running nodes more cost effective and resilient to changing market conditions. Increasing the staking requirements or encouraging consolidation of POKT stakes introduces a lot of potential unknowns (read: risk) - especially in the current market. The market is testing us now for sure but maybe all we need to do is to weather the current storm.

5 Likes

I fully agree with the proposal to change the staking reward: reward should be based on the number of pokt staked and not number of pokt and number of nodes.

1 Like

Firstly thanks for the post, there seems to be more of an focus on the ‘cost’ to run a node, where the thinking seems to be “if we increase the cost to stake to 45,000 - 60,000 POKT per Node”, talking this through what will be the result here; total nodes will reduce by the same or similar factor, that will reduce the months costs for Node Runners (that’s good for me as a Node Runner), the rewards will be split across fewer Nodes, so the rewards per Node should increase (neutral as a have less nodes), the ability for new Node Runners to buy in will reduced, but the counter argument here is that really depends on the price of POKT as it’s 45-60k POKT * $X.XX - we need to find $X - essentially if you reduce this down as a Runner, my monthly costs will reduce by a factor of 3-4, OK but this is only relevant if I’m paying in FIAT, not in POKT, if your running based on POKT this would be be driver behind your decisions.

I can’t help but think ‘is this the right part of the problem to focus on?’ We have lots of Node runners that the economics, until recently, has worked for. The reason the economics of running a Node are not currently working is the price of $POKT has dropped to $0.16 (at time of writing), for me this should be a focus, and there have been some good discussions and formal points raised at Infrcon

  • Create liquidity (in process with wrapped POKT)
  • Get wPOKT onto CEX/DEX so it’s much easier to buy/sell (In process)
  • Start to charge App users (In process)

If I could wave a magic wand, it would be to get the core team (or as many as possible) to focus on implementing the Charging of POKT, this is admittedly not as exciting for Devs, but is a core challenging, one that I think the core team have solved (in the thinking) but needs a ‘all-nighters’

In summary

You have already solved this in theory, it’s now just a matter of what you focus on and when - the order you do things in, matters as much as what your doing in many cases.

Focus on the ability to buy/sell POKT and the ‘Value’ of POKT, this would have the maximum impact for the near term and the far term, for the whole POKT ecosystem.

Focusing on more POKT per node doesn’t seem to solve the core issue, but more a sticky plaster, less runners get more $POKT - where $POKT Is worth $X

Let’s focus on finding $X

2 Likes

Right now, the cost of a 60k POKT’s Node is around 35% cheaper than a 15k POKT’s Node at the beggining of the year. I understand when you say a fewer Node would lower the “entry barrier” but as of now even this increase makes it eve cheaper than the original format. And still, we have to chose what we want, all decisions has its trade off’s and I don’t see the “entry barrier” right now as one of them.

1 Like

Not an economics expert, but I don’t think increasing the required stake amount too much is a good idea.

Right now it seems like getting x2 or x3 the current required stake amount is accessible, but I am speculating that once this gets announced price will go up and it will be a higher cost to pay (especially) for small node runners. I tend to think that increasing it too much will only benefit large node runners.

We need to create demand for pokt in order for the price to go up and while increasing the stake amount is one way to do it, I do think that the other solutions listed should have more weight. Not against increasing stake size but be careful with how much it is increased.

Again, not an economics expert so I might be wrong and price does not end up going up that much. Pure speculation from my side.

2 Likes

You’re correct, it is cheaper right now, but we have to think ahead. I’m sure changing the min stake amount is not something we want to be doing all the time, seems like a very, very disruptive operation. I think we’re all hoping and working towards an increasing POKT price, so we have to consider what happens at $.50, $.75, $1, etc.

My thought is, if we implement weighted staking, then a node runner can stake any amount, now or in the future. It would be a valuable network feature to have regardless imo. Then we can use WAGMI to continue to tighten rewards beyond the 50% target we have now, making it unprofitable to run at 15,000. And just let node runners /the market decide how they want to allocate their stakes. In addition, this would also encourage node runners to hodl their rewards instead of selling them, since adding to their stake increases their earnings.

And if someone still wants to enter at 15,000 and run at a loss, that’s a choice they can make. And it might be a reasonable choice - if you don’t have the lump sum on hand for a 40,000 POKT stake or don’t want to tie down down that much cash fine, you can basically pay your infrastructure costs out of pocket monthly , earn POKT, and get to a profitable stake eventually with your earnings.

I guess all that to say weighted staking gives the network a lot of flexibility in the future , increasing min stake does not, quite the opposite, it locks us into a situation that may come back to bite us in the future.

4 Likes

I agree that the weighted staking if technical possible is the better solution for now, in terms of reduce infra costs. Also, it would be a natural possibility of compounding. I.e. if you have a c0d3r Node and you can leave your rewards there to increase your Node size and, therefore, get more rewards, you eliminate the idle time gap to get another node.

3 Likes

Would increasing the minimum stake be retroactive, or would it only affect new stakes?

Something to consider re decentralisation if this is to be applied retroactively. Based on my research there are 310 unique service domains (note domains, not urls) as of block 60745. Working on a hypothesis that each unique service domain represents a unique node runner entity, we can say there are approx 310 unique entities running nodes. Just a hypothesis and not 100% accurate as we know there are entities with multiple domains.

Of those 310 unique service domains, there are 86 service domains with a single staked node. Or 27% or all node running entities. If the minimum stake value is doubled and applied retroactively, these node runners would no longer be eligible.

There are 36 unique service domains with two staked nodes. Combined with those running a single staked node, this represents 39% of all node running entities. If the minimum stake value is tripled and applied retroactively, these node runners would no longer be eligible.

If my hypothesis and reasoning are correct, this would have the effect of further centralising the network

This is just my own research - I thought it would be valuable to put some data against the proposal to raise the stake values, and happy for it to be critiqued.

6 Likes

@SCH thank you, that is great information to have. The stake increase would have to be retroactive if the goal is reduce the number of nodes. I would think that once the parameter value is altered, any nodes that fall below would just be force unstaked, just like you would now with a node that falls below 15,000 min stake.

I know this is preliminary discussion, but I had a thought while mowing grass. If the DAO decides to go with the weighted stake option, it would be an excellent opportunity to introduce some weighting for quality, and trigger a quality arms race amongst node runners. A “quality” rating would be calculated per node, and an average per network per month. If a node runner consistently serves requests 10%,20%,30% below network average, that feeds into the formula and their probability of being selected for a session increases. This quality rating could be as simple as average response time. If the weight assigned to the quality portion is sufficient, you could see node runners begin to invest in higher quality hardware instead of higher stake amounts, which would be just as valuable. Also, not investing in keeping up with at least the average network quality could leave your node less likely to be selected for a session, and therefor less profitable.

1 Like

v1 shifts from a mint per relay to a mint per QoS score model, so this is already in the roadmap.

Yes. Good catch. Grammarly changed the meaning of that.

Right, and that’s excellent. But v1 is out in the distance with no definitive launch date, and adding some basic quality incentives now would create a smoother transition towards v1, and prepare the node runner base for that transition by encouraging continuous improvement. Honestly, it would be a great marketing talking point as well - built in incentives for high quality service. I do get that it’s completely outside the main issue being discussed here which is reducing infra costs, and maybe needs to come as a separate proposal, but it seems like a great opportunity to implement since the team would be working on and testing that code anyway.

Edit : would there be the possibility for some monetary incentives for the core dev team from the DAO for an accelerated implementation of at least the basic stake weighted selection option? Say get it done in 90 days, you get 1 million POKT, something like that.

1 Like

To be clear, I’m agreeing, and noting this is the intended direction anyways.

1 Like

I see flows here if node count has been reduced based on Weightage staked. Currently most of nodes are being hosted by 3rd party services like Coder, Poktpool, Thuderstake etc… Based on weightage staked, most of these big node runners will stake with upped limits as they have power (enough tokens) to do so. In such case, i assume almost 80% of nodes will be capped at upper staked limit.

I believe in such case, rest 20% node will “never” get any session. On theory its all about probabilities, but in practical those min or low weighted nodes will starve for session. You guys are assuming based on probabilities that low staked will get session. But this can be proved only once its implemented. As being Software developer, i see “starvation” problem here. This is just what i believe based on knowledge.

Another criteria is, even though with above flows, if node counts reduced based on weightage stake to reduce infra cost, then i believe inflation should be reduced to same percentage. I read in between line that Inflation will be controlled based on WAGMI. But if node count is being reduced on emergency basis then inflation should be also control immediately and should not wait for WAGMI to reduce it on later point.

Consider this example : Inflation control in alignment with "reducing node count"

It’s a valid concern, but I think we have to wait and see the actual proposal and formula being used to calculate the probability of being selected for a session. It may not necessarily be linear, as in 150k stake gets 10x more sessions than 15k stake. That’s a discussion to be had on the proposal.