PUP-17: The Phase Plan (a progressive plan for network security and optimizations)

This is just an arbitrary point on the good vibes curve.

Why would we do this and disregard a system that allows for the market to pick a reward distribution that converges on a cost minimum?

We could also treat this as a first step and have a future proposal which addresses a longer term system.

I am by no means an expert on the topic so I will just be sharing thoughts and initial impressions.

I agree with the validator rewards increase since that is important for the network security.

The part that I still have my doubts on is in the minimum stake increase. At first glance, my impression is that this will only benefit large entities and will push out smaller ones. Therefore making the servicing network a bit more centralized.

For instance, if a single 15K node is being profitable right now then why do we want to add the burden to spend an additional 1.5K-2.5K USD (at the moment of writing) just to keep it running? For some people that amount is trivial but for some it is not, especially during the economic conditions the world is currently experiencing. And if the node is not being profitable right now then my assumption is that it will be shut down eventually, therefore reducing the node count. Therefore, I am speculating that the economic conditions by itself will make node runners (especially smaller ones) to keep going or to shut down.

Right now I am against the stake increase but since I am not an expert, it is likely because I have not understood the whole picture (yet). In this case, I would be willing to spend some time to be illustrated in this area.

1 Like

My understanding is if a node runner is staking in a pool, the share of the pool and the rewards from that pool would remain the same.

Only if a node runner is staking on a domain they control, or with a node runner service would they need to restake with a higher amount.

nb: The service rewards would double, if the minimum staking requirement doubled.

Generally speaking, this is a pragmatic approach to solving this issue.

I’ve been debating with @shane on the best path forward. We’ve come to understand that everything will be a tradeoff - there’s no right answer here.

I have a few underlying concerns, which I will address in the following sections. I also have many open questions that I’m sure the community is openly asking.


The benefit of GOOD VIBES (GV) is that we provide a predictable box for node runners and validators to thrive. The question is: do we prefer a “box” or a more laissez faire approach.

My concern is that with a 21% (or 27%) Validator Allocation, node runners will not know the outcome until things shake out. What if the common sentiment is that servicing is still superior in rewards? What if people make the wrong call? Node runners are left with a game of chicken where they are incentivized to sit on the fence. Why would I act until I know the outcome?

The Right Number

I’m concerned that picking a number based on some high level assumptions of how people will act is too risky. The lack of predictability is why GV could be an alternative worth considering. No matter what people do, I, as a node runner, can predict the future with relative certainty. This may provide more confidence to participants.

Servicer vs Validator Economies

This proposal does a better job of discouraging a validator economy. A lack of true validator economy is attractive to some parties. I acknowledge that fact. Do we want validation to be a feature of service providers or an entire product? When we need to switch back to servicing, how painful will that transformation be? It is hard to say at this point, but I trust contributors to do what’s right for the economy.

Further, are whales interested in running service nodes over “easier to do” validation if the rewards are in similar ballparks? When does that begin to eat into the underlying service Pocket provides?


There is a fair bit of feedback on GV that the proposal strengthens the narrative of a “POKT FED”. While the execution of that change is the responsibility of the Foundation, I’m confident that the Foundation will act within the bounds of the proposal. These words may not provide much comfort, but there are checks and balances built in to protect the community from abuse. On a tactical level, I believe after the scariest implementation period, changes to the curve or the GV factor should be DAO decisions.

At that point, the effective difference for GV and this proposal is very little from a governance perspective outside of regular parameter changes that would occur with GV as determined by a DAO voted curve.


This proposal doesn’t properly address the issue of inflation, which Shane is aware of and he is addressing (I believe).

Without a concrete plan, I would have reservations about this proposal.


  • Add in a component that addresses inflation without leaving it ambiguous.
  • Publish the math of the post-Phase 1 outcomes for servicers and validators
  • Delegate the responsibility of a grace period to the Foundation or have a concrete plan to execute on.
  • Further define the sub-phases of Phase 1 and 2. Is there a correct order of operations?
    • I’d suggest that the validator change should occur before the minimum stake change.


Until we truly get economics and network costs under control and find equilibrium, we will be forced into constant compromises to bootstrap the network to where it needs to be. This may be necessary, but we need to recognize what it means: costs to the holders of the token.

