PUP-15: GOOD VIBES (Updated Version 1.1) - A New Economic Policy for Pocket Network

Have we realized that with 15k servicers, and these types of APY goals, servicers will be squeezed to only generating 10.57 POKT a day? This is only 25% of what a servicer currently receive daily.

This is pulled from the GOOD VIBES spreadsheet. This goal is set for servicers to generate 10.57 POKT and validators to generate 407.78 POKT a day.


What research has gone into what the servicer node landscape will look like if servicers are squeezed to only receive 10.57 POKT a day?

By paying servers 10.57 POKT a day, how many servicers will an individual have to own to at least break even with infrastructure costs with only $41 worth of reward a month?

What type of infrastructure environments will likely be needed for servicers to make the same APY as validators with only 10.57 POKT per day and high infrastructure costs?

How many individual node runners will not have enough POKT for a validator but won’t have enough servicers to break even with 10.57 POKT a day?

Yes sir. The goal is to reduce the number of nodes, so rewards have to be reduced to incentivize that. It’s the inflated rewards that allow 47,000 nodes to exist today, so rewards have to come down in order to address over-provisioning . The other option is to keep minting and wait for the token price to drop to a couple cents.

I would argue there is no break even, regardless. It’s false income. There’s no money coming in from anywhere at the moment. As a node runner, you can pay for infrastructure by diluting your stake with high inflation, or you can pay for some infrastructure out of pocket, stop diluting your staked assets, and watch the token price rise as supply gets reduced, and later again as monetization kicks in.

Many. That’s the point of the proposal, to drive down the number of nodes to the target of 15,000. Pools will become a very viable option for these folks where they can benefit from economies of scale. It will greatly increase the overall efficiency of the network.

It’s no different than increasing minimum stake. If we go to 45,000POKT min stake, everyone below that gets unstaked and moves to a pool. Except adjusting minimum stake comes with pitfalls. Instead, PUP-15 creates the economic incentives to run 5-6 nodes in order to be profitable, while allowing for minimum stake to remain the same for future flexibility.

So with this economic model… running servicers always comes at a loss compared to validators because the amount of infrastructure costs and time that servicers require. When you look at the chart, servicers never increase in rewards the lower they go, so they are pegged to an APY loss until the economic model changes entirely.

Validators though… they need servicers to generate their reward. They lose APY if servicers do not do their jobs at a loss.

So whales who are validators, will want to keep some of their POKT in servers at a loss (APY wise) so they can keep their validators generating all the real rewards.

The servicers are always meant to be generating a loss so that only those who have validators will have the capital to run servicers.

I don’t know what to call this economic model. Servicers are designed to run at a loss so only those with validators run them. Am I getting that right?

So if you look at the graph, at 15,000 node the APY lines cross. Once we go below 15,000 nodes, it becomes more profitable from an APY standpoint to be a servicer than a validator. Once you go over 15,000 nodes, it becomes more profitable to be a validator than a servicer. This is the mechanism that will balance the network around the 15,000 node target.

Servicers can run at a loss, but most likely they will either just run enough nodes to be profitable, or move to a pool. Whether we raise min stake to 150,000POKT, or tweak the economics so you have to run at least 10 nodes to be profitable, end result is the same. Weighted stake will have the same effect once implemented and should repeal PUP-15 once approved.

Loss or profit is a function of token price though. 10 POKT per day might put you well within profitability range with even a few nodes if token price increase by even just 10 cents. And a reduction in token supply and sell pressure coupled with a huge increase in demand - all of which this proposal will create - should have a very positive impact on token price.

I’m hearing a whole lot of “people will move to a pool” around this, but I don’t think it accounts for the fact that pools cannot build entirely around high stake validators for two reasons: it takes 21 days to unstake a node (including validators), and you’d potentially have to unstake a 150K validator to allow 1K pool participants to exit.

Stake weighting servicers works better for pools, because you can treat servicers like currency denomination: 10 100K stakes, 20 50K stakes, 50 15K stakes, etc., to provide the liquidity structure needed to let participants move in and out.

For example, in the last couple of tranches with poktpool, low returns have driven up our unstaking amount. When stakers request an unstake, we must honor that request. If we had all 150K staked validators, some stakers would be force unstaked against their will to cover the request of smaller stakers wishing to exit.

Pools themselves are a notable factor in the dramatic rise of node count, because they’re filling up servicers with small stakes. With Good Vibes, pools may choose to stake a handful of large validators, but the liquidity requirements prevent us from using megavalidators fully. Those largest validators would mostly be whales who do not have third party considerations around staking.

