Pre-proposal: 🧙 GANDALF (Decrease MaximumChains)

[shane]

UPDATE: For quick reading SPARK NOTES (TLDR) SUMMARY

Attributes

• **Author(s): @shane
• **Parameter: MaximumChains (the maximum amount of chains a servicers can serve)
• **Current Value: 15
• **New Value: TBD (considering between 1-3)

Summary

Since POKT’s birth, MaximumChains has been set to 15. This number was arbitrarily picked at the start for the network. 15 chains per servicer was beneficial early on since POKT wanted to be able to add new chains rapidly with a small node community, and allowing a server to serve many chains was a great way to enable that.

However, after having talked to many in the POKT ecosystem, no one actually knows the measurable effects MaximumChains has on POKT today, so I’ve done independent research into accurately modeling out real world effects of the MaximumChains parameter. This research can now be used for data driven decision making for MaximumChains in both v0 and v1.

The conclusion I have drawn from this research, is that with POKT’s very mature node ecosystem, having MaximumChains at 15 is negatively effecting POKT’s economics, QoS, and decentralization. I am proposing we change this parameter to 1, 2, or 3, and am first submitting this as a pre-proposal to start a community discussion on what the proper number should be.

In the past year, POKT’s node ecosystem has been progressively becoming less open (through increased complexity), centralized, and imbalanced, and MaximumChains only acts as an accelerant when set at 15. By addressing MaximumChains we could remove a lot of friction and imbalance within the POKT ecosystem, while potentially encouraging node growth.

I am calling this proposal GANDALF, which stands for “Growth Acceleration, Node Decentralization, And Load Fairness”. GANDALF is here to protect all, including the little guys.

Abstract

The GANDALF Model spreadsheet is a complete look at how the POKT chain ecosystem balances and the effects of MaximumChains. Here is an outline of the different pages:

• Settings - Where you can update the chain information from POKTScan and set other variables.
• Today - Shows how POKT looks like today with MaximumChains set to 15.
• Gandalf - Same layout as Today page, but allows you to change the MaximumChains, see the suggested balanced outcome, and introduce imbalance through Column H.
• Gandalf w/ Today's Imbalance - Similar to the Gandalf page, but shows the effects of the MaximumChains on the Gandalf page, but with today’s imbalance. This shows what the effect of today’s imbalance would have of different MaximumChains settings.

A BALANCED POKT WORLD

POKT TODAY

Before we can determine what the MaximumChains should be, we need to understand what a perfect world looks like for each MaximumChains variable. We can introduce imbalance later, but for now, we need to see how the system is suppose to work.

To understand POKT, let’s first look at the Today page which has it’s MaximumChains set to 15. We can see how many nodes should be staked on each chain and how many relays each node would expect in a balanced world.

Already we can some interesting features of MaximumChains set to 15, where Ethereum through Optimism are best balanced with every node on the networked staked on them. These 8 chains are “Money Chains”, and even with all nodes staked on them, they would still generate more rewards than all other chains because they have a lot of relays.

Starting with Klaytn however, the amount of relays on the chain require less nodes to serve it. In a perfect world, with node balanced across each chain, all chains (besides the Money Chains) would serve 1,419 relays a day and generate .31 POKT.

CHANGING MaximumChains

Now lets see what happens when we change the MaximumChains to something like 1. This means that each servicer on the network can only serve 1 chain. To do this, move over to the Gandalf page and set A2 to 1.

Now we see something interesting:

There are no longer Money Chains, and each chain would serve 65k relays a day, and 14 POKT a day. This means each node does not need to serve the 8 money chains to get close to network average… they instead need to simply serve a single chain.

All chains now have the ability to generate the same amount of rewards per node in a balanced network. Instead of a node runner needing to run 15 chains to make network average, a node runner could just run a single chain node.

Main Takeaways

When looking at what a balanced network would look like we can already draw several conclusions from MaximumChains being set to 15:

1. A single node requires 15x the amount of infrastructure compared to MaximumChains being set to 1
2. The 8 Money Chains generate the vast majority of rewards for POKT nodes, whereas if MaximumChains was set to 1 then all chains could generate the same amount of rewards per POKT node.

AN IMBALANCE POKT WORLD

While looking at things from a balanced place shows us how the system is technically designed to reward each chain, the real world isn’t perfectly balanced. GANDALF allows imbalance to be introduced to see what the effects of imbalance would be on different MaximumChains settings.

POKT TODAY

When looking at the Today page (which has imbalances pulled from POKTScan data), lets look at a chain like Moonbeam to understand the effects of imbalance with MaximumChains set to 15. You can see that Moonbean should have 3,229 nodes to be balanced, however it currently has 8,543 nodes. This means that for Moonbeam to be balanced, 5,314 nodes should be subtracted and staked on other chains.

Moonbeam has a provisioning of 265%, which is 165% over the 100% it is supposed to be for balance.

What effect does this imbalance have on the network?

This imbalance means that each serviceer staked on Moonbeam is only generated .12 POKT per day, instead of the balanced amount of .31. So the effect of this imbalance is those nodes are losing essentially -.19 POKT per day.

As you can see, this imbalance has very little effect. -.19 POKT is very little to worry about. On most chains, extreme imbalance has very little effect since Money Chains are where the bulk of a nodes rewards come from.

Main Takeaway

When looking at what an imbalanced network we can already draw several conclusions from MaximumChains being set to 15:

1. Imbalance is barely penalized.
2. A few Money Chains will always generate most of a node’s rewards.

CHANGING MaximumChains

Now let’s see how that imbalance with Moonbeam was applied to when MaximumChains was set to 1. To do this set A2 on the Gandalf page to 1 then go to the Gandalf w/ Today’s Imbalance. This page applies the same Provisioning imbalance (Column K) from the Today page to the MaximumChains set in Gandalf.

If Moonbean was provisioned at 265% (which is 165% over what it should be), then the effect would be as follows:

Nodes overstaked on Moonbeam would now be receiving a reward hit of -8.74 POKT per day. So instead of just losing -.19 (like it is today) nodes would be losing -8.74 POKT per day. This substantial reward drop for overstaked chains would mean the network would be naturally incentivize to have balance across all chains.

A node runner may be willing to remain on overstaked chains if the penalty is only -.19 POKT… but if the penalty is -8.74 POKT, that would require moving nodes to an undeserved chain.

Main Takeaway

When looking at what an imbalanced network we can already draw several conclusions from MaximumChains being set to 1:

1. Imbalance is harshly penalized.
2. Balance across all chains are naturally incentivized.

Motivation/Rationale

Fix Rare Chains

