Proposal: Calculate Indexer Delegation Capacity as a Curve

[EthWiz]

Abstract:

There have been lots of discussions lately regarding indexer centralization, primarily in regards to a collection of stake that seems to have congregated into the hands of a small number of indexers within the protocol. Many of us agree that a huge addition of value to The Graph is its decentralization, and many attempts to remediate this issue have been presented. Taking into consideration many of them, I am proposing a rather simple solution to the issue that penalizes success nor gives an unfair advantage to any single party within the ecosystem. With this proposal, I suggest that delegation capacity multipliers (currently set at a static 16x for all indexers) be calculated as a factor of indexer self-stake in the protocol, as a strictly decreasing exponential decay function representing the multiplier at which an indexer can be considered overdelegated.

A few starting points that underpin this proposal:

1. Decentralization is a massive part of The Graph’s value, and its expansion benefits all parties and network roles in the long-term.
2. Indexer stake, and the distribution thereof, is a somewhat touchy subject. Attempts to remediate this issue should not give special economic privileges to one party over another, or attempt to “steal” market share from any single party. Parties should be open to competition at a base level of the protocol.
3. The delegation market is based on free-market principles of competition, and this should not be undercut for ease of implementation. Indexers should always have to compete with one another for delegation stake, and any proposal to decentralize future or current stake should not change that.
4. Indexing on the mainnet is currently a capital-intensive operation due to infrastructure costs and variable costs such as gas fees and stake amount, and this makes smaller indexing operations (above the threshold of 100k) harder to operate without large delegations.

With that said, the current system works as follows:

Allowed delegation amounts operate on a multiplier of owned stake => delegated stake at a constant factor, currently set to 16. Thus, if an indexer self-stakes the minimum GRT allowed by the protocol (100k GRT), they will be allowed to accept 16 times that amount as delegations, which is 1.6 million GRT. This is the same for all indexers- as the number of self-stake grows, so does their overall capacity. Thus, as indexers get larger, they are incentivized to add to their self-stake in order to grow larger. As we have seen, however, this makes it much more difficult for smaller indexers to operate, as they require much more delegated GRT to be profitable.

The proposal:

Instead of the constant 16x multiplier, the delegation multiplier should be a strictly decreasing function that models exponential decay of a given factor.
Currently, this function is modeled as y = 16, where
• y represents the multiplier for an indexer, and
• x represents the indexer’s owned stake (a straight line)

The proposed function is as follows:

y = (a - c)b^x + c, where

•	a > 0,
•	0 < b < 1
•	c >= 0

and

•	y represents the multiplier for an indexer,
•	x represents the indexer’s owned stake (either in relation to the largest network stake, or a percentage of the total network self-stake. This measure is open for discussion.)
•	a represents the maximum delegation multiplier possible (for indexers with at least X self-stake)
•	b represents decay rate between 0 and 1 (likely .999999) to determine the rate at which delegated GRT allowed decreases, and
•	c represents the minimum delegation multiplier possible (to receive delegations)

This would make the multiplier curve look like this:

Which may be observed at the following link: Desmos | Graphing Calculator

Pros:

• This solution does not require shifting of stake- instead, it gives smaller indexers greater opportunity to leverage their own stake as they grow, while still being required to compete for delegators in the same capacity as today.
• This solution is a relatively simple implementation- the getIndexerCapacity() function found here Staking | Address 0xc3d14a6e96bcbd7915b940504537ab9a4ca1e55c | Etherscan would simply require another math function (likely in a library) that uses the indexer and network details to calculate the indexer’s multiplier based on their size (either arbitrary or relative to the network). It goes without saying that the getters/setters would also need to be slightly updated as well.
• This solution sets both a maximum and minimum multiplier on delegation stake allowed (determined by variable “c”), so large indexers still have the ability to leverage their self-stake at a factor higher than they were.
• All these variables may be easily tweaked as the network (and testing) progresses. This includes the multipliers themselves, as well as the decay rate (use desmos to adjust “b”).

Cons:

• This solution may not address the direct root of the issue, as current evidence seems to indicate that delegation cap isn’t what prevents smaller indexers from succeeding. This can be seen at Indexers | Graph Explorer , which indicates that very few indexers are overdelegated. Going forward, however, this may not be the case, especially as overall delegated network stake grows in relation to the indexer self-stake.
• There is a risk that this sort of system would simply shift larger indexers to break their operation(s) into smaller indexers to reap greater rewards- this sybil effect is common in a permissionless network such as indexing, and I believe that this is not a very large issue at scale, as the overhead to run (gas fees, variable costs, etc.) multiple indexing nodes on the mainnet is too complicated a task for most operations. Additionally, if this sort of effect occurs, the values of the function can change (less/more steep curve, or a lower maximum multiplier) to accommodate this to still incentivize large indexer self-stake in the protocol.

