Proposal to change the 'indexer cut' mechanism

Governance & GIPs
1

Hello! Gavin from Figment. This is a proposal to change how indexer cuts work.

Problem

Unintuitive, volatile commission rates

New delegations and undelegations dramatically change the staking income for indexers and validators unless the cut rate is regularly adjusted.

Why is this happening? Staking income for the indexer and delegators is pooled before the Indexer cut is calculated.

Potential Solution

Separate ‘indexer staking income’ from ‘delegator staking income’

Query fees and new issuance rewards (aka “inflation”) captured as staking income will be pooled and distributed pro-rata (ie. by stake weight) to indexer and delegators. A commission amount (or “cut”) set by the indexer will be taken off the top of the delegator staking income to pay the indexer. What does this look like?

Outcome

Intuitive, stable commission rates

If you delegate to an indexer with a ‘rewards cut’ and ‘fee cut’ of 10%, it means you will get 90% of whatever your staked GRT earns and your indexer will get the other 10%. If you run an indexer, you will earn your pro-rata staking income in full and a 10% commission on your delegators’ staking income.

What you see is what you get. Unless the indexer changes their cut rate, this will be the outcome for both stakeholders, regardless of how the delegation amounts change.

Example

Fee cut @ 25%; Reward cut @ 10%

  1. Indexer sets query fee cut to 25%

    • 100% of the query-fee income captured by the indexer’s stake is distributed to the indexer.
    • 25% of the query-fee income captured by each delegator’s stake is distributed to the indexer.
    • 75% of the query-fee income captured by each delegator’s stake is distributed to that delegator.

  2. Indexer sets reward cut to 10%

    • 100% of the new issuance (aka “reward”) income captured by the indexer’s stake is distributed to the indexer.
    • 10% of the new issuance income captured by each delegator’s stake is distributed to the indexer.
    • 90% of the new issuance income captured by each delegator’s stake is distributed to that delegator.

Grateful for any feedback and/or questions.

9 Likes
2

Thanks for kicking this discussion off, Gavin. This is definitely on the minds of many participants I speak to.

I think there’s a clear community signal forming that the cut mechanism is a difficult thing to grasp for all involved. The last couple of months of protocol interaction and the feedback from the community have shown that it’s a major challenge to even educate on the impact of various cut configurations because they are so heavily tied to the network dynamics. I am in support of initiatives that explore alternative ways to express and manage what is referred to as commission on most networks.

Before I personally dive into asking questions around the details of this proposal, I would be keen to hear from some of the E&N team on the design decisions and history of this corner of the network - why we are where we are today with the cut mechanism. @Brandon @davekaj

2 Likes
3

I am also in favour of a proposal to make the indexer cut mechanism simpler to use for all parties.

What Gavin has described seems to me to be the most straightforward solution, and is in line with patterns that a lot of people in crypto are used to.

The question I do not have an answer to immediately is how hard it will be to implemented. It is something we can dig into, but right now our focus is the Indexer Rewards proposal. I imagine a proposal like Gavin’s could be used, with slight modifications to make it implementable in Solidity.

@cryptovestor Originally we designed the indexer cut mechanism to be like this. As we began to implement it, we didn’t notice the non-intuitive aspect of how it keeps changing, and how it is not user friendly. By the time we realized it, I think we were only a few weeks away from launch, and done our audit. We opted to not change it because of these time constraints.
It also would have been something we would have caught if we had time to do delegation in the testnet, but we didn’t. So overall, I personally would be open to changing it and making it more intuitive.

I think I would be able to provide more in depth thoughts later on this week, but right now I am focusing on the Indexing Rewards proposal so I don’t want to dive into this yet. I am excited to see what others come up with in the community for changes or different angles from what Gavin is proposing!

4 Likes
4

Hi @Gavin