Currently some chains on the POKT network generate such little rewards that few bother to support them. This is why a Rare Chain Supplement was introduced in DAN. However, this was only meant to be a temporary measure, and a long term measure is needed.

GANDALF is a long term solution. By incentivizing balance across the network, node runners have to split up from primarily serving Money Chains, and focus a balance spread across all chains.

Enable Reasonable Independent Node Running

Currently, a node runner has to run at least the 8 Money Chains to be close to network average rewards. By reducing the MaximumChains to something like 1, then any independent node runner can start generating rewards by just serving a single chain.

Independent node running has always been a key part of POKT’s mission, but it has all but been extinguished through:

1. High infra costs
2. GeoMeshing
3. Increased complexity

By reducing MaximumChains, it can be economical for folks to run POKT nodes from home computers.

Encourage Node Growth

POKT was originally purposed to be a network where if someone was already running a chain node, they could stake POKT nodes on top to generate extra revenue for their nodes. I was the first node salesman for PNI, and that was the standard pitch to folks already running nodes from other chains.

When we first wanted to launch Avalanche as a new chain in August of 2021, they hosted a Twitter space for Michael and myself where Michael pitched how this is a way for their community to serve AVAX applications and generate reward from it. Today however, that pitch is all but dead because there is no reason to node run unless you can support many other expensive chains you know nothing about. That marketing has been dead for POKT, but we could set the network on a path to regain those kind of partnerships and marketing strategies with GANDALF.

POKT would benefit from the buy pressure if the node ecosystem was open to everyone, and not exclusive to large operations who can support a dozen chains, like it is now.

Prepare for v1

@RawthiL in V1 – How to Enforce Fairness and Decentralization: A first approach, has already started the argument that 1 chain per servicer would potentially allow there to be more distribution and fairness in v1.

POKT has already experimented with having many chains per servicer, and it seems to only have had a negative effect since the POKT node ecosystem matured. GANDALF shows objectively how imbalanced and impractical node running currently is, and how only few chains get most the reward. V1 needs to introduce balance, and GANDALF should be the starting point.

BONUS: Data Driven Decision Making on Delisting Chains

There is a good argument that POKT has too many chains that are underutilized and should be delisted. GANDALF provides a data driven approach to actually evaluation chains, their profitability in different environment, and if they are net loss for the network.

Column R shows if the net reward for a given chain is more than cost to run a single node in each primary POKT region. As you can see, 61% have “NO” which means they do not generate enough reward to even run a single small server in each region.

Ultimately the POKT DAO and community will need to decide what our approach to delisting chains should be, but GANDALF allows us to actually make informed decisions, especially when taking factors like MaximumChains into account.

Dissenting Opinions

This will hurt large node runners.

It likely won’t “hurt” anyone. Instead of any node runner relying on the 8 Money Chains for the bulk of their rewards, each provider will likely spread out to support other chains. Many larger providers will still likely serve the same amount of chains, but each provider will focus on different chains.

Right now, the two top node providers both serve 15 chains each, but 11 of those chains are the same between them. This means that 74% of their infrastructure is serving the same chains, while other chains have little to no support. With GANDALF, and MaximumChains set to something like 1, they would likely only share 2 to 4 of the same chains (instead of 11), meaning POKT would have much more diversity of support between hosting providers.

Smaller providers on the other hand would benefit from this because they could generate more rewards with less chains. If someone has a few hundred chains, they could likely only spin up 5 or so chains, giving good spread to their rewards, while saving substantially from needing to serve 15.

TLDR: Large node runners would likely serve the same number of chains, but it would be a greater diversity of chains, while small node runners could actually serve fewer chains to generate the same reward.

1 is too low.

We can’t know for sure what number will be best for POKT, but 1 should be what we want to heads towards (for all the reasons mentioned above). GANDALF does provide insight to how other numbers will work, so the community can help decide on the ultimate number. 15 however objectively is hurting the ecosystem, so something needs to be changed. To eliminate Money Chains, entirely, then 3 is the largest number to consider (hence why I’m suggest between 1 and 3).

Pros and Cons:

Set to 1

Pros

• Anyone can join POKT ecosystem by serving a single chain
• Less provider overlap, so more chains can be covered at a single time
• Most incentive for providers to maintain node balance across all chains
• Requires the least amount of infrastructure
• Eliminates Money Chains
• Best prepares for v1

Cons

• Rewards may be less consistent per servicer, since it’s connected to a single chain (though providers are heavily incentivized to balance quickly, so this would likely just be a short term issue).
• QoS for small chains may suffer if they are dominated by a single provider (that is the issue with having an ecosystem reliant on large providers though).

Set to 3

Pros

• Rewards come from 3 chains, so they may be more constant on the daily
• Eliminate Money Chains
• Possibly better QoS on some chains (since there could be more overlaps with which chains that providers support)

Cons

• Requires 3x the infrastructure per servicer vs the 1 option
• Requiring more chains per servicer could limit who can/wants to join the node ecosystem

TLDR: We can decide as a community what we want to set it at, but 15 is not helping anyone and it needs to be changed. Feel free to use GANDALF to determine what number you feel is best and share below.

Node runners with more resources will be able to jump to more profitable chains, giving them an edge over others.

The beauty of setting MaximumChains to something like 1, is that node runners are incentivized to go to chains that are most profitable. If there are node runners that are able to quickly jump between chains to get the most profit, it benefits everyone since they are actively creating balance.

Example:

Say large node runner sees that Kava Archival (a chain they support) is overstaked by 20 nodes, and Celo, is currently under staked by 10 nodes. This results:

• Kava Archival making 10.61 POKT
• Celo is making 16.71 POKT

The large node runner decides to move 10 of their nodes to Celo, to maximize rewards. This results in Kava Archival reducing nodes, and bringing it closer to balance, helping every other Kava Archival node. The result is Kava rewards go up and Celo rewards go down:

• Kava Archival now makes 12.09 POKT
• Celo now makes 14.06 POKT

Having well equipped large node runners that are able to jump around to different chains, brings balance to the ecosystem as a whole and helps everyone. Any chains where nodes are taken away immediately see meaningful jump in rewards when the MaximumChains is low.

We want nodes to generate more rewards, so we should allow them to serve as many chains as they want.

I’m placing this here because this has been a common misconception. More chains does not equal more rewards, it just means those with more infrastructure (larger node runners) have the ability to get more rewards at the expense of smaller node runners who can’t support expensive infrastructure. MaximumChains has always been a mystery to the network, but GANDALF can now clearly see that MaximumChains set to 15 doesn’t promote decentralization.