Open Questions:

• Do you think this improvement would lead to more opportunity for smaller indexers, helping further decentralize the indexer-owned stake in the long term?
• Does this proposal miss anything?
• Are there any potential unintended consequences of this sort of change in the protocol?
• What sort of conjunction might make this proposal more potent in order for smaller indexers to still compete fairly?

Feel free to comment here and/or reach out to ethwiz#2744 on Discord for any questions.

[KonstantinRM]

Strongly support this proposal.
As we discussed at the meeting about Stake Decentralization we obviously need to implement it.
But we need to have a broader discussion about particular numbers.
For now, I tried to adjust them to the current network state. With the goal to limit further growth for already large Indexers and give more space for small Indexers.

In this case, we will limit all current large Indexers near their current state, and it will not be painful for current large Indexers and their delegators (majority of the network, speaking not only about held tokens but also about people amount).
Otherways, current large Indexers will be immediately over delegated, and Delegators start losing rewards without any alternatives. Because if they decide to redelegate to someone else they will lose 28 epochs of rewards and an additional 0.5% delegation fee.
From my perspective, we need to start from this action and the numbers, that I provided above.
Of course, it will be only the first step to make The Graph more decentralized in the future and we need much more, but I believe we can’t postpone this one till the moment we agree with all others.

UPD. For better understanding of this image:

1. X-axis is number in M of GRT of self-stake;
2. Y-axis is number for Multiplication (currently it’s constant=16);
3. Number from X-axis*Y-axis will give us a possible amount of Delegation Pool.
4. It will be better to go Graphing Calculator put these numbers and look at the right side of the graphic that currently outside of the pic

[DataNexus]

I am in support of this.

[cryptovestor]

On IOH we discussed a couple points on this:

1. Delegators need more agility in-protocol before this proposal could be implemented or they suffer 28 day thaw lost yield for no fault of their own
2. We may not agree yet on actual numbers in the curve model, but we can continue to have the conversation in lieu of #1 being achieved.
3. We need to add more statistics to the above model so we can see what Indexer proportion of total in-protocol GRT looks like as you move the sliders.
4. We need to add “current in-protocol stake” as a slider to the model to get #3

@EthWiz can you help with adding these features to the desmos model?

[KonstantinRM]

About #1, I’m ready to vote “Yes” right now, if we use numbers proposed by me Because it will automatically stop further expansion right now by design. But will not force anyone to lose their current rewards.
We can make a Proposal with these numbers, to prevent further growth to large Indexers.
And keep doing everything else after that.
Otherwise, I can’t guarantee anyhow, that P2P, Framework, Figment, and Protofire will stop growth because we just can’t reject new delegations. Speaking about Framework, I haven’t seen anyone from them inside of the community, maybe they are currently speaking with some whales for 500M delegations

[EthWiz]

I can help with this! Let’s talk numbers.

To start, I have open-sourced a python script designed to look at the current network state and calculate the currently active multiplier for each indexer on the mainnet today. It can be found here:

https://github.com/Rburdett4/Indexer-Delegation-Research

As of today (9/14), the network state is currently distributed as follows:

where:

• x-axis is the amount of self-stake an indexer has (in millions of GRT),
• y-axis is the current multiplier for the indexer (delegated GRT / self-staked GRT),
• blue dots are indexers,
• the blue line is the current 16x multiplier,
• and the yellow/green/red lines are potential curves found by modifying the values of A, B, and C.

Using @KonstantinRM 's numbers, we can see the potential curve looks as follows:

which, as he mentioned, would make no immediate changes to the current system, but instead place a cap on the currently-largest indexers roughly where they currently are.

Personally, I am an advocate of using a slightly steeper curve, as well as a slightly lower thresholds for the “minimum” and “maximum” multipliers, likely from 30 → 25 and 3 → 2 respectively.

I personally think that the values that seem the best for long-term growth look as follows:

However, this would currently displace 2 indexers, which may not be ideal. I think compromise is key here, but it’s also important to consider that stake is currently not as decentralized as it needs to be, so some changes to the existing system may need to occur to remediate the issue going forward.

That being said, the key here is compromise. I’d love to hear what the community thinks about specific numbers here- feel free to clone my repository and try some curves for yourself.