I have a few questions, because i’m failing to see much more than “10% should mean 10%” on the suface here, and want to know more about how you think the implementations of this should work vs ‘now’:

  1. I see no mention of Curators and where they fit in to this plan?

  2. How would this work when taking fees vs rebates in to account? How is an indexer that is more proactive and performant with their allocation weight meant to conduct themselves, versus how things were expected to play out in the current system (rising to the top via merit)? Effective cut of rebates would be updated/reflected when exactly?

  3. How should reward pooling (pre-distribution) work with the above? Should there be multiple pools each with their own distribution mechanisms? In what order should the cuts be computed between each stakeholder group or pool?

  4. How would this system handle cuts with overdelegation?

From my perspective, a lot of the current confusion people have could have been solved already by abstracting the 'cut %' away and replacing this with 'effective cut' as a front-facing metric on the Graph dApp specifically, as a primary metric/view in the table. It’s been a recent addition there, but is currently still hidden behind a hover/tooltip, for some reason. Even though this is the primary factor many Delegators are looking for. (Shout out to @warfollowsme and other dashboard creators who made things more clear for Delegators in this way)

The argument i saw in regards to not highlighting things this way on the Graph dApp, is that this kind of thing should not be held up specifically as the primary motivator that Delegators base their decisions on.

But if that’s the case… shouldn’t we consider whether this proposal goes one step further than that?

Imagine if a Delegator’s primary concern is APY, which is apparently the case for a very large portion of them:

  • With the above proposal, they could (would?) always go for the lowest cut, if things like stake:delegation ratio no longer were of any concern, nor had an impact on their final payout values. Effective cut is no longer a moving target (within the bound of stake ratio) and can be ignored.

  • Delegations would likley be stickier than they already are (highly due to the 28 day thaw feature) and re-delegating would not matter, unless you find yourself on an over-delegated Indexer…

  • … which is unlikely to happen when you already have a handful Indexers who can accomodate 1/3rd of the supply between themselves, before becoming overdelegated.

In my opinion, this would railroad Delegator behaviour even more than it already is by the current system and presentation of data. And simply makes monopolization of the market much less effort for large stakes.

If those top handful promise a low cut, why go elsewhere when you know you no longer need to consider delegation ratios to determine your final payout. Unless your motivations are more idealistic? And if you believe idealism is the norm, i invite you to check what % of the 1.6bil in current delegations are currently held by the top few, despite higher APYs being offered by many others.

Another suggestion made by many people, since at least December, was to simply flip the cut % variable, so that 10% means fee and not cut, to make this value align to what people expect from other ‘staking’ mechanisms.

The response at the time made it sound like that alone would present an unreasonable amount of effort. But from what i can tell, the proposal above would require a much deeper overhaul of how the system and pooling altogether works. So i would have expected a little more hesistation than i’m seeing upon first impressions.

Which takes me back to my former points:

  • Is the system really broken, or just hard to understand on first glance?
  • Can tooling (EG dashboards) not be the end-user’s solution, if the problem is how that data is being presented?
  • Is changing the system to act in the way proposed not going to exacerbate some current issues, like centralization, and encourage/enable behaviour that contributes to this?
7 Likes
5

Hi Gary,

  1. This is a proposal to address the indexer-delegator relationship, so curators are out of scope.
  2. Could you reword this? I’m having difficulty following.
  3. I’m hoping that the Edge & Node team will champion an implementation that integrates securely and effectively with the existing system.
  4. I don’t know how overdelegation should be handled in this sort of change. Personally I think overdelegation should not be possible, and perhaps that should be added for consideration into the scope of this proposal.

Is the system really broken, or just hard to understand on first glance? Yes, kind of. It technically works, but indexer cuts of delegator earnings are very volatile and I don’t think that they should be.

Can tooling (EG dashboards) not be the end-user’s solution, if the problem is how that data is being presented? No, because it’s primarily a material issue (ie. volatility), not so much a perceptual issue.

Is changing the system to act in the way proposed not going to exacerbate some current issues, like centralization, and encourage/enable behaviour that contributes to this? I don’t see how, but it could be because I’m not following your reasoning.

3 Likes
6

Its too early to make changes now. There is a ton of education that must occur for a delegator to get started, and begin making informed decisions. Its not unreasonable to expect them to spend a few extra minutes to learn how query fees work. I think this problem of confusion can be readily solved by more transparency and education (eg. effective cut).