I believe there is a reason that no other RPC protocol being developed has a MaximumChains parameter as POKT (that I’m aware of). I’m only aware of node runners staking X amount per chain they want to serve on other protocols. GANDALF shows that higher MaximumChains ends up centralizing at the expense of decentralization.

Analyst(s)

• The GANDALF Model spreadsheet

Copyright

Copyright and related rights waived via CC0.

[Cryptocorn]

I’m behind this just for the memes .

Will be interesting to hear Ramiro and others’ thoughts.

[shane]

Sparks Note Version, courtesy of Claude

---

Here is a condensed 1 page summary of the key points from the proposal:

GANDALF - Growth Acceleration, Node Decentralization, And Load Fairness

Abstract

The current MaximumChains parameter of 15 negatively impacts POKT’s economics, quality of service, and decentralization. This proposal argues for lowering it to a number between 1-3 based on data modeling and analysis.

Current Issues

• Only 8 chains (AKA “Money Chains”) generate most of the rewards, centralizing infrastructure around those specific chains.

• Imbalance barely penalized. Overprovisioning a given chain reduces rewards just slightly.

• 15 chains requires substantial infrastructure, favoring large node runners and locking out smaller node runners.

• Many chains don’t generate enough rewards to justify running a node.

Proposed Changes

• Reduce MaximumChains to 1-3.

• At 1, 2, or 3 chain per node, all chains could generate similar rewards per node.

• Imbalance would be harshly penalized, incentivizing balance, addressing the Rare Chains issue.

• 1 MaximumChains allows anyone to participate with minimal infrastructure.

• Growth could be spurred by lowering barrier to entry.

• Data can inform chain delisting decisions.

• Aligns with v1 goals of fairness and decentralization.

Benefits

• Fix imbalance, encourage growth

• Allow data-driven chain analysis

• Open ecosystem to more participants

• Distribute rewards more evenly

• Prepare for v1 goals

The GANDALF model allows data-driven analysis of options. Community discussion needed to determine right number between 1-3.

[RawthiL (Ramiro | POKTscan)]

Why… now…

Before we start

To you and everyone else. Please define your methodology. Posting spreadsheets is easy but the description on how they work (mathematically) is required to understand (and audit) them.
Spreadsheets (or any other obfuscated and comment-less code format) can have two types of errors: conceptual errors and implementation errors. The first ones can be easily spotted with a methodology section (definitions), the latter ones by inspecting the code. However if the methodology is not given we can cannot distinguish implementation errors from features…

Some might think that math modeling is pseudoscience, but you will find it is not (you can consult your astrologist in case of doubt).

---

The “imbalance”

Not sure how nodes to balance is derived or its meaning. Please define how you calculate the “imbalance”, going through spreadsheets calculations is tiresome and error prone. I cannot understand how some chains can be “balanced” with all the nodes on them. Please define what you understand as “balance”.

It seems that your “balance” is more like a “saturation”, i.e. given the current number of nodes, how many can you assign to each chain until you normalize the incomes of nodes in all chains? then the “money chains” are never “saturated” because their number of relays is too high. If this is the case, the definition of “balance” is a function of the total number of Pocket nodes, which is not related to the number of blockchain nodes. This will impact the real capacity of the Pocket Network to re-assign their nodes to some low-traffic chains.

The “perfect world” is not possible

While what you say is true and the behavior of node runners should lean to that, it ignores the fact that it’s much easier for large node runners to simply deploy a lot of nodes on a single chain, reducing their rewards by node but at zero cost. Once you have a node in a blockchain you can spam nodes on it. It makes economical sense to do so, as the hardware cost of adding a Pocket node to an existing blockchain is zero but the cost of spinning a new blockchain node to get more rewards most of the time exceeds the return. This problem is one of the reasons that we argue for the inclusion of a “normalization” parameter (the entropy) in our research thread.

Why is the current pocket ecosystem not like the page “Today” of the provided spreadsheet? because it makes no economical sense. The living proof of this imbalance is the average reward of some medium providers (< 300 nodes) that can make averages that are much higher than bigger ones (> 1000 nodes).

I doubt that only setting the maximum allowed chains to 1 (or any other number) will result in a “perfect world”.
In other words, we don’t have 18696 “wildcard nodes”, we have a given set of nodes that are run by a given set of operators that have a given set of blockchains. Assuming that all these nodes can be set to any chain in any location is not accurate. Optimality of stake alone is not enough to drive the “perfect world” formation.

Rare Chains

Setting MaximumChains to 1 is a step in this direction but is not enough. Rare chains have other problems, like low traffic or high costs. Calling this proposal a “solution” is too strong IMO…

Independent node running

Yes, this is the strong point of reducing the maximum number of allowed chains; the same conclusions can be derived from our research thread.

In this point you also mix GeoMeshing, which has nothing to do with this proposal, and GeoMeshing effects will remain. Reducing the maximum number of chains won’t affect this at all for small node runners.

Chain Delisting

With or without this proposal we can do the same analysis; I don’t know why you include as part of the proposal.

---

@shane

This will hurt large node runners.

Oh yes it will, and I don’t care. However the response that you give to this argument is full of strong assumptions (and strong assumptions are bad).
Don’t try to soften the blow, they (we) had it coming, as Pocket Network philosophy is to be decentralized.

@shane

1 is too low.

One chain to stake them all and One geozone to bind them

or

Multiple chains and Multiple regions (sorry no pic here).

We make an extensive point on this in our research thread. Other options are non logical, using 3 is just another arbitrary number that emerges as limit in GANDALF just as a consequence of the total number of current nodes and the assumption of free movement of nodes, neither of those are valid reasons to think that 3 is a logical choice.

@shane

• Eliminates Money Chains

This claim is too strong (and unreal IMO), this will only happen under your assumptions. I think that without a mechanism that punishes over-staking of nodes, the imbalance will remain. It will be reduced, but it will not be anywhere near the “perfect world” and hence the “money chains” will still be a thing.

@shane

QoS for small chains may suffer if they are dominated by a single provider (that is the issue with having an ecosystem reliant on large providers though).

An issue that’s easily solved in V1, with the watcher modulating the rewards to these low QoS nodes and implementing a mechanism that encourages nodes to stake in this chain/region (as we argue in our research thread).

---

Why now? Why separated from the research thread?

Many of the conclusions that you reach here are the same as we saw in our thread. It is great to see someone reaching the same conclusions from a different angle. We agree with them, but why are we discussing this in separated topics?
This last question is probably related to: why now? why not discuss this in a V1 scenario as we proposed?