[Oliver]

I have taken a look at our current network numbers in more detail to evaluate the impact on both Indexers as well as the aggregate network level. Before going into that, I propose some goals for for guidance in these discussions:

Goal Definition

Total network capacity

One thing to consider is total capacity we have available in the network. Based on the current 16x methodology, that capacity increases the more Indexers increase their self-stake. If it surpasses total GRT supply (i.e. 10.2bn), then we have excess capacity in the network which directionally facilitates stake centralization. The reason is that it leads to an increasingly higher number of Indexers with enough capacity left to delegate to without constraints. Currently we have about 14bn capacity in the network, 2.3bn of which is used up and 11.7bn is still available. In order to achieve meaningful impacts for stake decentralization, I propose to set parameters that reduce the current overall network capacity closer to the total supply level of 10.2bn

Reduced capacity for larger Indexers

I infer from previous support expressed in the community that we are looking to influence future delegations to be made more decentralized. I therefore propose that we set parameters that would make delegating to larger Indexers less attractive where their current remaining capacity is significantly reduced relative to status quo.

Based on the above stated goals, I therefore focus on one key metric in the evaluation of finding appropriate parameter levels: Remaining Delegation Capacity

Self-Stake vs. Network Stake

Another question previously raised was whether the variable x should be in regards to share of self-stake vs. total network stake. Important aspect in this context is that this new algorithm introduces a degree of uncertainty to Delegators. The static 16x cap today provides a stable frame of reference that is easy to understand when the limit is reached. The new algorithm will make the cap dynamic and subject to everyday changes based on continuous network staking changes. Delegators who are staking with an Indexer close to the cap limit might have to monitor more closely and regularly how the cap is changing with this new method. The 16x cap today provides a natural barrier of entry for new Delegators that keep existing Delegators more safe. The new method can move an Indexer into overdelegation territory not only because of changes to that Indexer stake itself, but also due to changes happening in the rest of the network (i.e. large undelegation elsewhere). This in itself might be a point worth discussing further, but for the purposes of this proposal I recommend the variable x being in reference to the total network stake. The reason is that the total network stake is always equal or higher than the total self-stake, meaning that changes occurring to stakes in the network will result in softer daily delta to Indexer cap levels, which in turn lessens the impact on Delegator uncertainty.

Evaluating Proposals

We can look at Konstantin’s numbers and start looking at how this would change the situation for the largest Indexer in our network. Using a=30, b=0.975, c=4 and x=4.62 (share of self-stake in the total network) we get a new y of 27.02. In other words, it has increased that Indexer’s capacity and not decreased it. The reason is that even the largest Indexer’s self-stake is only 4.62% in the network. Using the chart provided by Konstantin helps illustrating that:

I added the green line as reference to our current 16x multiplier. The blue dots represent where each Indexer falls on their new y. Since no Indexer has a self-stake share of more than 5% in the network, every single Indexer ends up well above the current 16x and we end up with a y range of 27-30 across all Indexers. That in turn increases our available network capacity from 14bn to about 24.9bn, ending up with an opposite result to the above stated goals. However, the chart above gives us some good insights and leads us to this conclusion: we need a much more pronounced downward trajectory early on in the curve, which means b needs to be significantly lower in value.

As for Min and Max capacity values, I’m not sure if there is a sophisticated method to define that. We want the Max to be higher than the current level of 16 and the Min to be lower than that. Overall, I agree with Konstantin’s suggestions here as they intuitively feel just.

Parameter Proposal

With b being our main parameter left to adjust, we can see the impact it has on individual Indexers and the network aggregate in the linked file below. The data is from Graphscan which I pulled today (9/14/21). You can adjust different values for b and evaluate changes in capacity. I myself landed on 0.40 and the curve would then look like this:

We have now achieved a higher degree of distribution for y, where larger Indexers are below 16x and smaller Indexers are above 16x. At a b value of 0.40, the Remaining Delegation Capacity in the network is reduced by 2.7bn which would bring down total capacity from 14bn to 11.3bn. The capacity for the top 6 Indexers would be reduced by 5.8bn, while the capacity for all other Indexers would increase by 3.1bn. In sum, a b value of 0.40 would achieve the goals outlined in the opening of my response.

Calculate Indexer Delegation Cap as a Curve

[EthWiz]

Hi Oliver,

I’m having a difficult time understanding this proposal, even after looking at the spreadsheet you provided. I think my confusion is primarily with what the blue dots on your graph(s) represent, and how much these changes will displace the existing network.

