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



We are working to come up with an upgrade to this proposal that would simplify the mechanisms used in this proposal. If we were to upgrade, the nature of the proposal would remain the same and we want to optimize for simplicity, predictability, and stability. I wanted to release this proposal to begin the discussion around the mechanisms proposed.


The ideas in this proposal are my own and don’t necessarily reflect the views of others on the core team or Pocket Network, Inc. Nothing in this proposal should be relied upon for decision making. The examples and spreadsheets are for informational purposes only.

Update Log for V1.1

  • Updated spreadsheet
  • Changed Input: GOOD VIBES Factor (GV): 0.450
  • Changed Input: Inflation Decelerator: -0.65%
  • Changed Input: Max Validator Allocation: 40.50%
  • Added Minimum WAGMI Target Inflation Value. Set value to 250,000,000 POKT
  • Added support in the spreadsheet for USD returns to better encapsulate the true cost of running nodes
  • Added a more in depth calculator page


Pocket Network has several sources and sinks, which have been discussed at length on these forums. WAGMI is designed to curb the main source, but doesn’t go far enough. It was never designed to be the end all be all. It was the kickoff to a long and recurring conversation about how to make the economics work for all parties involved and to make Pocket Network sustainable through good and bad times.

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 very roughly estimating the minimum viable node count considering even distribution and capacity to be about 10,000 - 15,000 nodes distributed across the globe near traffic sources (this is a rough estimate of minimum viable node count and is directionally correct, but not a precise figure to be relied upon. We will monitor and adjust accordingly). This means we can cut network costs without damaging quality of service. Further, using 15,000 nodes as a baseline provides an opportunity to view the real performance of the network for users and have the ability to adjust accordingly.

This proposal attempts to combine several ideas into one while piggybacking on, but not entirely replacing, WAGMI. The idea is that by simply incentivizing validators, we can encourage people to accumulate on a single node rather than continuing to spread POKT over new nodes. In doing so, we can proportionately decrease the mint rate and overall inflation while maintaining work-based rewards at reasonable values.


There have been many discussions that effectively end with the conclusion that the cost of the network is too high, which puts pressure on the token in the open market (I won’t bother to list all the arguments here). We can address all of these through one proposal that aims to curb sources and sinks.


The Growth Oriented and Optimal Distribution of Validator Incentives Based Economic System (GOOD VIBES) proposal attempts to create a predictable mechanism that incentivizes validators by assigning a rewards premium over and above servicing rewards. GOOD VIBES adjusts ProposerAllocation and ServicerAllocation according to a given level of nodes, annual minted tokens, and average validator stake. It creates a curve based on these inputs that can be relied upon as we transition from overprovisioned to a more sustainable node count.

GOOD VIBES attempts to make it much more economically viable to make the switch to validating and to have confidence in that decision. Those who make the switch from servicing to validation will make a small premium over servicers. If the node count reduces below the Minimum Viable Node Count threshold, the economics reverse, making service nodes more attractive than validators. The Minimum Viable Node Count acts as a way to govern when the economics change to favor servicers so that node count doesn’t fall below an optimal number.


ValidadtorAllocation =


(Total Unjailed Validator Stake / Total Unjailed Stake) * GOOD VIBES Factor) < Max Validator Allocation


Total Unjailed Validator Stake / Total Unjailed Stake) * GOOD VIBES Factor


Max Validator Allocation

Important Inputs & Other Information

Servicer_Allocation = 1 - ValidatorAllocation - DAO Allocation
Max_Validator_Allocation_Percentage = 40.50%
DAOAllocation = 10%
Minimum_WAGMI_Target_Inflation	250,000,000
MaxValWeight	40.50%
Inflation_Decelerator	-0.65%
GV_Factor	0.300
WAGMI_Target_Inflation @ 15,000 Nodes:	320,954,252
Assumed_Node_Cost: $120 (all in)

If you graph this out, you’ll see that it only takes a small amount of validator incentives at first, but that amount increases significantly as validation becomes more popular, but as node count shrinks, validator weight is increased significantly. Due to the incentives, node count would never go far below the Minimum Viable Node Count (proposed to be 15,000 nodes).


See full table here: Experimental: PUP:15 - GOOD VIBES - Google Sheets

The chart below shows daily expected average rewards by node count if they were to do all servicing or all validating (validators also earn servicing rewards).