The change is violent from a POKT return per POKT invested (economic incentives). A LOT of friction will be created as the staking paradigm changes a lot for stakers. Stake holders who are used to just stake and forget will have to choose chains? or they will defer to the staking service for their staking? Who’s going to decide which client nodes will be sent to die in low-relay chains (sparse rewards, seeing your node do nothing for days maybe) for the sake of achieving balance?
This friction will create confusion that will be come atop the ongoing pain that ARR has caused node runners. As the optimal staking strategy is achieved among node runners and a new status quo arises the chaos will reign. Dagor Bragollach will look like a camping trip compared to this. I might be a little bit of an alarmist, but the time is not the right for this move. Node runners are already in pain and confused, we should spare them of this until V1…

Also, our choice of putting up this discussion in the context of V1 had other reasons besides making a clean cut from V0 to V1 staking strategies. Defining nodes with a single chain and single region is one and the same (as we argue in the research thread). Setting only maximum chains to 1 is not logical if we keep GeoZones unrestricted (that cannot be changed in V0). There is a larger concept behind trying to achieve 1 Pocket Node == 1 UNIQUE Blockchain Node; we cannot do that in V0, probably also not in V1, but we are always looking at how to do that. In V1 trying to achieve this parity is more important, as the watcher will modulate the node rewards based on their performance and having a single set of metrics per node address is the best way to do it (and code) IMO. I don’t want to keep on talking about V1 here, but it cannot be avoided as this proposal ties in so closely to what the future protocol will look like.

[shane]

@RawthiL

Please define your methodology. Posting spreadsheets is easy but the description on how they work (mathematically) is required to understand (and audit) them.

I was more focused on explaining the spreadsheet itself, vs explaining how it works. Good feedback and happy to provide more details (though I won’t be able to bust out the Greek like yourself )

@RawthiL

Not sure how nodes to balance is derived or its meaning. Please define how you calculate the “imbalance”, going through spreadsheets calculations is tiresome and error prone. I cannot understand how some chains can be “balanced” with all the nodes on them. Please define what you understand as “balance”.

Happy to provide more insight.

Balanced is when nodes are perfectly distributed across all chains, so all nodes are serving the same amount of relays. Chains that have more relays, have more nodes staked to them, and vise versa.

How Balance Is Calculated

With MaximumChains set at 15 and 18,783 nodes on the network, there are a total of 281,745 possible sessions (15*18,783=281,745). These possible sessions, I’m calling Session Slots are in C1. To find balance, these 281,745 Session Slots need to be staked across all chains on the POKT network in a distributed “balanced” fashion. This is done by distributing the Session Slots to chains in accordance to the amount relays it produces.

Example: Klaytn Mainnet has 25M relays, so it has 18,291 nodes, while Fuse has less relays (21M), giving it less nodes (15,291). Balance is nodes on both Klaytn and Fuse serve the same 1,419 relays a day.

However, when distributing Session Slots to chains, in accordance to their relays, each chain has a natural limit since a node can only stake on a chain once. This means that the max number of Session Slots a chain can have is 18,783, since that is the number of nodes on the network. Therefore even though a chain like ETH has 1/3 of the network relays, it can’t have 1/4 of the Session Slots… it can only have 18,783 since that is the number of nodes on the network.

This is how Money Chains are created. Technically a chain like ETH should have around 70k sessions slots (since it has so many relays), but it caps out at 18,783, making those session slots serve much more relays (which is why ETH reward is so high). The other 50k session slots, that should be on ETH, then have to be distributed to other chains.

Columns U through Y are an Adjustment table which distributes session slots, across all chains, though it makes sure that no chain exceeds it’s max of the amount of nodes on the network (18,783 in this case). It is this table that is able to distribute session slots perfectly, across all chains, in accordance to the chains relays.

You can verify that all session slots are accounted for if E58 is equal to the number of total session slots, and that no chains have more than the total number of nodes (which is B1 on the Settings page).

@RawthiL

I doubt that only setting the maximum allowed chains to 1 (or any other number) will result in a “perfect word”.

I want to clarify that I’m not saying that setting MaximumChains to 1-3 will create a “perfect” world. I gave an example in one of the Dissenting Opinions of a scenario where a node runners moves around nodes to maximize their rewards, and in return it creates meaningful balance for the other chains staked on the other chain.

GANDALF isn’t claiming to create a “perfect world”, it’s just providing the data to show that adjusting MaximumChains, creates economic incentives to have meaningful balance (which objectively does not exist today).

@RawthiL

Chain Delisting

With or without this proposal we can do the same analysis, I don’t know why you include as part of the proposal.

Sure someone else could have done that analysis at some point, yourself included, but I went ahead and did it since it complimented the data in my model already. “Is a chain even generating enough rewards to justify it’s existence” is a natural question to ask when thinking about node distribution. So I included Columns P through S and stated that it is “BONUS” data in the proposal.

@RawthiL

Rare Chains

Setting MaximumChains to 1 is a step in this direction but is not enough. Rare chains have other problems, like low traffic or high costs. Calling this proposal a “solution” is too strong IMO…

Exactly, it is a step in the right direction, but I do not mean to suggest it is the “complete” solution. To be fair, we don’t know how much impact this step would have… there is a chance that niche node runners form around low relays chains if they don’t have to also serve 8 other chains for meaningful reward, thus addressing some of the rare chains.

If we can propose steps in the right direction, with data driven thoughtfulness, then we should NOT let all the other issues of the network freeze progress. That was PNF argument for ARR, “let’s just take this step and see how things look”… and I’m proposing the same argument.

@RawthiL

In this point you also mix GeoMeshing, which has nothing to do with this proposal, and GeoMeshing effects will remain. Reducing the maximum number of chains wont affect this at all for small node runners.

I would have added geo data to this model, but since the Portal no longer provides that data to the network, we are kinda stuck on that front. We really need geo data back

However, I do not believe that the remaining GeoMeshing effect will be a fully debilitating effect on independent node running as you may be suggesting. Before geo data was discontinued, many chains easily saw 50% to 70% of a chains traffic come from 1 region. It really depends on the chain.

If that is the case, many providers have fees 30% or more, and with ARR in effect, it is likely fees may increase. This means that for some folks, depending on the region they are in, they could easily run a chain, on their own infra, and make the same or more than going with a provider.

Again, even though GeoMeshing could still be a obstacles for some configurations, we should still move forward with steps that move us in the right direction with reducing the infra requirements by upwards of 15x. Start with that IMO, and see where things go.

@RawthiL

Oh yes it will, and I don’t care, however the response that you give to this argument is full of strong assumptions (and strong assumptions are bad).

It will effect each provider differently most likely. Some may adopt well, some may not. I do believe there is a place for the more agile providers to thrive… but I understand that others may not agree with me.