Modifying my calculations to make the x-axis “total network stake” (self-stake + delegated stake) and changing the a, b, and c values you provided gives me this chart:

which appears to displace far more indexers currently participating in the network.

Am I missing something here?

[EthWiz]

(I should also note here that with these parameters, all blue dots over the orange line would become overdelegated immediately). This may be a feature to the enhancement, of course, but I am interested in hearing more details.

[Oliver]

Per your OP, you define x as “represents the indexer’s owned stake (either in relation to the largest network stake, or a percentage of the total network self-stake. This measure is open for discussion.”

Both of these options are relational numbers. My chosen x represents “what is an Indexer’s self-stake as a percentage of the total network stake”. I have used total network stake (vs. self-stake) for the above-mentioned reasons, which is to soften the impact on Delegator uncertainty which this new cap method introduces.

The x-axis in my chart hence represents % of network stake of an indexer’s self-stake. The blue dot furthest to the right would represent the Indexer with the largest self-stake, while the blue dot furthest to the y-axis would be the smallest Indexer. The line therefore represents an Indexers new multiplier based on his self-stake share in the network which would need to be somewhere on the line.

Per my calculation in the spreadsheet, only one Indexer would be pushed into overdelegation based on the proposed parameters. Maybe there is a difference in the formula between our models, though I checked the formula twice to ensure it’s the same as yours. Maybe you can point out if there is a difference.

[EthWiz]

Ahh, I think I see the difference now.

The line therefore represents an Indexers new multiplier based on his self-stake share in the network

Your calculation is based off the percentage of total stake in the network- mine is simply based on total stake in millions.

Now that makes sense, and your logic falls into place. However, this does mean that the algorithm/calculation required needs to be changed, if I am correct.

Instead of:

y = (a - c)b^x + c, where

•	a > 0,
•	0 < b < 1
•	c >= 0

and

•	y represents the multiplier for an indexer,
•	x represents the indexer’s owned stake (either in relation to the largest network stake, or a percentage of the total network self-stake. This measure is open for discussion.)
•	a represents the maximum delegation multiplier possible (for indexers with at least X self-stake)
•	b represents decay rate between 0 and 1 (likely .999999) to determine the rate at which delegated GRT allowed decreases, and
•	c represents the minimum delegation multiplier possible (to receive delegations)

We would need to update to:

y = (a - c)b^((x / t) * 100) + c, where

•	a > 0,
•	0 < b < 1
•	c >= 0

and

•	y represents the multiplier for an indexer,
•	x represents the indexer’s TOTAL stake (self-stake + delegated stake)
•	a represents the maximum delegation multiplier possible (for indexers with at least X self-stake)
•	b represents decay rate between 0 and 1 (likely .999999) to determine the rate at which delegated GRT allowed decreases
•	c represents the minimum delegation multiplier possible (to receive delegations), and
•   t represents the total network stake in the protocol

the changes here being that b^x becomes b((x / t) * 100) to account for a network percentage rather than an arbitrary value.

This is an improvement that I am in full support of.

[Oliver]

Yes, very true. x is in fact a formula itself in my model and it makes sense to spell it out accordingly. This right here is exactly how I have it as well

@EthWiz

We would need to update to:

y = (a - c)b^((x / t) * 100) + c

[EthWiz]

In that case, I think this is great. From here, I think the best next steps would be to hear from folks like @KonstantinRM and others to see if there’s anything we may be forgetting.

[Oliver]

I have continued evaluating the new model with regards to its impact it has on the future. I ran dozens of scenarios and have captured my findings in the presentation below. I have come across some significant insights that I’m sharing there and I also make a recommendation of an adjustment to the model.

Prior to advancing the discussions, I would recommend reading the findings in the presentation as many different dynamics are explained that have not been discussed yet. Happy to conduct a workshop to talk about the content of the presentation which covers a lot of ground and which may raise some questions.

Indexer Delegation Cap Change Analysis.pptx

[KonstantinRM]

Looks like a very big and complex work, thanks.
But I think I missed something.
It seems that we changed the basic paradigm with a self stake in M to share of the network. After that, you made a lot of experiments and rejected basic options. But all reasons appear from changed Self-stake to the Network share. Because if we keep the self-stake model, all new GRT in self-stake will reduce multiplier, which totally makes sense and caped Large Indexers.
Maybe I understand your proposal wrong, but the basic model looks more simple in implementation for me and solve our issues now and in the future (where we actually don’t know how many new Indexers and delegations we will get)