1 Like

Certainly stake weighting is the ideal solution. This proposal only aims to act as a stop gap , since the dev team indicated it will be 6 months before stake weighting can be production-ready. Maybe we can get Thunderhead on it. Just kidding. But not entirely.

I certainly agree that pool operators will be faced with the task of making some decisions, as far as balancing reduced infra and administrative costs with the need for liquidity. It may end up being 80% in validators, 20% in 15k servicers, those are business decisions that only pool administrators can make based on their specific needs, market conditions etc.

Ultimately, this proposal only creates an incentive. Whether the network chooses to move in that direction or not, is entirely up to the network.


That is a illusion if you aren’t also taking COST into account. Validator APY means nothing if the servicer APY is not enough to cover costs on it’s own. Even if a validator decides to unstake to become run servicers because the POKT APY is better, they are at a loss at the end month when comes to the amount of USD that they put into infrastructure vs the amount of POKT that was generated.

This is why I asked:


If I were to run 15k servicers on OVH, a bare-metal rental service, I can get the most bang for my buck. Running bare-metal is the most efficient way to cut node costs… though it takes much more work because you aren’t in a dynamic cloud.

So with the most efficient servicer network possible with 15k servicers, this is what it could require if entirely on OVH.

With the most efficient servicer infrastructure possible with 15k nodes, you are looking at $554,435 of monthly costs.

Now the question is, how much rewards would those servicers produce? 4,757,438.4 POKT with a price of 12c bring a value of $570,892.61.

If one individual, in the most efficient way possible, ran the ENTIRE servicer economy, they would only generate $16,457.61 in PROFIT a month. That is an APY of .61% when taking COST into account with the most efficient servicer network possible.

What will the quality of our RPC service be if the entire profit of running servicers is has an APY of .61%? What single individual will run the entire servicer network for a monthly salary of $16,457.61?

That is of course if the price doesn’t dip beyond 12c. At 10c your APY is -3.48%.

This is why only whales, who can take the losses, will be willing to run servicers. They will run them at a loss, but it keeps their validators generating rewards.

With this scenario… how are whales going to decide how many servicers each of them should run to keep the rewards coming? Some whales may not pay to run any servicers, which is a burden to the network.

Is this where we trust that everyone will do their fair share and run robust servicers, at a loss, and add up to 100 new chains by the end of the year?


We need to take this seriously… Just saying “pooling” and “efficiency” are not reasonable responses. This economic shift absolutely leads to the outcome which @shane has outlined. At best it will be some type of oligopoly pricing model with a Nash equilibrium. But with some of the validator whales refusing to support the network by running their fair share of altruists, who knows where that number will fall?

Remember… the desire to reduce node count to an arbitrarily chosen number (15,000) is not because there are too many nodes. It is because of the expected result on price and validator stake.

Note: It is already more profitable to run a validator which is also a servicer than to run a servicer alone. Yet the network has not responded to that fact. Just because two lines cross on a spreadsheet does not mean that they will cross in the real world.


I just want to point out, everyone has been taking much bigger losses, for a while. In the past 30 days, token price dropped from 38 cents to 12 cents. A node runner with 15,000 POKT and a node optimistically earned around 1500POKT for the month, while also losing $3,900 in wealth on their stake. There is no profit.

There is no reason to believe token price will remain constant if nothing changes. Staying the course means continuing to mint millions of tokens per day and driving the token price further into the ground. On the flipside, reducing inflation, increasing token demand and decreasing infra costs to reduce sell pressure is guaranteed to positively impact token price.

So do we want our node earnings 60 days from now to be 30 POKT * 5 cents/POKT, or 10 POKT * 15 cents/POKT. The answer is pretty clear. Reducing inflation and infrastructure costs is the right way forward for all of us.

Certainly. And if the network chooses to not respond to the incentives being implemented here, nothing changes. This proposal only introduces an incentive. The network can choose to take it, or not, it is not forced upon it.

GIven that the cost to run a validator with hundreds of thousands of pocket is so much cheaper than running dozens of servicers. We can probably expect that the number of validators will exceed the parameter set threshold. Even though the reward alloaction would be less on a percentage basis, the net would be significantly more. This would give servicers outsized gross rewards.


Beyond just criticism, I do want to offer some suggestions that could help us tackle similar goals to GOOD VIBE. We can make changes using existing parameters with the following:

  1. Updating block producer stake ASAP. (Enough to address the security concerns and reduce servicer nodes)
  2. If we want to reduce nodes further, increase the minimum stake to encourage node consolidation (grace period suggested here may be required).
  3. Release the feather client (drastically reduce costs).
  4. Update WAGMI to account for the costs saved with the feather client. (it could be a significant %)