I can’t account for how every provider will respond.

@RawthiL

Many of the conclusions that you reach here are the same as we saw in our thread. It is great to see someone reaching the same conclusions from a different angle, we agree with them, but why are we discussing this in separated topics?
This last question is probably related with: why now? why not discuss this in a V1 scenario as we proposed?

Your thread was about a number of v1 related points, while GANDALF focuses on one parameter for v0 and provides real world data of it’s effect. I’m glad that this research relates to v1, as it provides a data driven model to some of the concepts in your thread, but this is a v0 proposal and the v0 effects of MaximumChains. I can’t submit a PIP under your thread… it needs to be it’s own thread.

@RawthiL

The change is violent from a POKT return per POKT invested (economic incentives), A LOT of friction will be created as the staking paradigm changes a lot for stakers. Stake holders used to just stake and forget will have to choose chains? or they will defer to the staking service for their staking?

Is your assumption that GANDALF makes it harder for independent stakers, which will drive them to staking services? This is fundamentally wrong thinking, and the opposite of what the data shows and what this proposal outlines

If you believe this will hurt independent node runners and drive more business to staking services, I would need to see data and reasoning to back that up. Use the GANDALF spreadsheet to show how the economics would be bad for small node runners. Open to feedback if I’m missing something

@RawthiL

Who’s going to decide which client node’s will be sent to die in low-relays chains (sparse rewards, seeing your node do nothing for days maybe) for the sake of achieving balance?

That may be a UX challenge for some providers. I do not know how different providers will react. Some providers may allow stakers to choose their chains, and other providers may choose for the client. POKTScan would have to decide what options they give their users… just like how POKTScan already decides what options they give their users. That is a discussion to have between members… as I can’t tell any providers how to do their UX

@RawthiL

This friction will create confusion that will be set upon the ongoing pain that ARR has brought upon node runners.

That was also brought up on the community call today, and I think @BenVan’s suggestion is great. He suggested doing a progress reduction vs a sudden one. Start with reducing to 10, then 5, etc. This would allow large providers to transition with less friction and shock.

However, while there will be pain for large providers, reducing MaximumChains only helps the small guys and even opens up the potential for independent growth. For a long time the network has primarily favored large providers, as the GANDALF has shown, and this is starting to take that favor away for the sake of independence and decentralization.

It doesn’t have to be the sock you are suggesting… but we shouldn’t turn a blind eye to the effects MaximumChains is currently having on POKT’s decentralization and node growth IMO.

[shane]

@RawthiL

Who’s going to decide which client node’s will be sent to die in low-relays chains (sparse rewards, seeing your node do nothing for days maybe) for the sake of achieving balance?

On more note on this comment. Your are mistaken in think that moving to a lower relay chain will produce less rewards. GANDALF actually does the opposite. Smaller chains will produce the same amount of rewards because balance is incentivized. GANDALF gets rid of sparse reward chains for the first time.

Perhaps my explanation of GANDALF was confusing, but I’d ask that you show me how any chain with relays would have sparse rewards if MaximumChains was set to 1 to 3. GANDALF shows the opposite.

[RawthiL (Ramiro | POKTscan)]

@shane

Is your assumption that GANDALF makes it harder for independent stakers, which will drive them to staking services? This is fundamentally wrong thinking, and the opposite of what the data shows and what this proposal outlines

Nope, setting max chains to 1 does help smaller node runners to compete, I agree with that.
The point I’m trying to make is around who run the nodes (node runners) and who own them (stake holders). This is a non trivial issue that will introduce noise to the “normalization” of the number of nodes by chain, i.e. POKTscan wont be able to distribute their 3K nodes as it sees fit because those nodes are not theirs to manage. Some clients have hundreds of nodes, some have a handful, staking strategies to normalize their incomes are not going to be the same and are not going to be simple to understand.
Also pages that make ranking of node providers wont provide any meaningful information, as the averages of nodes incomes per domain names are not going to reflect the average of any of their clients (unless they are pools).

@shane

That may be a UX challenge for some providers. I do not know how different providers will react. Some providers may allow stakers to choose their chains, and other providers may choose for the client. POKTScan would have to decide what options they give their users… just like how POKTScan already decides what options they give their users. That is a discussion to have between members… as I can’t tell any providers how to do their UX

I’ll tell you the answer to this, as anyone can guess, pools. Not your nodes anymore, bye-bye non-custodial. Anyone can calculate the optimal staking strategy and stake like that. The largest that owns its hardware will win. Is this bad?, no as you say is just UX. Are node runners prepared and economically incentivized (due to ARR) to do this right now? No.

@shane

That was also brought up on the community call today, and I think @BenVan’s suggestion is great. He suggested doing a progress reduction vs a sudden one. Start with reducing to 10, then 5, etc. This would allow large providers to transition with less friction and shock.

In what time frame? V1 should be here in 6 months…

@shane

On more note on this comment. Your are mistaken in think that moving to a lower relay chain will produce less rewards. GANDALF actually does the opposite. Smaller chains will produce the same amount of rewards because balance is incentivized. GANDALF gets rid of sparse reward chains for the first time.

Nope, I get what you say, the problem is not on the average returns, it is in the time between returns. Thats what I tryed to clarify with:

“sparse rewards, seeing your node do nothing for days maybe”

I agree that averages are going up for most chains, but the time-between-rewards is increased. You do not account for this in your calculations and it is OK, but the last simmilar issue that we had was with PIP-22. The argument then was that some stake weights produced more than others. We end-up running a 3 month trial to clear all the doubts around that, something as simple as an average get confusing when its variance is high…

---

Yes, all this can be solved, node operators can adapt. The question is, are we going to have 2 weeks to prepare or 6 months?
Given the low interest in this subject when it was brought up in a community call by BenVan, also when we published our thread and in private conversations with V1 devs, we were more inclined to think that this was going to be a V1 thing.
We know the work that this will require from a node runners perspective and also from the data/dashboard perspective. V1 is going to break a lot of things, our time would be best used if we directly code for that.

I don’t think that testing this live in v0 is the best option. I get the “go fast, break things” vive, but the truth is that behind all the stuff breaking is people working who would love to have some peace of mind and work towards V1. I hate to bring this cheap argument, but behind every change that is proposed there is a lot of community work.

Moreover, as you say, we completely blind in QoS data, how are we going to asses the effects of this change if we do not even have a baseline anymore? For what is worth an experiment when we cannot measure?
Without QoS metrics the only thing that we will have from this experiment is the answer to economic incentives of node runners (i.e. how the nodes are going to be distributed). If a chain gets undeprovisioned it will default to CC. Great, is it worth? I do not beleive so. Economics incentives will be hit again (and hard) with V1 GeoZones restrictions and Watchers modulating rewards and punishing nodes.

