Proposal to change the 'indexer cut' mechanism

  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

Hi Pat,

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

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

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

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.


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

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.


  • Being able to set a fixed effective cut easily


  • 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)

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.


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.

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.

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

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.


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


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.

Hey Jim, we can discuss in this thread. I posted a potential implementation here because it is based on the proposal described in this post.

Sure. So I am thinking about a couple of Quality of Life improvements for Delegators, and from a lay point of view, they might make sense to address as part of this cut mechanism overhaul, I would need your guidance on that. Here is what I am focussing on:

  1. Improve the utility of the cooldown period by changing how it works (it is less useful today and rarely used)
  2. Adding optional rate change cap and max rate cap to the new cut mechanism

So for #1, I still need to gather opinion on this, but I feel that the cooldown function is little more than theater in its current form - an Indexer can still jack up cuts immediately after than period ends. I am wondering if there is some way to tie cooldowns to something that would give Delegators more peace of mind than just a number of blocks where cut cannot be changed. I will try and cover this in Office Hours to gather ideas around making the cooldown more useful.

For #2, it is common practice to have a “maximum allowable change” to commission rates on other networks. This provides Delegators, in our case, with a very high level of confidence that their Indexer cannot act dishonestly by changing cuts in rapid succession. Here is an example from Cosmos:

“Max change rate” prohibits the validator on this network (Cosmos) from changing their commission rate by more than 1% per day.

“Max rate” sets a ceiling to the validator’s chargeable commission - they cannot raise commission above that rate.

These parameters are set on the initial registration of the validator and can only be reduced after being declared. [ref]

Does it make sense to address these feature improvements as part of this proposal, from a technical point of view? Personally I would rather see the cut mechanism and cooldown mechanisms fixed together, as the combinations of changes represent a very significant increase in Quality of Life for Delegators.

Edit: The more I think about it, the more I think the cooldown feature could be completely replaced by the feature described in #2.


I think that the objective of this GIP should only be to reduce the amount of work needed from an indexer to keep the effective cut-rate at the desired rate, and to facilitate choosing an indexer for delegators.
What’s interesting here is all the thoughts and ideas that this GIP are generating concerning the impact on delegators.
In my opinion, we need to focus on one thing for this GIP and that is to make the effective cut calculation automatic. Because we all agree on its importance, and it doesn’t impact much the protocol.
All the other suggestions will directly impact the delegator model, which I believe needs a visit on its own.
Questions like, how to use the cooldown parameter to protect delegators, max and min cap rates, liquid rewards, thawing period, a delegator delegating to an open allocation…
All these questions are intertwined and fall under the delegator’s model, which I believe when the time comes needs to be treated together.

1 Like

That’s fair. This change on its own represents a significant positive change for both Indexers and Delegators.

My rationale for the additional work is that it sometimes makes sense to address issues when touching the same plumbing, so to speak. I agree that more discussion is required on how to address shortfalls in the commission system however I also want everyone to be cognizant of the fact that we have been talking about some of these issues for six months and have yet to resolve them.

As discussed with @Oliver, @Joseph and @chris on Office Hours today, we can look at putting some focus on a more formal upgrade roadmap on Delegation improvements among other proposals on the table. This would be a very useful planning tool for all stakeholders.


Hi @joseph, thanks for participating.

Definitely, this proposal and the implementation was more focused on tackling the indexing rewards calculations to make it so the rewards cut doesn’t need constant change to maintain the yield for delegators. The idea is that if indexers gets to a stable cut the cooldown feature can become more relevant. It was less effective if you needed to change it frequently.

These are the highlight of changes:

  • By changing the calculation the yield is more stable for delegators, less need to change the rewards cut.
  • The share of rewards is stored when the allocation is created. If the indexer were to change the conditions just before the allocation is closed it will have no effect. This is beneficial for delegators and honest indexers. Again more stability.
  • It also fixes a condition where a delegator with just few tokens delegated could keep the full share of delegators rewards if no other delegator delegated. This is because the new formula first takes into account the delegation to total-stake-ratio.

@cryptovestor I’ll capture your proposal about the cooldown period and think about it. I’m planning to go to the next Office Hours to participate on the discussions you had about the upgrade roadmap. Additionally, I’m doing some research with Brandon to see the possibility to remove the delegation tax and change the delegation unbonding period for a different mechanism. This would be a capital efficiency improvement for delegators too, but depends very much on calculations to ensure that some economic attacks are not possible.


Great suggestions @cryptovestor. Want to do a quick plug for this Delegation Feedback rollup thread if there’s anything you’re seeing that is not captured there: Delegation Feedback Rollup Thread

Agree with what others have said that it makes sense to do changes incrementally. It’s been hypothesized that we may see longer thawing periods once indexer rewards calculations are more stable.

As Ariel mentioned, a side benefit of this change is also that delegation parameters are locked in for allocations when they are created. This is in a similar spirit to the suggestion above around limiting the rate at which delegation parameters can change.


Thawing periods? Or cooldowns? :nerd_face:

1 Like