PUP-20: Increase Node Minimum Stake


  • Author(s): Henry Habgood, Patrick Linden, PJ Forster
  • Parameter: StakeMinimum
  • Current Value: 15000000000 uPOKT (15,000 POKT)
  • New Value: 30000000000 uPOKT (30,000 POKT)


We propose increasing the minimum service node stake from 15,000 to 30,000. This simple shift can occur on a one-time basis and will not have any impact on gross ROI earned by service nodes on a per-POKT basis, but will help to quickly reduce the number of service nodes on the network to a more manageable level.

Further, this shift will greatly improve net rewards to node runners and reduce overall infrastructure costs to the protocol. If the number of nodes on the network were to be halved as a result of this proposal passing, it could reduce excess infrastructure burden by over $3m per month (assuming a reduction of 21,000 nodes at a hosting cost of ~$150/node).


There have been many discussions surrounding the best way to achieve the goals of the network while reducing excess waste due to high infrastructure costs of running a Pocket node relative to the rewards being generated. This proposal seeks to build on prior proposals and provide a clear and easily achievable solution to our current problem while limiting the impacts of forced consolidation/unstaking. Just as important is that this proposal can be passed without the need for a moratorium on the 21 day unstaking period due to the phased implementation.

In our view, the reason that variables such as StakeMinimum are considered governable is because they are meant to be used as levers in the Governance process to adjust the Pocket economic system. If we don’t first attempt to use the variables as levers themselves and instead move toward building increasingly more complex systems of managing the protocol, we can quickly find ourselves in a place where the complexity of adjusting the protocol can outstrip the ability of many members of the community or DAO’s ability to understand or effectively take advantage of those changes.

Most discussions surrounding changes to the StakeMinimum parameter have ranged from increasing the value by 100-400%. Increasing the parameter by 100% falls at the bottom of the range of discussion and likely outside the final range that it will need to be adjusted to, but that adjustment will provide real world data on the impact of StakeMinimum adjustments to the protocol, which is ultimately more impactful for future governance decisions than models which have no data on real user behavior with which to draw from.


The new parameter value change would allow for the consolidation of nodes to a point still above the current optimal range of ~15,000 nodes. This consolidation goes a long way to improving the net ROI for node runners while still maintaining an adequate buffer of excess nodes in case of unintended consequences (like greater than expected unstaking/consolidation) as a result of this or other proposals passing.


Doubling the minimum stake required for a service node is a rational increase as it provides a clear benefit (reducing node count) that utilizes preexisting variables to address current issues surrounding overcapacity on a servicer level.

The timeline outlined below, which is a phased plan, allows for the gradual adjustment of the minimum stake, providing node runners of all sizes with the ability to slowly grow their stake over time. Additionally, it gives the DAO the opportunity to study the impact of the phased increase and the lag time between increases allows for ample time to adjust the increase to the minimum stake if there are adverse (or unintended) consequences of the proposal. More importantly, it does not create a complex change (or code change) to the current protocol that could have disastrous consequences to unwind after implementation.

This proposal builds on the back of the many similar proposals which call for an increase in the minimum stake. One of the core problems with these other proposals is that they require making complex changes to an already complex system, and the range of adjustments being made will make it difficult to actually monitor and score the success of the system. Further, asking a community of node runners to participate in a complex economic experiment that requires advanced math skills to perform optimally in may be an even more restrictive barrier to entry/performance than the comparatively simple decisions necessary to either acquire more POKT or consolidate nodes to keep up with an increasing min stake.

Dissenting Opinions

To Be Added


The update can be made immediately, however doing so would dramatically reduce the number of available service nodes on the network to below an acceptable level. In order to provide node runners with a clear timeline for this transfer, we suggest a phased implementation that would increase the minimum required stake by 2,500 POKT every 15 days, effectively doubling the minimum stake over the course of 90 days while having an immediate impact on node count and net rewards.

Not only would this timeline allow node runners who run multiple nodes to consolidate in an orderly manner, it would also reduce the burden on single node runners by allowing them to ‘earn in’ to this increase. Initial estimates show that rewards earned over those 90 days would supply ~30% of the additional POKT required, greatly reducing the amount of additional investment required for someone running a single node.


Copyright and related rights waived via CC0.

1 Like

The update cannot be made immediately. It is dependent on the activation of the non-custodial staking feature, which is bundled with the removal of burning when someone falls below the minimum stake. This feature is set to be activated in July. The proposal should be amended to state that the phased increases in min stake should start only after this feature has been activated.

1 Like

I have several objections to this proposal and feel it is inferior to every other proposal on the table at the moment related to reducing node count (excepting PUP-17 which like this proposal proposed to raise StakeMinimum to 30000 POKT)

Objection 1: PUP-19 is already in the works and has overwhelming voter support to pass in the next few days. Once turned on, it should serve as a strong driver to incentivize consolidation. Give PUP-19 a chance to do its job before submitting and passing a MUCH more heavy handed system change

Objection 2: raising proposer-allocation to 5% as per PUP-19 can be implemented as soon as vote is confirmed. StakeMinimum, on the other hand, cannot. Changing this parameter setting is a hugely complex undertaking. It would probably take two months to accomplish. Everything must be precoordinated with all node runners and achieve a very high level of pre-modification compliance among the group prior to effecting the change. PUP-19 could be implemented, the resulting system behavior studied (ie degree of consolidation that took place), go back to the drawing board and raise proposer allocation even higher if 5% wasn’t enough, vote on the new value, implement it and study the result of that new value all in the time it would take to change StakeMinimum. TBH, if PIP-22 and this proposal were to pass voting on the same day, my bet would be on PIP-22 to get implemented first.