Some advocate for a progressive change, but I think that they fail to asses the magnitude of the impact that V1 will have on node running economy. This feels like paininting the house before building a second floor, the whole thing is going to be wrecked, you are wasting your time.
We should focus all this energy on V1 economics research, that should have already started.

[shane]

@RawthiL

The largest that owns its hardware will win. Is this bad?, no as you say is just UX. Are node runners prepared and economically incentivized (due to ARR) to do this right now? No.

That is a misconception. Those with larger infrastructure, that have the ability to switch chains easily will bring balance to the rest of the network. I already gave an example here of that happening and how that actually helps the network as a whole.

The network as a whole would benefit from providers with resources moving quickly between chains that are imbalanced, because it provides balance. You will have to show me how providers balancing out chains is bad for the network, because that is contrary to what the data shows.

@RawthiL

In what time frame? V1 should be here in 6 months…

Then start the transition now to prepare the ecosystem! Especially since we don’t know when v1 will be coming, as the date does get pushed back often and no hard time frame has been set.

I get where you are coming from but we shouldn’t maintain an obviously wrongly set parameter in v0 for the sake of providers, especially since it needs to happen anyways. Make things as healthy as possible now to improve the network and encourage node running.

@RawthiL

the problem is not on the average returns, it is in the time between returns. Thats what I tryed to clarify with:

“sparse rewards, seeing your node do nothing for days maybe”

I agree that averages are going up for most chains, but the time-between-rewards is increased.

As I mentioned on the call that is a misconception. Here is the proof.

Right now POKTScan shows how many appstakes there are for 5 chains. Using those appstakes (minus Rinkeby which has been discontinued), we can see what the probability is that a node would get in a session with the MaximumChains at 15 and at 1.

As you can see, the probability actually increases for every chain, including Ethereum. GANDALF would actually bring more balance to reward timing than it is currently.

While GANDALF starts bringing balance, ultimately appstakes per chain should be balanced as well. There is no reason I can see why ETH should have 79% of app stakes, while Polygon on has 3% when they drive the same traffic If you want it totally fixed, appstakes should be updated as well, but GANDALF actually brings better reward times on it’s own.

@RawthiL

Given the low interest in this subject when it was brought up in a community call by BenVan, also when we published our thread and in private conversations with V1 devs, we were more inclined to think that this was going to be a V1 thing.

With all due respect, GANDALF provides quantifiable data that hasn’t existed. Suggestions are great, but they rarely have teeth until they have real data. So while others have brought this up before, they did not show exactly the effect it was having.

My assumption was MaximumChains was hurting POKT more than anyone knew, so I set out to see if I was right. Turns out it does have an objectively negative effect on POKT which is why there is now interest. Some providers may not be interested in a change, but I’m at least showing the real world effects.

@RawthiL

If a chain gets undeprovisioned it will default to CC. Great, is it worth? I do not beleive so.

No idea what you mean here. Most of POKT chains are not on CC so not sure CC is related to this. GANDALF is addressing part of the underprovisioned chains issue by balancing their rewards.

@RawthiL

Moreover, as you say, we completely blind in QoS data, how are we going to asses the effects of this change if we do not even have a baseline anymore?

Again, we don’t know exactly how QoS will be effected, so why wait till v1? You seem to believe that v1 should be where all the experiments happen… but v1 should be our grand reveal, not a glorified testnet.

PNF is making plans to make sure v1 is properly marketed… so let’s start transitions we can control now on areas we know are hurting POKT, so we HAVE data for v1. That is something that has to happen at some point, and experimenting with the launch of v1 is a very bad plan IMO, when the issue is this deep.

@RawthiL

This feels like paininting the house before building a second floor, the whole thing is going to be wrecked, you are wasting your time.

Using the house analogy, then this is foundation repair before building a new house (v1). We know that the node ecosystem’s entire foundation is built on an imbalance that is creating undeserved chains, limiting POKT’s node ecosystem growth, and centralizing it’s node into fewer and fewer hands. How many node runners should exit the ecosystem before we fix a foundational issue like MaximumChains?

For the longevity of the network, it would be prudent to do what can to prepare for v1, including fixing the foundation now, instead of treating v1 as a testnet for everything all at once IMO

[RawthiL (Ramiro | POKTscan)]

quick answer (believe me I tried), just for clarifications.

First. I agree and share the conclusions that you make, they are the same that we had, we might only differ on how strong their effects are going to be (with GANDALF, we need the rest of the Istar). So, no need to convince me of the benefits of a single chain. Please do not interpret my answers as if I do not share your conclusions.

---

@shane

As I mentioned on the call that is a misconception. Here is the proof.

You are showing only chains that are currently over staked, wich indeed will have increased selection chance when nodes go away from them. The other chains, those under staked right now, is what I’m talking about, those that will gain nodes. Btw, I cannot see that calculation in the provided spreadsheet.
However, lets use that screenshot, if you are a simple staker, would you like to have earning coming at a rate of 34.77% selection prob or a rate of 1.45% selection probability (forgive me gods of math for putting it this way).
For me it is clear that the higher selection rate will result in faster rewards. I have more chance of being selected every hour (session), actually my expectancy is approx 1 every 3. Even when I earn 34 times less in eth than in polygon, I will see rewards every day tricking in. In polygon I will see rewards only approx 1 every 100 sessions, that’s days.
AGAIN, it is not an issue of AVERAGE rewards is an issue of VARIANCE, a variance in time between rewards. Same issue as PIP-22. No, you cannot change this, no it is not unfair, yes it is difficult to explain.

@shane

No idea what you mean here. Most of POKT chains are not on CC so not sure CC is related to this. GANDALF is addressing part of the underprovisioned chains issue by balancing their rewards

If a chain is left with no nodes (or too little to form a session), PNI will at least spin-up a node ans stake it (probably also hook it up to CC) because it is very likely that they are bound by a contract to do so. So, the issue of starvation has no teeth IMO.

@shane

Again, we don’t know exactly how QoS will be effected, so why wait till v1?

So we are changing this now not to get data but for the thrill of doing it? I don’t see the benefits if we are not going to learn anything from this. If we are not learning anything then it does not matter if we do it before or at V1.

---

A general note on modeling

Lets try to avoid putting in a higher value to models constructed out of data vs models that are mathematical descriptions. There seems to be an obscurantist trend in the community that calls models “theoretical exercises”, even when they check out with reality. Knowledge building works the other way around, it tries to model things out of simple concepts, compound its effect and test against reality. It is very different from creating model to a fit given observation.