It was designed this way for a reason, to be very flexible, so I think we should at least give it a chance to let it play out, and figure out how we can adapt it to our own liking.

3 Likes
7

Gavin,

The fact that there is so much debate about Indexer cut illustrates the fact that it is both complex and divisive. We therefore appreciate this subject being raised because it needs to be resolved and resolved against two criteria:

  • Clarity
  • Fairness

We like the essence of what you have suggested because it does improve clarity. What we do not know is whether it provides fairness (at the % levels implicit).

What is clear is that The Graph requires more investment and more proactive effort as an Indexer than conventional network validation. What we are currently waiting for is a statement from the Foundation about their initial recommendation that Indexers should be retaining the majority of the rewards, presumably because of the effort required. Until this is forthcoming, as Cryptovestor has indicated, it is going to be difficult to progress this much further.

As Dave has indicated his current priority is ensuring Indexers are able to access any reward at all. So lets not lose focus on that. Dave also highlights that we do not know how hard it will be to implement or indeed how long it may take. It may take a long time based on the experience of trying to get Indexer payments resolved. That is not a criticism, just a reflection of how busy the team are. Under these circumstances we may want to consider what interim measures could be put in place.

Fattox also makes a very good point about whether the system is really broken or is just difficult to understand. It is slightly counter-intuitive and at odds with other networks. Yet Graph is not like other networks!

3 Likes
8

  1. They’re not out of scope…

  2. … which is kind of where this was leading.

As for the original point - Wouldn’t having some kind of ‘effective cut’ that tracks to the payout, potentially hide how performant an Indexer actually is, if Delegators are looking at effective cut rather than having indicators based on that performance (EG rebate ratio)? An effective cut % only tells me how much of the slice i’m getting, not how big that slice is, which makes it harder to judge and advertise based on performance.

  1. Kind of ties in to the above.

  2. Another topic then, yes.

I appreciate @pi0neerpat for mentioning that education is very important, which is partly what i was getting at, but should have explicitly gone over. And i also think it’s a little premature as @Mike-LunaNova points out.

However, if you go in to more detail of this vision and how you think it should/would look and play out from a high-level perspective, i’d be interested in how you see it all fitting together, alongside any concerns already made by myself and others.

1 Like
9

Hi Pat,

The core problem is with volatile indexer fees. The intuitive part is an unnecessary side effect.

10

Hi Mike, the core issue is with volatile indexer fees, not user confusion.

11

Hi everyone, thanks for engaging. I plan to present this proposal using an interactive example at the Graph Town Hall on Tuesday. I hope that you’ll be able to attend. Brandon is supposed to be attending, so he can likely provide insight into how the current implementation came to be.

Here’s what I’ll use for my demo. Spreadsheets aren’t my forte.

1 Like
12

Here is my personal opinion on the Graph Staking & Rewards system in general and specifically on this proposal.

Yes definitely, when we first faced with the Graph Staking system there are many questions about how things work. No one will argue with that. But immediately afterward another question arises - why is it so and is it justified? And if you look deeply into how the management of rewards and staking works, you understand that everything is in its place. The main difference between The Graph and other staking systems is that distribution rewards are not tied to the stake itself, but to the part of that stake that is used - the allocation. It is the root of the whole protocol. Right now the Rewards Manager doesn’t know which part in the allocation belongs to the indexer and which to the delegators and just gives the whole rewards to the indexer’s delegations pool. I’m not a smartcontract developer, but I know that the main task of the programmer is NOT to complicate the calculation process, so it doesn’t consume an insane amount of gas and the protocol isn’t too expensive.

The proposed solution does look simple, but in reality it requires reinventing the entire logic of the staking & rewards system. Perhaps there is a simpler, more elegant solution. But find it is clearly not a task for the graph team right now, there are much more important tasks. It seems to me that this is an ideal task for the community. If detailed suggestions on how to make The Graph Staking system simpler come up, I’m always happy to discuss and test them. Right now unfortunately all I see is ‘Separate ‘indexer staking income’ from ‘delegator staking income’’ but it’s not a solution, it is a formulation of the problem to be solved.