The average assumes that you’re able maintain an average validator stake throughout the decrease in node count. Individual results will vary, but the intention is that it’ll always be better to validate - if you can stay in the pool of validators, considering the cost of servicing.

Example: 50,000 POKT

From a practical perspective, let’s take a closer look at what this means for a node runner. As an arbitrary number, I chose 50K POKT as an example of a node runner who needs to make a decision about how to run their nodes.


With a constant average Validator Power, it is obvious that validating is (almost) always better than servicing even without introducing the costs of servicing. The node runner would always choose validating as long as they could keep up with the minimum Validator Power required to be a validator. The expected rewards for work on the network get squeezed as the amount of staked POKT increases.


People with smaller amounts of POKT will risk getting pushed out of the validator list and then being relegated to only servicing. This could make the list of servicers overrepresented by the long-tail of node runners.

Example: 2,000,000 POKT

As we can see below, in the 2M POKT example, the more stake you have, the tighter the difference between validating and servicing becomes.



Even though their expected APR is higher for servicing, the additional cost for running servicers should cause whales to flock to validating. It’s worth noting that APRs will vary per user depending how many nodes it’s possible to run with a given stake.

How it works

A curve is created by the previously entered inputs and the GOOD VIBES factor. The GOOD VIBES factor increases validator incentives and acts as a lever to encourage servicer to validator migration. The initial input for this proposal would be 1.15. This proposal aims to start with a modestly low GOOD VIBES factor and increase it over time if necessitated by the market. This scenario may come about if whales are cautious about the change and don’t think there is enough incentive to make the leap. While I don’t see a need for an adjustment for this in the near term, the adjustment of this should come by DAO vote in future proposals.

To give the reader a sense for the curve created by an decrease in GOOD VIBES factor, this is the curve at .3 GOOD VIBES.


As you can tell, you can manipulate the validator premium up and down with this input.


A nice side effect of GOOD VIBES is that we can bring down the inflation rate in proportion to the number of nodes on the network to a sustainable level.

Extrapolating out the current numbers, our WAGMI-based economic system is on track for the following:


Effectively, GOOD VIBES would replace the WAGMI Parameter proposal when implemented where the number of nodes on the network determines the Target Inflation Value in WAGMI. To be clear, WAGMI is still used to govern the mint rate according to the number of relays, but the inflation target is determined by GOOD VIBES.

For example, if there were 31,500 nodes in total, the WAGMI Target Inflation Value would be 544,261,626 POKT. At 19,000 total nodes, the WAGMI Target Inflation Value would be 386,007,055 POKT. The mint rate would still be adjusted according to the number of relays over the past 30-days. The full schedule can be found here:


At an Minimum Viable Node Count of 15,000, the annual WAGMI target would be 398,655,195 POKT, a 56.25% reduction in inflation beyond the 50% annual inflation target of 472,507,494 set out in the original WAGMI parameter proposal. Effectively, this brings annual inflation to roughly 21.8%.

Grace Period

As part of this proposal, I’m suggesting that we provide an unstaking time grace period to allow for the easy transition between servicing and validating. The passing of this proposal would delegate the specifics of this to the Foundation to announce and provide a period of time to make the transition. To aid in this process, the control of the unstaking time parameter would be delegated to the Foundation until this proposal has later been revoked.


I view GOOD VIBES as a stop-gap measure until stake weighted servicer selection (as proposed in V1) can become a reality or other advances can make it irrelevant. That said, GOOD VIBES addresses several problems at once:

  1. Network-wide overprovisioning
  2. Network-wide inflation (source)
  3. Increases the effectiveness of the sinks through validator power competition (sink)
  4. Economic network security

People have discussed overprovisioning at length, and this proposal effectively addresses that problem head on by encouraging validation.

Further, it consistently incentivizes validators to compete for additional Validator Power, which causes an effective sink to be created as there is a competition to capture more rewards.

Future proposals like Jinx’s Stake Weighted Adjustment of Probability for Session Selection could be a drop in replacement for these mechanisms in a more elegant, code-driven solution. If/when a code-based solution is implemented, we can remove GOOD VIBES. For avoidance of doubt, the repeal of this proposal happens only if that language is included in a new proposal.


GOOD VIBES is fairly set and forget, from a framework perspective. If/when node count decreases, the power to change the RelaysToTokensMultiplier, ProposerAllocation, and ServicerAllocation would be delegated to the Foundation to adjust at its discretion according to changes in the node count.