Your model is not “data-driven”, as it relies in a single observation. This is actually a weakness. A data-driven model would be one that explains many observations of an unknown process. You don’t learn nothing from fitting a single observation (or a bunch of them).

As a community we should try to avoid empowering misconceptions like “if it fits the current observation then it is better”. It is much better to have model that we know how and why it works but does not 100% explains everything, than one based “on real dataz” that is only a particular case of completely wrong model.

Don’t get me wrong, I love your threads, they are in fact the highest level of experimentation and research that I see in the forum, thanks for that. Also, this is not a critique to this model in particular, nor a way of saying it is wrong (it is not).
What I need to express is my concern around the way we are constructing knowledge here, because I felt that some of your comments reinforced this misconception.

[shane]

@RawthiL

AGAIN, it is not an issue of AVERAGE rewards is an issue of VARIANCE, a variance in time between rewards.

Yeah, chains like ETH will always produce faster rewards because it has 79% of the appstakes. Perhaps we should do a proposal where PNF (who is getting ownership of the appstakes) balances them out. I believe doing an update stake is all that is required, and would the address variance issue you have been describing.

I don’t think this issue should be a blocker for GANDALF though, as those who are willing to wait for a higher impact session will get more if too many folks are aping into chains just for more frequent rewards.

@RawthiL

Lets try to avoid putting in a higher value to models constructed out of data vs models that are mathematical descriptions.

Unfortunately, I do not speak in mathematical descriptions, as you do , but I do speak in data analysis (aka spreadsheets) For you, having “the Greek” helps you understand something, for me, having a dynamic spreadsheet model helps. While you are multi-lingual, as in you can produce work in mathematical descriptions, python, spreadsheet, etc… I may be more of a simpleton and really only speak spreadsheet. So that is the why I communicate with the models as I do

I’ve been very grateful for the discussion when I present a model, and many people end up providing feedback to make them better. I feel that is in part because I speak in spreadsheet models which is more approachable to most folks. I don’t believe one method should be held in higher regard than another, though I do think that spreadsheets open the door for more participation.

@RawthiL

There seems to be an obscurantist trend in the community that calls models “theoretical exercises”, even when they check out with reality. Knowledge building works the other way around, it tries to model things out of simple concepts, compound its effect and test against reality. It is very different from creating model to a fit given observation.

Not sure how this relates to GANDALF specifically, but I think when data is laid out in an approachable way (like with a logical spreadsheet) then people tend to verify the assumptions on their own, vs blindly trusting mathematics descriptions that most don’t have the ability to understand. That is at least my two cents.

When you created the spreadsheet for MINT, it helped me understand your proposal since I don’t speak in mathematical descriptions, like you do. Once you made the spreadsheet, I was able started providing feedback because it was approachable to me. I’ve always appreciated how you do make spreadsheets with a lot of your research, as it allows me to get my hands dirty

@RawthiL

Also, this is not a critique to this model in particular, nor a way of saying it is wrong (it is not).
What I need to express is my concern around the way we are constructing knowledge here, because I felt that some of your comments reinforced this misconception.

I apologize for reinforcing that misconception. Not my intent at all GANDALF is my best attempt to take POKTScan data, find out what MaximumChains looks like in a balanced world, imbalanced world, and make it dynamic so we can draw rational inferences on what MaximumChains should be for the betterment of the network

Much thanks in helping flush all this out

[msa6867]

@shane

I believe there is a reason that no other RPC protocol being developed has a MaximumChains parameter as POKT (that I’m aware of). I’m only aware of node runners staking X amount per chain they want to serve on other protocols.

Staking X amount per chain is a rationale approach, and as far as I can tell consensus seems to be forming around this point in @RawthiL’s “Fairness” research thread for v1.

But wanting to make the change now? Just when we’re trying to absorb ARR and settle into a new post-ARR “steady state”? I have to echo @RawthiLs “Why… now.” I get your counter-argument about doing experimentation now rather at v1 introduction. But my counter-counter argument is that 1 chain max per stake is not really an experiment… the experiment if done now is more in what kind of havoc doing a switch from 15 to 1 midstream will cause during the transition period. By bundling the change from 15 to 1 with the introduction of v1 - where there is a wholesale change going on anyway from an old state to a new state, that “midstream transition” experiment happily never needs to take place.

As a side note - and this applies to whether making the change now or with v1 - if we do want to limit number of chains, its hard to come up with a theoretical justification for a limit value greater than 1.

Last point for now - and this also applies whether making the change now or with v1 - I think the discussion of maxchain oughtt to be conducted in tandem with discussion of minStake. Right now the min staking requirement is 15k POKT to run up to 15 chains. Does it make sense when transitioning to maxchain=1 to still require a stake of 15k POKT to run a single chain or should MinStake simultaneously be slashed… say to 1k POKT or something in between 1k and 15k?

[shane]

@msa6867

But wanting to make the change now? Just when we’re trying to absorb ARR and settle into a new post-ARR “steady state”?

I think everyone may have different opinions on what is considered a “steady state”. From my perspecitve, I see us bleeding staked POKT, folks are exiting the ecosystem, and even though ARR is hard on every node runners, it dramatically burdens those with fewer and fewer nodes. At this pace, everything may become “steady” when most nodes are controlled by a few hands

GANDALF would start reducing the amount of chains required, thus reducing the infra cost for most, while progressively balancing out the rewards for smaller chains, and opening the door for more folks to join POKT. I don’t see this as something that needs to wait, if done in a smart way. So far the feedback from this proposal has been great, and I plan to make changes.

@msa6867

the experiment if done now is more in what kind of havoc doing a switch from 15 to 1 midstream will cause during the transition period.

I agree that it would be a dramatic experiment to suddenly reduce the MaximumChains from 15 to 1. This is the beauty of a pre-proposal where changes can be made. It was suggested by another node runner in the community call that it could be a progressive reduction, similar to how SER reduced inflation over time.

Each month MaximumChains could be reduced. Most node runners could start reducing the amount of chains they need to support to make network average, thus progressively reducing their costs. It would also start creating better chain coverage as each adjustment would create less and less “Money Chains” and start balancing rewards.

I’ve taken this progressive concept to heart and will be adding a progresses reduction strategy to the final proposal. I believe that doing this progressively in v0 would be better for POKT than doing it suddenly in v1.

@msa6867

I think the discussion of maxchain oughtt to be conducted in tandem with discussion of minStake

I agree that for v1, Minstake should to be revisited, but changing Minstake in v0 is outside the scope of GANDALF and is not required to accomplish this proposal’s goals.

[iannn (Ian)]

