Indexer Cut Simplification Proposal

I am creating this new topic as a follow up to the discussions in this post where a specific GIP by @ari may have gone unnoticed by the broader community as it was a response in the thread. To summarize, Ariel’s proposal introduces solutions to three concerns that frequently come up in various community discussions and posts:

  1. Simplified cut settings interpretation (Delegator benefit)
    Delegators no longer need to translate an indexers cut % into an effective cut % and then evaluate different levels. Whatever cut % an indexer sets (for bot Indexer Rewards and Query Fees) becomes in fact the critical number to evaluate. That means, as an example, one Indexer’s 10% setting will in fact mean that the impact for delegators is twice as high as another Indexer’s 5% setting.

  2. Simplified cut settings management (Indexer benefit)
    Indexers no longer need to constantly monitor their delegation-to-indexer stake ratio and make cut adjustments to maintain their desired target return %. The new mechanism auto-adjusts for delegation changes and reduces the times Indexers are required to change their settings.

  3. Eliminate sandwich attacks (Delegator benefits)
    Cut % are locked in at the time an allocation opens (vs. closed currently). That eliminates the possibility for a sandwich attack to occur where cut % are changed unexpectedly around the time rewards are allocated and removes uncertainty for Delegators about their expected rewards yield.

Here you find the details of the proposal which is called Stable Delegation Rewards Yield

The GIP has been created over two months ago and has not advanced due to lack of community feedback that demonstrates strong support implementing this proposal. Feel free to provide your feedback in this post as we will use it to gauge level of community response and whether to proceed further with it. Thank you!

25 Likes

Just reiterating my own opinion on this from others threads - strongly in favor, these three three improvements have received positive feedback across multiple disparate threads. Improves UX for both Delegators and Indexers and makes Indexer commission rates much simpler to express and manage.

10 Likes

Totally agree with the previous speaker! :slight_smile:
We discussed all of this a lot before. And just waiting for implementation. Strongly support all 3 points from my side.

6 Likes

I agree with the other two posts. These changes will decrease the complexity and increase the safety of delegations. To me this seems like a positive change!

6 Likes

I’m strongly in favour of these improvements as well. I would like to think the majority, if not all indexers would be in favour of these improvements. The original thread and the idea of these improvements have had good feedback, it just seemed to have been forgotten or put on a back burner?

How much support is needed to move forward with these improvements?

5 Likes

+1. Strongly in favour!

3 Likes

Make that +2! The technical specs check out well and I’m strongly in favor.

5 Likes

This simplifies the metric used by most new delegators, and everyone wins when protocol friction is reduced. Strongly in favor!

4 Likes

Everything that goes into simplifying new delegators to come on board is very much welcomed.
Strongly approves this :+1:t2::+1:t2:

3 Likes

Totally agree with this change.

3 Likes

Just showing additional agreement.

3 Likes

I am very supportive of this. Simplification and greater certainty for both indexer and delegator expectations.

In addition to these proposed changes, I think it would be cool to add a new metric on the Graph Explorer page called the Productivity Ratio (or something along those lines).
Productivity Ratio = (indexer rewards + indexer query fees) / (indexer stake + delegator stake). Basically this ratio would inform delegators how efficient each indexer is at earning GRT and show that, in many cases, smaller indexers outperform the larger ones and may be the better choice when making delegation decisions. While I can only speak from my own experience, my smaller indexers have outperformed my large indexers pretty significantly with the 7 months of data I have (in terms of my yield). I think finding a way to chart this data to show how the metric has varied historically would be the best/truest way to express it since it’s a very dynamic calculation, but maybe there could be a way to have it as a column on the Graph Explorer. Charting it over time would also give insight to reputation of each indexer. Most importantly, I believe it would create a more decentralized ecosystem.

2 Likes

One last thing building on my post above… Each time I visit the Graph Explorer page, the indexers are default sorted based on Indexer Owned Stake. I think this naturally leads new delegators to select an indexer in the top 1-10 in the same way search engine optimization works (I have no data to support this but just my gut feeling). Perhaps changing the default sort to something like the Productivity Ratio or (Productivity Ratio) x (1 - indexerCut%) would lead to greater decentralization. If sorted like this, the indexers who hold down the top 10 spots would change on a much more frequent basis. It’s not often that the top 10 changes using the current default sorting method. I hope this would also contribute to more decentralization.

4 Likes

Totally support this initiative!

2 Likes

Very much agree on all 3 points raised, strongly in favour.

2 Likes

Thank you for making this post.

Undoubtedly The Graph currently has one of the most complex and opaque systems for understanding delegator rewards. The fundamental difference in how the protocol operates from a delegating/staking point of view, when compared to POS networks, also means that higher indexer earnings (cuts) are often misunderstood.

We would like to make the following points:

  1. With the way the network operates it is not unusual for a good indexer with a high fee cut to provide significantly more returns to a delegator (per unit of GRT staked) compared to a poor indexer with a very low cut. Just opting for Indexers with the lowest fees may not be in a delegator’s best interests, something which should be communicated clearly. Therefore @dannyb’s proposal is a very promising one and we would like to see this and other options explored in more detail.

  2. In the current system it is possible for the indexer to reward delegators with far more than the delegator’s own stake is actually earning (ie. a negative cut). This proposal effectively puts a floor of 0% for the cut an indexer can apply to a delegator’s rewards. We think this is undoubtedly a good change and question whether it is worth going further and setting a higher minimum indexer fee.
    The reason for this second point is that we often see a pernicious “race to the bottom” on fees in many networks. Wealthy operators are often prepared to run at a loss for prolonged periods to shake out smaller players. This increases network centralization and creates an environment that discourages quality operators who are prepared to invest in good hardware and processes (because they are unlikely to recover their costs) and instead favours those who will only put in the bare minimum of effort and resources. Superficially this looks unimportant in the short term but is highly damaging longer term and will lead to more centralization and a less capable network.

In conclusion, LunaNova are very supportive of this proposal but would like to have discussion around the points we’ve raised before it is finalized. This should help extract the maximum value from the work necessary to implement a change to the fee cuts. Whatever is implemented needs to be accompanied by very clear articulation of the value of indexing work.

5 Likes

This is going to be a very important change vote in favor

2 Likes

Support for all 3. Hopefully this passes.

1 Like

I’m supportive of this proposal because it simplifies the life of both delegators and indexers, making the protocol easier to operate (make decisions) and still more accessible for newcomers.

1 Like

In favour of the proposal, and agree that it would be beneficial to have some discussions around the points raised here.