For example, if we’re going to support more nodes than is strictly necessary to run the service, we’re going to have excess inflation and unnecessary market pressure. If we choose to support more than is strictly necessary, we’re all agreeing to bear that cost. In some scenarios this may be worth it and in others it may not be.

In my personal opinion, it’s best to try to get as close as we can to market equilibrium today rather than continuously kicking the can down the road. These changes need to be part economics (inflation) and part costs (light client, node count).

Regardless of GV or Phase Plan, we need to understand that these are near term fixes to long-term problems.


1 Like

I agree. I think in that respect GOOD VIBES in its original incarnation is superior to v1.1. It took bold action to get us to where we need to be. And that’s what we need, bold action. We’ve made this mistake before (see PUP-13) , and the fact we’re sitting here mid-way through the adjustment schedule looking for other solutions is proof. Sometimes progress is made with small steady steps, sometimes it’s made with leaps. It’s time to stop being afraid, stop hedging, and make a leap forward.

The future of Pocket is bright - we just need to find the courage to lift our head up, reach out and claim it.

Thanks for the response @adam. It’s been great talking through our proposals and finding the advantages and disadvantages of each.

I do not see the Phase Plan introducing risky variables into the Pocket ecosystem. Updating these parameters does not incur any more network risks than what we have today, which I personally think is a good thing. Pocket’s core economic incentives are the same, just with parameter changes to improve security and consolidate nodes.

I do not feel like Pocket needs an economic box. The complexity of GV gives me much more pause than simply adjusting network parameters that were built into Pocket for these times like these. I personally don’t feel Pocket economics need to be re-engineered, parameters just need to be updated.

Why would node runners decide not to take advantage of all those rewards to say in servicing? There are less infrastructure costs and more consistent rewards with being a validator… so why would the network ignore those rewards to only stay as a servicer?

We currently don’t have issues with folks upping their nodes to above average to be a validator, and I don’t see any reason why that would change if validation rewards are increased by 21x.

This is the nature of any free market. I don’t feel Pocket needs an economic box that ensures all decisions, good or bad, have the same outcome. To be decentralized there has to be the freedom to make bad decisions. If some folks aren’t wise with balancing their validator and servicers deployments, other folks who figure it out will take their place and generate better rewards.

I feel keeping Pocket’s economics decentralized and competitive is important.

The future can’t be predicted with any decentralized ecosystem. Pocket has been thriving since the launch of mainnet without explicit predictability. I think we need to be wise with making updates to our parameters, but I feel there is far greater risk with putting all our eggs in one centralized plan basket.

GV v1 was close to being put up for a vote and it had notable oversight that would have crashed the network’s economics. GV v1.1 addressed the oversights I brought forward, but there are likely other oversights because it’s trying to put the entire ecosystem in an economic box where the focus is on validation.

These are great questions and ones I’ve been struggling to answer if we shift into a validator focused economy. Servicers are what make Pocket’s service great, so I think it’s important that the economic focus always be servicers and just use validation to secure the network.

Thanks for that clarity on where the DAO fits in. I personally find the curve (aka: GV Factor in the spreadsheet) very hard to predict or explain. I think that will be one of the greatest challenges to a GV like economic model… very few will actually understand how it works.

Correct. Because this proposal isn’t changing how Pocket’s economics work, inflation plans can be introduced without issue.

The nature of this proposal is to address the two most pressing challenges, which is network security and infrastructure costs.

I greatly appreciate the suggestions. I am actively working on mapping out a more indepth economic model that outlines the results of the Phase Plan. I’m also looking to include weighted stake (PIP-22) as the consolidation mechanism instead of increasing the minimum stake.

There are some fundamental inflation changes that weighted stake introduces, so new models need to be created to map out the impact. I plan to release my finding soon.

Thanks for all the feedback :slightly_smiling_face:

1 Like

I’m confused what you mean here. GV in it’s original incarnation would have crashed Pocket’s economics. It was updated to v1.1 for a reason.

Personally I disagree. I think if we’re to enact change, we should plan for where we want that change to take us, not for where we are. If the plan is to boost token price by reducing sell pressure, increasing demand and reducing token supply, and if we believe in that plan, then reducing token rewards significantly makes a lot of sense. If we plan the whole thing around bottom of the market current 12 cent token price, then we don’t believe in the plan delivering - so why implement it in the first place.