9 Likes
13

I do agree that showing the protocol cuts instead of the effective cuts is quite unintuitive for delegators, having said that I don’t think that changing how the underlying system works is the right approach, at least right now.

I’ll address the problem, but as two separate problems, since I don’t think they are intrinsically tied:
Intuitive rates:
As I said, I do agree the currently shown rates are not super intuitive, but this can be fixed quite easily (and has been done by third parties), by swapping the currently displayed cut to actually display the effective cut.

Effective cut volatility:
Effective cut is quite volatile at the initial part of the curve, passed the inflection point, the effective cut becomes quite stable within a certain range, and you can even set your parameters to avoid going higher than a certain effective cut. You certainly would need to frequently update if you want to set a fixed effective cut, but you could get away with updating every once in a while (or maybe almost never) if you have no problems working within a certain effective cut range, as long as your delegations don’t swing massively.

Here’s an example of an effective cut curve

image
image888×496 14.4 KB

We found it quite useful for our particular strategy of incentivizing delegators at lower amounts of delegated stake.

As you can see, after you have at least 20% delegation capacity filled, you will start to experience a more stable effective cut. Changing your protocol cut will only move the curve higher or lower, but it won’t change the shape of the curve, so that relationship should still be valid.

This means that after a certain point, you won’t need to update your cuts frequently, as long as you don’t need to be exactly fixed to a specific effective cut and can still run your business with a flexible effective cut.

Will an implementation be possible to maintain a fixed cut?
Without going too much into smart contract development, I think we can already see some possible issues.
How would you maintain the fixed cut to the delegated stake if delegated stake changes?
It would greatly depend on what you understand for effective cut, since if you only care about allocated delegated stake (which would probably be the only way to implement it), if the amount of delegated stake changes, and you don’t immediately fully allocate, you would have some distortion because a part of your delegation is not generating rewards but is getting rewarded anyways.
Taking that into consideration, your effective cut for the total delegated stake would still be volatile, depending on your optics of what the effective cut means.

Pros and Cons of the proposal:
As previously discussed, I don’t think that unintuitive cuts aren’t fixable with the current implementation, since we can just display them instead of the protocol cuts.

Pros:

  • Being able to set a fixed effective cut easily

Cons:

  • Needs a relatively major refactor of the reward system
  • Variable effective cuts strategies will need to be constantly updated to be able to work (just as fixed effective cut strategies are maintained now)
  • Might still suffer volatility of the cut depending on the implementation
  • You might lose the possibility of negative cuts to incentivize delegations (depending on the implementation)
5 Likes
14

There’s been quite a number of solid concerns and counter-arguments, so far they’ve seem dismissed rather than addressed. When trying to improve things, it’s critical all aspects and perspectives are thought through every well, so that the solution doesn’t actually make things worse or has unintended side-effects.

3 Likes
15

Thanks for the clear feedback, Juan.

If negative cuts are important, perhaps that feature could be added. I’ll leave it up to the team to comment on implementation.

16

Hi Koen, I’m not in a position to address all of the concerns and counter-arguments. In some cases I’m not able to fully understand some of the feedback I’ve received, so I’ll likely need assistance from the core Graph team and from other stakeholders.

17

Hi Gary, I don’t mean to be dismissive, but I haven’t been able to follow the feedback that you’ve provided.

  1. How could curators be affected?
  2. Could you clarify the concerns I haven’t addressed? For example:
  • if we do x, then y will happen
  • y could be a problem because of z
1 Like
18

Hey! I wrote a GIP (and implementation) of what is described in this proposal by Gavin.

I’m posting the link to the proposal for convenience. It will be available on Radicle soon for editors to review.

Open for feedback.

8 Likes
19

Amazing, thanks @ari! Just tagging @Joseph to help review

2 Likes
20

Hey Ariel, does this proposal have a forum thread? I couldn’t find one. I have some questions I would like to ask around how related functions might or should work after this change, specifically the cooldown period.