Objection 3: Raising StakeMinimum has the potential to cause the network to crash it implemented incorrectly. No other proposal on the the table (PUP-15,19, PIP-22,23) run any such risk. Right now there are only 15 nodes in the network that are at or above 30k POKT staked. If StakeMinimum were simply switched to 30k without all the above precoordinated effort, the network would be reduced for a time to only 15 Servicers, 15 validators. Perhaps enough to run a billion relays. I doubt it.

Objection 4: This proposal offers no improvement to the network; it is at its core, simply a “wealth redistribution” mechanism - change a parameter setting to make life easier for the people who run multiple nodes at the expense of people who run a single node. What is fair about that? Every other proposal on the table seeks to make an improvement to the network with consolidation being a side benefit. PUP-15 and 19 seek to bring better balance to validator incentives which currently are too small compared to servicer incentives. PIP-22 and 23 seek to bring efficiency to multi-node players. All four of these other proposal make sense to consider incorporating whether the price of POKT happens to be ten cents, a dollar or ten dollars.

Objection 5: This proposal defies all sound economic theory. It is a “make-believe” fix. It is like when Mexico has spiraling inflation and substitutes one “new” peso for a 1000 old pesos without solving any of the underlying economic problems and thinks that is going to be a fix. The most likely outcome of changing StakeMinimum to 30,000 without changing underlying inefficiencies and assuming macro environment stays unchanged will be, after a few months shakeup period, to drive price of POKT down to 6 cents and nodes back to operating in the red.

Objection 6: In governance, incentivizing a behavior (in this consolidation) is vastly superior to forcing a behavior. In what context is the opposite ever true. Mandated behavior ALWAYS leads to less efficient system than putting the right incentives in place and letting free-market behavior take care of the rest. PUP-19 and PIP-22/23 have VASTLY different mechanisms to incentivize consolidation. It does not matter: because they are incentive-based the consolidation that takes place will be efficient (consolidate where it is most needed and makes most econonomic sense; don’t consolidate where it doesn’t make economic sense.) Either or both are better than amdating consolidation even when it does not make economic sense to do so.

Objection 7: Case in point. This proposal INCREASES inefficient reliance on expensive custodial service providers instead of decreasing reliance. Let me illustrate this hypothetically since I do not know the actual numbers. Suppose there are 1000 node runners who each one run one node. They spent $500 to upgrade the hard drives and memory on their gaming PC to run their own node and apply their tech skills to do so. Their only operating expense is $8/month in electricity. Meanwhile the other 40k-something nodes are run by big passive players who don’t even control their own POKT but hand it over to big conglomerate custodial service providers charging them $200/month. I would think that the first group is the group the network wants to cultivate more of, not less of! In this hypothetical example they make up 2.5% of the network. In real life the number may be even smaller than this. Now compare results: Let’s say that PUP-19, PIP-22 and/or PIP-23 is turned on and leads to an average of 2x consolidation. That consolidation will take place precisely where the network is operating least efficiently. The 40k count of inefficient, expensive custodial nodes consolidate down to 20k while the count of efficient nodes stay the same at 1000. So the market share of efficient vs inefficient nodes doubles. On the other hand, if consolidation is forced, then the 40k count of inefficient custodial nodes gets cut in half, but so does the efficient group. Worse yet, many in this group will not be able to consolidate and will be forced out from node running. So this group might shrink from 1000 to around 200 to 300. Now the ratio of efficient to inefficient nodes has shrunk to 1 to 1.5%. This is a move in the WRONG direction. It is absolutely naïve and irrational to think that this group will simply go out and buy more POKT to “stake up” because it is so “cheap” to do so. The whole point of being in a macro bear market is that everyone has already spent the liquid money they have and the liquidity simply is not there right now for this “staking up” to materialize. Much more likely that they will quit the network and figure out where they can put their existing equipment to use to mine etc other alt-coins - especially if they feel slighted by the DAO for raising the Stake minimum

Objection 8: raising StakeMinimum can create a lot of ill-will and (in niche circles) bad PR for pocket especially among this tech savvy portion of the community - who just so happen to be the ones most likely to know app developers who might one day be potential clients of pocket. People are vastly underestimating how important goodwill and good PR is for a project still in its infancy (or toddler) stage

Objection 9: Doing NOTHING is superior to raising StakeMinimum. Unlike so much rhetoric floating in the different social media forums, pocket is not broken, It has healthy relay growth, robust network, no outages to speak of, etc, etc,. That the world economy is in a recession and pretty much every market sector is in a bear market is not an indication of a problem. That node runners are operating in the red is not a problem. It is an indication that the node runners spun up nodes extremely inefficiently (eg with expensive custodial service providers). In bull markets such inefficiencies are allowed to fester. Bear markets punish relentlessly such inefficiencies and force innovation to bring greater efficiency to the system. If we do nothing, those who continue to operate in the red will eventually sell off and efficient players who can operate in the black even during a bear market will take over.

Bottom line: A heavy-handed governance that wields its power to protect a special interest group and keep an inefficiency going will lead inevitably in this very competitive space to a more efficient POKT-competitor blockchain arising and taking over market share until all of our investments become equal exactly and precisely to zero.


I largely agree with @msa6867 objections with this proposal. I think this creates alot of disruption to the network and may not have the desired outcome. I see the reasoning, but the risk/reward is too lopsided for me to feel comfortable with this being implemented.
The other proposals have a more balanced approach on the impact to the ecosystem.

Thank you everyone for your feedback. We will take this under advisement and reply with amendments to our current proposal.

1 Like