Potentially capping indexer stake

There seem to be a fair amount of concern around the centralization of the network/stake in the network. I’m curious if there are any thoughts about a cap on the indexer stake to try and mitigate this. Perhaps as a portion of the total staked or total indexer staked amount?

4 Likes

This is what it currently looks like.

1 Like

Interesting idea, problematic in practice.

Aside from the political questions (eg: What should the maximum be? Who are the winners and losers?) the biggest impact of the change is likely that it would incentivize a sybil attack where Indexers simply run multiple nodes under different assumed identities. That would leave us in the same place we already are, except with a more complex protocol and confusion around identity.

3 Likes

It’s worth noting that in terms of selecting an Indexer to serve a query, centralization is not nearly as problematic as you might think. It’s hard for a single Indexer to dominate across every selection criteria (economic security, price efficiency, performance, data freshness, reliability, reputation, etc…). Since different consumers will have different preferences in regards to these criteria and the Gateway also values network health - there will be a distribution of queries which is where the real incentives lie.

2 Likes

Last point… since new token issuance (staking rewards) is inflation, it makes sense that it should affect each stake proportionally.

2 Likes

Thanks for your input on this. I was kinda wondering if this was mostly a symptom of the phase we’re in where all the rewards are coming from indexing a single subgraph and queries aren’t playing a roll yet. Sounds like it may be at least partially that.

I agree that the politics of something like this would be a nightmare.

That would depend on what changes could be implemented and how.

  1. If the delegation cap was a hard limit, rather than a ratio, then large stakes would need to spin up additional Indexers. But this would become cost prohibitive due to not only the extra Infra opex, but also the ETH/gas costs involved. The problem is, how do you pick a suitable hard cap?

  2. If the delegation ratio were to be lowered, it may cause some Indexers to pool their funds with other ‘trusted’ parties, if they wish to continue running the single biggest Indexer they can muster. Presuming this continues to be a metric that attracts Delegator’s attention.

However, the way i imagine #1 would actually play out is that delegation capacities on larger indexers would be filled much sooner, overfilled already in many cases. Much of this delegation would then trickle down to other Indexers, as being overdelegated only retains a reasonable APY to a certain degree, even if the cuts are ‘low’ in relation to others. To maintain similar profit margins, Indexers could raise their fee, but even if they did, due to a higher distribution of delegated funds (and thus lower ratio of ‘others’ to share rewards with in their pool) there would still be attractive levels of APY on offer for both parties, just spread across more Indexers.

To be honest, after running some numbers, i’m quite surprised any ratio of higher than 1:10 was chosen. But i’m also using the power of current knowledge and hindsight, of course.

In addition to the above, another issue is the lack of an overdelegation limit. The current delegation ratio allows ‘profitable overdelegation’ to remain a thing for much longer, since this effect grows exponentially with the delegation ratio.

Note: These are just observations about how things seem to be playing out in the here and now. It’s possible you’re right in thinking that this could all change when query volume ramps up, but from what i have seen, it would take an very large amount of traffic to make a noticeable impact on the current state of things. I expect the centralization to continue on the current course, and i hope that this doesn’t dissuade too many smaller operations in the meantime, because that will only execerbate the issue further.

4 Likes

Might I suggest an adaptive cap increase based on the amount of delegation that was retained over a period of time. Delegators could also see the frequency of when the caps were increased based on good indexer cap limit standing.

For example, a new indexer is registered and is capped at a limited allowed of GRT delegation. Perhaps a cap of 500k or so. After several months, their cap would increase to 1 million and so on if they retained a cap limit for a certain period of time. (Numbers are just examples) This will drive indexers to market their platform in order to increase their delegation cap while also instilling trust with in the entire ecosystem and delegation practices.