This proposal includes the ability for the Foundation to edit the GOOD VIBES factor (increase/decrease validator incentives), the Max Validator Allocation Percentage (to change the incentives to servicers) and the Max Validator Weight (according to the Minimum Viable Node Count) to increase or decrease validator incentives at its discretion to balance the demand of service nodes. From time to time it may be necessary to adjust the curve to align incentives. An example of this may be when the MaxValidators parameter changes.

Dissenting Opinions

Stake Weighting: Stake weighting is being considered by the engineering team but is not a light lift from a code perspective and will take months to properly code, test, and release. This proposal is not a replacement for stake weighting, but it’s a stop gap until stake weighting is released. Jinx is planning a proposal that would address this topic.

Node count inflation attack: Colluders who don’t care about profits could stake many nodes to drive up the inflation while earning rewards. While not a very threatening attack, it probably is worth noting that this could be an attack angle.

DAO Allocation: This adversely affects the DAO’s income in POKT terms. The DAO will be hamstrung by any proposal that aims to reduce inflation.

Costs aren’t considered as part of the premium: As long as rewards per POKT staked is equal, and validators are cheaper to operate than an equivalent amount of servicers, validating is more attractive and therefore a premium is not required. This is a valid argument and should be considered as part of the overall parameter proposal.

The validator competitor pool naturally gets smaller over time as the validator bid gets higher. This is a very fair critique of this proposal. Validation could end up extremely top heavy and centralized.

Expensive transition: As people unstake from the network, they might use it as an opportunity to exit the network completely and sell their tokens. This may lead to additional sell pressure while unstaked in a short time period. To counter this, I recommend a pre-defined grace period of reduced unstaking time which would allow for people to make the switch without the massive opportunity cost associated with the switch.


@adam - Wizard of WAGMI, Least Popular Proposer, Guy who VIBES

Thank you for the numerous contributors to this proposal. Your guidance was invaluable.


Copyright and related rights waived via CC0.


Beyond the project fundamentals and utility, it’s the amazingly smart people involved with the project that make me optimistic about its future.


Thanks @iaa12, this was a team effort from community members and core team members. I can’t take all the credit.


Well thought through and articulated proposal - I support this proposal fully

Thanks for this. Directionally an improvement for sure. A couple questions if you don’t mind.

-At the baseline node count (~15000) are monthly costs expected to be around $3 million to support the network (ie validator node costs will be the same as the current servicer costs)? Are there any next steps to lowering this operating costs for the network? As mentioned in TG, it’s still very very high relative to the crypto industry, also to POKT liquidity, and uses for POKT, etc. And before you say it’s not apples to apples with any other project all I’m trying to do is simplify the supply/demand dynamics so everyone clearly sees. In general, the space needs to use simpler frameworks so individuals can make clear decisions.

-I don’t see anything regarding the minimums to become a validator. Or rather the amount of block producing validators. Is that spelled out somewhere that I missed?

  • Overall, the proposal seems to use economic incentives to drive large servicers to switch to validators (eg lowering costs). I imagine this will occur over months, not days. Right? Maybe due to some unknowns from the question above & education? Are we still considering the stake amount adjustments as a shorter term & likely faster solution?

  • Lastly on unstaking grace period. Would this be extended to servicers currently unstaking or those who may unstake prior to the potential approval of this or only those who unstake after?

Thanks for your time.

This is great, thank you for the hard work on this proposal. Do you have an estimate for how long the grace period will last?

I would like to challenge Adam’s status as Least Popular Proposer and suggest that we can drive the latter number down to as low as 100M POKT.

The community needs to start getting used to the idea that POKT isn’t a $1 token - and I don’t care what puddle-deep liquidity on CEX is pricing now – but its real place is within the $3-5 range when the dust is settled.

Other than that, I wholeheartedly agree with this proposal.


I spent some time with the spreadsheet to understand what’s going on. I agree with this proposal, I think we should get it approved and implemented. I have 2 pieces of feedback :

  • Looking at the spreadsheet, it seems 10% (DAO fee?) was subtracted from Servicer Allocation Percent, but not Total Servicer Rewards and Per Servicer. Thus Max Validator Weight could be tweaked to 70% rather than 72% if we want the lines to cross at 15k nodes. Pretty close even if it’s left as is.

  • I would submit a tweak to the proposal for consideration, which addresses two of the criticisms in the proposal. I do not believe a premium is warranted over servicing, since the infrastructure savings are going to be huge anyway. As such, I would propose a DOGE Factor of 1 , a Max Validator Weight of 68%, and an increase in DAO allocation from 10% to 20%. Which would look like this:

I support this proposal.

A cooldown grace period has been mentioned in multiple strategy approaches. This would also be critical for the SWAPSS proposal, and is likely too much of a burden to repeat. I would request that if this proposal passes and is implemented, the grace period be shared with complimentary proposals.

1 Like

I think this is an interesting idea.

I have a few thoughts.

Also, some of the inputs are slightly off

The current stake of all unjailed, not unstaking nodes is 694,032,657.88. The average validator stake is 17,256.17, and the average servicer stake is 15218, not 17499.

It is possible to do load testing to determine the exact capacity of the pocket client. We are doing this now and should definitely be done during the discussion of this proposal.

This proposal creates an additional economic incentive to take control of all the validator slots, which is not safe for the network. This is especially apparent at our current node count and the proposed model. The following chart adds an additional line for the APR of validating and servicing (one can do both simultaneously).

Someone with alot of unlocked tokens would be able to take advantage of this immediately after the proposal passes and quickly take control of the validator set. There is an incentive here to act quickly, and take control of as many validators as possible in order to earn these maximal rewards.

It is also unfair to only reward the top 1k nodes. This alienates all small node runners as the average validator stake quickly increases. It would be ~100k pokt at 40k servicers and ~250k pokt at 30k servicers. This is a major centralization vector as large providers and pools will have the most access to liquid tokens.

This incentive is big enough for someone to stake additional liquid pokt that they have into validators, but it is not big enough to incentivize people to unstake and consolidate into validators.

There is also an outcome where this whole thing doesn’t make sense since it is -ev to enter a validator bidding war. If a bidding war were to start, the average validator stake would continually decrease until the validator APR converged to the servicing APR. Someone would then have very large node stakes that are alienated as servicers and earning very low APR. This introduces complicated collusive strategies where providers aim to keep the average validator stake as low as possible. The rewards are good until this convergence happens, but once it does someone would have to unstake and wait 21 days before they can distribute horizontally across servicers.

After the light client is released, there will be no functional difference in resource use between validating and servicing (outside of chain nodes which are inexpensive at scale).

I’m still thinking of the implications of this proposal and these are just some thoughts that come to mind. I think this solution might work if the factor is decreased dramatically and the maxvalidators is increased, but it is worth noting these other externalities and threat vectors.


If their objective is a governance attack, they can do this already. But once the validator auction plays out, doing so would be more expensive.

If their objective is to monopolize validator rewards, this is impossible since the validator set is a permissionless auction - whichever MaxValidator nodes stake the most are the validators.

There are elements of this I agree with and value. Thank-you @adam for designing this new possible mechanism for addressing over provisioning and network security.

I’m hesitant to support as I think we need feedback from core-devs the pros and cons of each of the solutions that are being proposed.

What I like about your solution is that it encourage token lockup and increases network protection. For any solution we decide on those are needed elements.

What I’m not comfortable with:

  1. Validators become far more powerful than what is necessary to secure the network. We highly inflate block production rewards instead of fixing servicers. The lean client or weighted stake actually fix the servicer issue vs creating a new class of nodes competing nodes.

Upping the block reward for validators, or expanding the number of validaors is more than enough of a solution without having validation compete with the servicers, adding complexity to the ecosystem.

  1. There would be a mechanism where validators and servicers compete for rewards instead just being focused on doing a quality job in their areas. Upping the block reward for validators is more than enough of a solution without having validation compete with the servicers, adding complexity to the ecosystem.

The lean client or weighted stake solutions actually fix the servicer issue vs creating a new class of competing rewards.

  1. This open the door for all the standard validator running companies to run validator pooling. I am not a fan of that being part of our ecosystem on the level that this proposal would enable. Currently the technical nature of running servicers keep out all the rent seeking services that will never want to see their rewards minimized.