But, having said that, I recognize it’s perfectly possible I’m just too bullish, I’ve always had strong opinions - that’s why you need multiple voices, come out with a balanced solution.

1 Like

I’d like to start by saying I greatly appreciate everyone’s time, effort, and energy with all the recent proposals, revisions, and comments. I have an unbelievable amount of faith in our community/the Pocket team and am excited to ride my PoktRocket to the moon in the near future. With that being said, I wanted to share my outlook on recent proposals… and i apologize if this is not posted in the appropriate thread.

Respectfully to all authors/commenters and from a non-technical view, I could not justify the need for PIP-15+'s complexity. I believe a combination of PIP-22 and this proposal (PUP-17) addresses all current concerns I am aware of (security, infra costs, growing node count, reducing sell-side pressure) while maintaining community morale and (hopefully) driving increased buy-side in the short/long term.

My only comment/question pertaining to a hypothetical combination of 22 and 17 is why increase the minimum stake with PUP-17 to 30K rather than let human nature/desire drive the average stake per node up by itself?

In my opinion, with proper communication to the community on the details of a hypothetical proposal (combination of 17 & 22) most pokt holders will want to lower their avg cost per stake by consolidating nodes while still earning approximately the same rewards with weighted staking (obviously absent PUP-17’s reward % reduction). PIP-22 should result in overall node reduction, increased total staked %, slightly increased security of the network, and slower node growth while nodes are barely profitable.

Once the fair value of daily rewards points to profitability, I’d see node growth increasing as token holders look to increase node count for diversification between regions/chains.

I see PUP-17 driving a significant amount of competition to become a validator, resulting in more staked tokens, slower node growth than we have today, and a more secure network. In turn, this would force some current validators to be converted to servicers, which will either drive up the buy-side pressure to continue competing as a validator or allow the newly over-staked servicers to experience the weighted-stake rewards of PIP-22 and not force any nodes to unstake and restake with minimum servicers amounts.

My understanding is the long-term vision of PN has always been to service billions and trillions of relays per day with hundreds of thousands of nodes in the network. I don’t see a forced reduction of the node count by increasing the minimum stake as a positive step for the network/community to take.

Id suggest letting the individual holders determine how much they want to pay monthly in infra fees based on their node counts and then continue to reward users who lock up 100% of their available tokens. Leave it up to the token holders to drive the long term goals of the network. Thanks for reading this far.

-Kadow (I’m a forum newb… but I can log in :blush:)


Thank-you for the comments and feedback. Working on these issues has actual become a full time gig for myself as I really feel we need to get this right :sweat_smile: Thank you for the support.

I’m very confident we are close to finding the proper balance and action plan.

I’m actually working on a modified model that uses weighted stake (PIP-22) for consolidation, instead of upping the minimum stake. :point_down:

Those are exactly the goals :slightly_smiling_face:


@shane glad to hear it. We are all here to help

1 Like

In the spirit of moving things forward quickly, I’d like to draw attention to PUP-19 which is proposing an immediate increase of the validator reward from today’s 1% to 5%.

While upping the validator reward alone doesn’t significantly impact the number of nodes on the network, it starts the ball rolling on #1 in the Security Phase:

Because PUP-19 is so closely aligned in spirit to the Phase Plan, I’d recommend allowing PUP-19 to be considered the first step in a phased approach. Though PUP-19 was only just published yesterday, the concept of upping the validation reward has already been heavily discussed here, so I would consider PUP-19 an extension to this conversation.

There will still need to be other steps to address node consolidation and inflation balance, but starting with block producer reward is good start. I’ve modeled out where validator and servicers balance out in terms of rewards with an increase of validator rewards to 5%. You can see my PUP-19 Impact Model.

NOTE: There are major risks with folks aping into validation, since it by nature locks ups larges amounts of POKT. The PUP-19 Impact Model should be taken as theoretical. But what can be seen is how the change the price can quickly make validation unprofitable compared to servicing. There will need to be further consolidation and inflation proposals to address these issues in the future.

As a first step to the spirit of the Phase Plan, please check out @nfahenry’s PUP-19 as a start to a phased approach.

1 Like

I’m in full agreement with @Shane here. PUP-19 is meant to be a starting point for other proposals, and not meant to supersede or replace the other proposals out here (and definitely not PUP-17). Shane’s proposal directly impacted the drafting of PUP-19, and I’m glad to see that he has worked it into his model as such.