I believe folks are not unstaking and leaving this ecosystem because of the maxchains, and reducing that isn’t going to help them. I believe this campaign is about capturing more stake per chain/per entity and not about helping indie node runners, at least that is my perspective as an indie node runner competing in this ecosystem. Folks are unstaking because they have lost faith in those behind the wheel and no longer wish to act as pawns in someone’s experiment.

I think we’re the only ones with a larger # of chains per stake, the new upstarts are stake per chain. That one can stake once and earn from multiple chains is something some of us like about pokt. I also think that the conditions you describe as optimal around 5 or 3 or whatever is something we could grow into by next year at 15 if we don’t stop making arbitrary changes that will achieve outcomes other than what’s stated, and stop jumping the gun before other things mature. I also think that we should see an expansion of chainIDs to represent different indexes and other value add components with different to represent different qos checks or whatever, and allow the traffic per chain to distribute into those as DEMAND requires… Also, we already have conditions now where there are already multiple “sets of 15” if you will that could be staked as a large provider to maximize rewards, and those larger providers that will outperform will be staking fleets into multiple sets of 15 nodes. If the maxchains were reduced, these same savvy providers, some of whom built machine learning tools to do this very thing last year, will grossly outperform anyone else in the aftermath of a chain reduction.

[msa6867]

@shane

changing Minstake in v0 is outside the scope of GANDALF and is not required to accomplish this proposal’s goals

@iannn

I believe this campaign is about capturing more stake per chain/per entity

Putting the two quotes next to each other, I would have to concur with @iannn’s take. Not saying that’s necessarily a bad thing ; but this aspect should be discussed/debated explicitly, not swept under the rug.

@iannn

I also think that we should see an expansion of chainIDs to represent different indexes and other value add components with different to represent different qos checks or whatever, and allow the traffic per chain to distribute into those as DEMAND requires

I really like this train of thought…

[Qspider]

In the past I wanted to increase chains to some unlimited number like 100 for those that could handle it because to my knowledge max is just max you don’t need to add 15 chains. I would be open to decreasing max chains though if it would generate more relays and be good for the network but I think decreasing to 3 or even 1 is far too much. I don’t think this has a chance of passing in it’s current form. The more max chains the more community involvement working together.

It is my belief that the more chains Pocket can handle the more attractive it is as a light weight RPC which helps the entire web3 space, hence why it’s a utility token.

[Qspider]

[Qspider]

I think the main reason people have left the space (aside from the market itself a couple years ago) is due to the tokenomics with the relay to tokens multiplier lowering APR and daily yields making this a poor investment. Max chains has always been around and have nothing to do with earnings aside from running more chains adds to your earnings (makes sesnse and its incentivized) it is the relay to tokens multiplier that is hurting earnings. People complain and complain about it and unstake right before a new change is implemented. You’ll notice the large majority of unstakes happen right before a change to the relay tokens multiplier takes effect. Earnings decreased 80-90% last month after this happened. Not very exciting. I don’t think decreasing max chance would have any effect on this decrease in earnings aside from allowing 1 POKT account to make 2-5 POKT or max 12 POKT per day at 15k stake and 10-20 pokt for a validator max 15 POKT avg currently. 15 chains or 1 chain just no excitement here because of the relays to tokens multiplier at 15 POKT max average. To me it’s pretty obvious. There is literally no difference at this price you’re making 6 cents a day or 20 cents on a $2000 investment.

We should add a new element to the relays to tokens multiplier to account for single node runners and start unwinding the tokenomics that have been precedent the last 2 years. It’s just not working. If it takes a hard fork then it takes a hard fork. Whatever is necessary to revive POKT excitement should be priority.

The tokenomics have made inflation far worse and earnings far worse causing more supply due to no excitement and mass unstaking.

[whyclosedsource]

is it possible to have ‘node pools’ similar to mining pools in the backend. Multiple smaller people come together and each runs a type of chain, then they split earnings by criteria y decided by the ppl participating.
This would be a good collaboration effort and relief weight on individuals on such low revenue, since it is more hobby and programmers have spare server resources, where they reliably could sqeeze in a rpc node backend.
the node pool could then optimize itself what node to run etc via internal voting.

[Qspider]

Yes when I mention community this is what I’m talking about. A pooling of sorts. There’s a whole lot of stuff going on out in the web3 space creating different ecosystems. The ability to handle multiple chains is/has a bonus in regards to infra service providers and independent node runners alike as well as app developers and node operators of other chains or multichain operators. Will follow up with more soon. Just going over the data again and trying to put it all together.

[Qspider]

Looking at what I could find when trying to see how this limiting chains started it seems like they are using old data from some source that compared RPC providers a few months ago on QoS before any of the upgrades and updates with new features has been implemented. I am betting QoS is better now after all of this new stuff has been implemented.

Limiting chains would make it more difficult for an independant node runner should they want it to be the same it’s been since we started. The author and those in favor of this proposal are concerned about full node costs and these days you don’t even need to run a full node depending on what chain you’re doing as there are others out there running that chain or service providers where you can even get access on a free tier leaving your existing infra up for something else perhaps a newly added chain to the network. Or maybe you want to participate in it’s whitelisting. That is a whole seperate topic that limiting chains applies to. The impact of whitelisting chains which may have been discussed but I didn’t see it. Who would want to sit and earn nothing if chains was limited to 1 while staking to a newly listed node or participating in it’s whietlisting. I know some would do it but it would basically be a donation for a node runner. It can be a week or longer before it starts so much less participation considering your options have been limited more.

With all this to consider it’s easier now than it ever has been and with the new features in place and new gateways that have popped up in the last few months this isn’t really an issue for QoS. The issue is with the inflation tokenomics and there is plenty we can do there before something like this max chains limit should be considered. I think changing the tokenomics would be good for everyone including PNI since the token price would most likely go up as there is excitment of earning value passively or participating as a hobbyist and learning all about it. Pocket is great for this as it can be like a starting point to the whole web3 verse for a novice or stay up to date being an expert in the technology working on multi chains. There is a place for everybody here whether it’s a node runner, already existing business in the space or an investor.

The imbalance in Pocket world started a long while back when the inflationary tokenomics policies started. This caused more people to leave after taking a huge hit already and it just keeps happening. Some of the policies are necessary but some have had very poor timing and could have been put off a couple months if needed at all because new investors coming in with all the other work everyone is doing. I think there would have been more people joining had some of the most recent stuff not passed a majority vote. Should have just kept it the same or even scaled back some of the previous measures we voted on.

We haven’t even seen completely the effects of what we as a network were doing in June and July so justification for something important like this doesn’t seem to be there.