Say with v1 the reward for validators is greatly reduced and the focus goes back to the servicers, that will create many issues if a large, ever growing portion of the ecosystem is focused around block production instead of servicing relays. Right now node runners all have the same goals, and opening up block-production on this level opens the door to competing economic parties for rewards. This fragmenting is dangerous IMO when POKT currently has one of the most unified node communities where nodes don’t compete with each other in a direct manner.

  1. If this block producing rewards need to change in the future to account for another network issue, then validators with be the ones that are over provisioned with amount of POKT staked. This means that block producing rewards will likely get favorable treatment in network decisions because validators have a huge amount of POKT staked per node. I think this will take a while to become a factor, but

  2. The grace period required to transition is a huge technical undertaking and I only think that level of ecosystem coordination should happen if we are introducing a servicer improvement like weighted stake.

  3. This proposal is mostly irrelevant if the lean client or weighted stake is released. If one of those solutions come forward then having a large market built around validation is unnecessary and a burden on the network. Just upping the block rewards to a reasonable limit, or increasing the number of validators can account for security without become irrelevent with a solution to servicers.

Those are my thoughts. Thanks again Adam for taking lead on this intriguing solution.


Would it not be the opposite way around? Avg validator stake would increase.

Since the validator set is permissionless, I’m skeptical that it will be possible for colluders to keep the validator stake low. Rewards in the validator set are proportional to stake weight, so everyone is selfishly motivated to stake as much as they can, and anyone can enter the validator set by staking more than the last validator.

Here are some assumptions that needs to be thought of and clarified (assumption → response)

  1. Node count increasing results in high infrastructure cost → Not necessarily true, this is solvable by the light client with the fraction of the cost.

  2. The validator set will all have the same validating power average. → As we’ve already seen with the current validator set, even with barely any incentives, the validator set is sparsely distributed. Whenever you incentivize the network by increasing block proposer rewards, this opens the door for whales node runners to “grind” their way to receiving that block rewards. Node running is a competitive space and whales are looking at any given opportunity to increase their POKT/day. Without simulations, models, and surveys from whales, large node runners, and pooling platforms, it would be absolutely disaster to put this to vote as it can lead to poorer economics and centralization. There needs to be an incentive, but the incentive should not only largely benefit whales. We need a clearer picture of how this will unfold before throwing it back into the ecosystem and having us "figure it out and adjust"

  3. Validators deserve to earn about the same or more than servicers → One of the bigger reasons why servicers and validators are even separated in the first place is due to network consensus limitations THATS the only reason why. We are fundamentally changing how the security model was designed which may have unintended implications. As POKT begins to onboard more and more chains, it does not economically make sense for a validator to earn remotely as close to a servicer. As the validator set becomes larger and larger, this blocks out entry for the small guys. This could cause a flywheel that will cause further economic changes and division (SERVICERS vs VALIDATORS, how much a validator should earn, how much servicers cost with chains, etc).

Also just food for thought: How does these changes affect V1.0? We are changing how nodes will stack their stakes, so whenever V1.0 comes, it would be a lot more complex to take the current state of the chain and modify it to fit V1.0. Is the network security even an issue whenever V1.0 hits and we have an improved consensus layer?


Not a governance attack. I am saying that you are incentivizing someone to take control of as many validators as possible. Even if there is a bidding war, there would still be single entities with large portions of the validator set.

I agree.

This is a good point. We would be giving a majority of the rewards to validators rather than incentivizing the optimization of our core product, providing fast, redundant RPC.


There are a handful of providers now. It would not be hard for them to collude and keep the average validator stake low to maximize APR. Of course others can jump in and stake higher, but 71% of the stake is with 7 providers.

Yes, incentivizing validators would make these kinds of grinding attacks +ev.

To add to my past comment, it looks as if the core-devs are taking things forward with a feather client feature in pocket-core: GitHub - pokt-network/pocket-core at feather

I feel that solutions is better for the network as it addresses the network resources in a manner that does not require a complex transition period that is likely to have a lot of technical challenges.

Now that this info regarding the feather client feature has been released, I feel the best option to secure the network is to up the number of validators as @addison suggested or up the block producer reward just enough to secure the network. Hopefully the core-devs will recommend a direction for securing the network.


I question whether a grace/transition period is needed to implement this, because:

  • We’re at a point where node-running profits are very low, so 21 day unstaking period may not hurt as much as it otherwise would. In addition, if there’s infrastructure commitments in place, a node runner would be incentivized by the unstaking period to keep the revenue stream going by unstaking in portions over a period of time as opposed to all at once.

  • There was some information in another thread indicating close to 40% of node runners are small, and they would have no reason to unstake. They would see increased earnings during the unstaking period, and would be incentivized to stick around and do servicing work, even if whales suddenly decide to mass unstake.

  • The network is over-provisioned, so it should be able to handle 1 billion relay traffic with a fraction of the 47,000 nodes it currently has.

  • The good citizens of the community would no doubt be ok with keeping a portion of servicing nodes active in order to ensure network stability - without which they would tank their own investment.