Those are suggestions that I think we can do one step at a time without changing the economic model of the system.


Thanks for the follow-up @adam and for the suggestion that I read the post from Hal Press - I read it and it was very good. I also reread your thesis in PEP-35. However, I’m still not completly following your assumptions/logic.

I understand optimizing for total network costs to mean paying less in rewards while still building a scalable and secure network. This make sense because like Hal Press wrote:

I hope nobody is worried that we might be close to Pocket’s market cap potential at this point :grimacing:. And given the current supply, I’m not sure the rewards / inflation should be a concern - now anyhow. But that asside, if LeanPOKT reduces node running costs as signicantly as it seems it will, would that not also make it possible to reduce rewards (through WAGMI) while still allowing node runners to be profitable? And, if so, would that not also lower the total network costs?

I’m also curious about your comment here. Networks in general have gotten consistently more cost efficient over the years as a result of innovations and optimizations. Here is a good read on that if you’re interested. Why would we assume lowering costs through optimizations will only happen this one time with LeanPOKT?

I vibe with the motivation for GOOD VIBES for sure :slightly_smiling_face:. But it introduces a lot of new variables that I belive could also introduce a lot of unforseen risks. In my opinion PEP-35: The v0 Optimization, LeanPocket seems to also address lowering the total network costs with a lot less complexity / risk. There is a good chance my old brain isn’t seeing things as clearly as yours. So, I’ll keep an open mind, but I’m not there yet. Anyhow, thanks again!

This is fair feedback and I’ll go back to the lab looking for a better curve to accommodate the needs of servicers at the low end. Servicers can’t be left out to dry with unprofitable node operations.


Light client would lower network costs and would allow us to decrease inflation, but that’s all speculation for now until there’s a proposal passed. Further, it remains speculation on how much cost savings will be realized or what schedule that would be delivered on. I do not want to be at the mercy of future tech that doesn’t have a clear defined release roadmap.

My argument is that you’re only solving for costs at the current node count, not necessarily a future node count. If node count grows at the 7%-13% per month it has been over the last 6 months, that will quickly outstrip the estimated costs savings provided by the light client or future developments. While I realize, in general, costs of tech decreases over time, we cannot wait for those cost savings to be realized.

My thesis is that node growth will outpace cost savings, which is how we got where we are today. I don’t want to repeat this mistake down the line.

1 Like

I think if you remove the .15 premium for validators it looks a lot better for servicers. I don’t think it’s needed personally, the premium I mean, validators will have a lot of incentive to consolidate just from infra savings.

1 Like

Another option for community consideration: PUP-16: The Phase Plan to network security and optimization

I updated the GOOD VIBES proposal due to some feedback from @shane @BenVan and others. The TLDR is that we’ve introduced concepts around node costs to understand profitability of servicer companies in the Pocket Network ecosystem. While servicer rewards are greatly reduced under this new structure, the effective profitability of businesses that validate is higher than servicers above the Minimum Viable Node Count.

Edit: Looking at the data, per servicer rewards remain fairly steady (around 38-45 POKT per day) throughout the curve.


These changes provide for additional sustainability for those who see too much risk in validating and can protect the downside of pools.

Feedback is appreciated.


We just published GREAT VIBES as an ongoing research effort to iterate on GOOD VIBES as well as account for some of the feedback we got from the community.

Feedback on PUP-15+: GREAT VIBES - A Sigmoid Based Economics Policy for Pocket Network would be greatly appreciated, after which we can turn it into a proper proposal.


In light of the more promising PIP-22 - Weighted staking, I am asking that we hold off on a vote on this proposal while I work on a new proposal that would incorporate PIP-22 elements from a parameter perspective.

As much as I like GV, PIP-22 is a more perfect approach. PIP-22 is potentially weeks away from implementation and would make PUP-15 unattractive as a stop-gap measure as PUP-15 would take weeks to implement - only to be unwound. It would not be fair to the node community to give them that sort of whiplash.

If core dev decides PIP-22 is infeasible or the time estimate for implementation proves to be too long, I’ll ask for this to go to a vote.


It is totally true! I work for OVH in Canada, so if you need to have someone working aside from you, just let me know. I’m in the commercial department, so I can help you to have the best delivery time, and the best configuration available for your POKT projects. ricardo.pinilla@ovhcloud.com

1 Like