1 Like

When Adam shared this draft with me I tabled my proposal to increase the minimum validator stake in favor of GOOD VIBES. This uses native market incentives to decrease the minimum validator count with minimum friction to the network.

This proposal included with the light client will solve most of the issues we have today. It will allow us to step down rewards as we become more efficient, allowing POKT purchases from applications to have more impact.

In a GOOD VIBES world I would also opt to increase the DAO allocation in a separate proposal as well.

I would love to see this proposal voted on ASAP.

There may not be a need for a grace period given where we are at with the cost model today. It is better for me to unstake and eat the 21 days than pay the monthly fee.

Agree, as we get more efficient, we can continue to lower this number.

This is standard for any proof of stake network. From the start, pocket has had an extremely favorable distribution across every token holder and is not at risk with 1k validator slots, given the distribution of POKT across all major holders.

If i’m running 2 servicers and I don’t receive validator rewards, I naturally earn more rewards for my 2 servicers as validators consolidate and earning on proposing blocks. The purpose of this proposal is that it balances out.

The important part of this proposal outside of the consolidation is that it provides a WAGMI-like step down in rewards as the network begins to consolidate. We should be aiming to have the network be as efficient as possible regardless.

We should be working towards upping the incentives to stake more POKT on validators. The network is extremely vulnerable otherwise. This is what provides the economic security for everyone.

We have already changed the security model once. The intention was that all nodes staked would be participating in block production. Due to the limitations of the protocol we had to limit this to 1k. This is increasing the security of the network while allowing for servicers to earn roughly the same amount as validators.


It would be designed to provide an even playing field for liquid or currently staked POKT.

At the moment, there are 1000 validators. That could change via a proposal.

I’m open to further deceases, but every time I’ve proposed something to this extent, it’s been HIGHLY unpopular. I’ll point to: PUP-12: Inflation Stop-Gap Proposal: Double Trouble as an example. I built in a mechanism for accelerating decreases to the mint rate above and beyond a proportionate decrease. That would look something like this @lex :

Inflation would be about 105M at the MVNC. If I hear others call for this, I’ll edit the proposal.

Looks like an oversight. I’ll get in there and correct things. Thanks @addison.

While I’m heavily in favor of the idea of the light client, I am thinking that there is a non-zero cost to the light client, as light as it may be. Meaning at the end of the day, more clients = more costs. According to Addison, these costs are very much non-zero At 50% of the cost, low long until we’re at 80K or even 160K nodes? What does that mean for network cost? It’s a little too early, in my opinion, to consider that the silver bullet until it plays out in reality. Further, why not do both? Operate at a more ideal node count, with very low costs? Seems like a win-win to me.

In an ideal scenario, this would be well coordinated and node runners would have a chance to get ahead of the changes meaning that changes wouldn’t take effect until everyone has had a chance to make their moves. It should be an even playing field. If someone does want to front-run, they’d be securing the network.

We’ve seen this continually with launching new service nodes; therefore, I’m not sure I follow the logic. Further, unstaking penalties make it costly to marginally decrease your stake.

At current costs, it definitely is. Post-light client, we will see. To your point, I think you can have the best of both. Liquid POKT is staked on validators (great) and we have low cost servicers with the light client (also great). I think where the rubber meets the road is with node running services which will offer validation services that put little strain on the market.

Let’s do both?

I’m convinced that incentives overcome the complexity that this introduces.

Given PUP-14: Increase MaxValidators to improve economic security - #29 by addison, it feels like we need this. The simple solution would be to just up the validator incentive arbitrarily, but I think you run the risk of migration back to servicing if not dynamically adjusted, jeopardizing network security.

Keep in mind that there is a 15 chain limit per servicer. It’s not like costs per servicer vary based on how many chains Pocket Network Supports.

I think this is a separate issue that GOOD VIBES does not intend to address. See below:

1 Like

I also proposed stake weighting probably before Jinx too here :Some Suggestions for Tokenomics

And while PUP-15 seems nicely thought out, It won’t help the price. The only solution is stake weighting. And it’s such an important solution that devs should not lose time with coding GOODVIBES and instead completely focus on stake weighting. And yes they should release staking preferably on a testnet in the next week at latest if they want this project to survive.

If price goes down a bit more, mass unstakings will happen.

1 Like