Proposal to tie Cooldown to Effective Cut

Governance & GIPs
1

This is a proposal to change how the cooldown mechanism works.

Problem

The cooldown feature, as currently implemented, does not give the intended incentives.

The idea behind the cooldown is that an indexer can pledge not to change their cut parameters until a cooldown period has expired, giving delegators confidence that they can expect stable terms for the duration of the cooldown period.

However, the protocol doesn’t let indexers specify their cuts as an effective cut %, and delegators would find a stable effective cut preferable over stable values to the current cut parameters.

The result is that an indexer who wishes to maintain a stable effective cut (the desirable behavior from a delegator point of view) would not be able to make use of the cooldown feature, since to maintain effective cut requires periodical tweaking of the cut parameters currently offered by the protocol (but that have to be kept stable to use the current cooldown feature).

This creates a counter-productive feature, where delegators looking for indexers providing stable effective cuts have to avoid indexers using the cooldown feature.

Proposed solution

Change the cooldown feature so that it relates to a stable effective cut.

On a high level, the proposal is to change how the cooldown feature works, but leave all other parts of the protocol as-is. The current cut parameters would not have to be changed. The cooldown feature would be implemented such that the indexer is allowed to change their cut parameters as needed in order to maintain a stable effective cut.

This proposal is meant to be high-level with a focus on the intention behind it, which is to make the cooldown feature more aligned with its intended purpose by tying it to effective cut. This thread is a forum for hashing out details. However, a few things have already come up in discussing this idea in the discord channels, which I will note.

Adjustable Cut Parameters during Cooldown
The cut parameters could not just be locked during cooldown but would have to be always adjustable in a direction that reduced the distance to the promised effective cut.

Tolerance
There would need to be some tolerance to how precisely the effective cut % would have to be maintained.

Flagging Violations
A consequence of this proposal is that an indexer that promised by using cooldown to maintain an effective cut but did not update their cut parameters as needed would have to be flagged as not respecting their cooldown and some counter-measure would be taken (slashing, compensation to delegators, disqualification from using the cooldown feature for a while, or merely adding a violation flag that is viewable in tools to their history - whatever seems appropriate). It is presumed not to be appropriate nor feasible to force the indexer to adjust the parameters.

Frequency Parameter
A concern that has been raised by indexers when discussing this is that using this cooldown feature would be costly for indexers in terms of gas required to constantly tweak their cut parameters. To alleviate this, it is possible that the indexer should be able to specify how often they pledge to update their cut parameters (if needed) to maintain effective cut as a parameter to the cooldown feature.

Parallel Cooldowns
The proposed new cooldown could be added in parallel to the existing one. Indexers who prefer to use the old cooldown system (for lower gas costs or other reasons) could do so. Note that the two systems would be exclusive (an indexer could not use both types of cooldown at once, since they offer contradicting promises)

3 Likes
2

Hey @Mats, great to finally have you here on the forums!

Going to the main topic, I think the current implementation of cooldown blocks is good enough for some strategies, but at the same time it’s impossible to use for other strategies.

This proposal would help indexers that want to offer a stable effective cut to be able to set a cooldown block parameter so that delegators know what to expect.

Currently, the main issue with those types of strategies not being able to set a cooldown block (because they need to constatly modify their cuts to maintain a stable effective cut) is that delegators don’t know why they are changing them all the time. In my experience, this misunderstanding happens because some delegators don’t know how the protocol cuts work, and because the official dashboard displays the protocol cuts instead of the effective ones, making that even more confusing.

While I do think it would be good to improve on the cooldown block functionality, maybe adding flexibility so you can adjust your cuts to meet a specific effective cut target, I think it would be confusing for newcomers to understand why the parameters are changing if the indexer has a cooldown block set, and thus, shouldn’t be allowed to change its parameters. This basically sends us back to another possible misunderstanding, especially if we keep showing the protocol cuts in the dashboard.

Another concern is that we would need to be able to display more than one type of cooldown block (according to your proposal), which would add more complexity to an already complex system, this would also increase the likelyhood of misunderstandings, and thus, make it even harder for new delegators to understand.

Also, adding another slashing mechanism for indexers just because they might’ve missed one of their updates seems controversial, given that indexing is already demanding enough.

I think that a good middle ground would be to have only 1 implementation of cooldown blocks, which could allow for both strategies. This could be achieved by using your implementation, but easing some restrictions on indexers, so you can use the cooldown block parameter to set a value and avoid updating it (like the current implementation), or set a value and stick to the effective cut curve it gives, if you want to do it (the effective cut curve generated can’t go past the effective cut number that it generates on a fully delegated indexer, so effectively it sets a maximum effective cut already)

This way, delegators will more or less know what to expect, and they will be able to know that an indexer won’t be able to increase the effective cut past the point that they already set when they updated the cooldown block parameter, without adding more strain to the indexers side via slashing or other types of punishment.

Also, this way, the implementation remains a little bit simpler, and thus is more likely to be easily added to the protocol.

3

Hi @juanmardefago ,

Thanks for the awesome feedback. It should definitely be the ambition to come up with the lowest-impact implementation so I think your middle-ground suggestion is great!

I also agree slashing is over the top, personally I think a flag that shows in the tool UIs would be enough. I even think that the protocol preventing the indexer from changing the cut parameters due to cooldown might be a little strict, I would prefer they can but there is some way to see if they have. That is, I would prefer to see cooldown as more of a pledge that can be broken at some cost rather than a lock down of functionality. Indexers should be able to do what is necessary to survive but at a possible hit to their reputation.

It’s an aside perhaps, but what do you see as the “legitimate” use case for the current cooldown, in what situation would it make sense as a delegator to look for an indexer that is using the current cooldown feature?

2 Likes
4

As a delegator, I’m fully in favor of this proposal. While delegations are in flux, the indexer cooldown is essentially useless. This would be a powerful tool to help small indexers compete!

As a delegator, I can’t really think of anything, at least not during early days when delegated stake is relatively unsettled.

If I see a cooldown in place I think one of two things will happen.
Delegations will increase, meaning the indexer is less self-staked, and therefore the effective cut goes up- a negative for me. Delegations decrease, meaning the indexer is more self-staked, and therefor effective cut goes down- a negative for the indexer.

I can really only see cool down being useful who an indexer who is very near their delegation cap and has stayed that way for a while and is therefore unlikely to see a lot fluctuation in self-staked %.

As a tool for indexers to attract new delegators, it is basically useless in its current form, as a tool for delegator retention, I suppose it may be useful, but an effective cut% cooldown would be equally valid in this scenario, and extremely more valuable in all other scenarios.

5

Hi again @juanmardefago

Your middle ground solution is really growing on me. Basically if I get you correctly, when an indexer commits to a cooldown it would work like now but they could also (optionally) provide a “target effective cut %” parameter. The protocol would allow the indexer to update the cut parameters as long as it resulted in a better match with their target effective cut %, but they would also be free not to update their cut parameters. The indexer would not be punished for not updating their cut parameters, even it that meant deviating from their target effective cut %. Updating the cut parameters in a way that would move away from the target effective cut % would be prevented by the protocol during the cooldown period.

That seems to solve everything, all the problems with punishments for breaking the cooldown terms go away, as do issues like tolerance and frequency commitment parameters that I listed in my original post. Very neat. It took me a while before the penny dropped that you really solve all those issues so elegantly, but I think you do.

I will update the proposal to be this. Edit: turns out I can’t (figure out how to?) edit the proposal post.

1 Like
6

Hi @Derkhersh

This would be a powerful tool to help small indexers compete!

I think so too, and I think it would increase stability and help make delegating more accessible and attractive in general. Together with making effective cut a sortable column on https://network.thegraph.com/ instead of just a tooltip on hover I believe it would make looking for indexers a much less daunting task for a lot of people.

I think this would be good for smaller indexers, because when it seems hard to understand and evaluate indexers, perhaps new delegators feel inclined to just go with the biggest indexers if only to go with the safety of the herd.

1 Like
7

Together with making effective cut a sortable column on https://network.thegraph.com/ instead of just a tooltip on hover I believe it would make looking for indexers a much less daunting task for a lot of people.

@Mats I think this is one of the most requested changes, so it will most likely happen, hopefully in the near future!

If I see a cooldown in place I think one of two things will happen.
Delegations will increase, meaning the indexer is less self-staked, and therefore the effective cut goes up- a negative for me. Delegations decrease, meaning the indexer is more self-staked, and therefor effective cut goes down- a negative for the indexer.

@Derkhersh This might be part of the strategy set by the indexer, like in our case. If you are confident enough that the network is already settled a bit and you can work with a variable effective cut, you could make your strategy basically have a top effective cut (when at max delegations), and if delegations move a certain amount up or down, and you can handle the lows, having the cooldown in place isn’t a bad idea.

Just for reference, we use this strategy, targetting a maximum of 10% effective cut when maxed out, but without the cooldown yet, since we weren’t sure whether we would hit max delegations (we did a few days back, so we’ll see how stable it is and check if it’s feasible to set our cooldown :wink: )

Taking as a reference our own strategy, you could probably see that if the maximum effective cut is somewhat reasonable, having your effective cut be variable can actually be a good thing, both for the indexer and for the delegators, unless it goes way down, in which case the indexer gets the worst of it, but if it’s blocked by a cooldown, you know for sure that the indexer can’t increase it more than the maximum effective cut (when at max delegations).

This, of course, wouldn’t work currently for strategies where you charge a stable effective cut.

Your middle ground solution is really growing on me. Basically if I get you correctly, when an indexer commits to a cooldown it would work like now but they could also (optionally) provide a “target effective cut %” parameter. The protocol would allow the indexer to update the cut parameters as long as it resulted in a better match with their target effective cut %, but they would also be free not to update their cut parameters. The indexer would not be punished for not updating their cut parameters, even it that meant deviating from their target effective cut %. Updating the cut parameters in a way that would move away from the target effective cut % would be prevented by the protocol during the cooldown period.

@Mats Yup, exactly. The indexer basically sets the cooldown, the protocol could calculate his current effective cut at that moment, and then the indexer would be allowed (but not forced) to maintain that effective cut (plus or minus the tolerance).

This way, delegators can be sure that one of two things can happen:

  • The current effective cut is maintained
  • The effective cut won’t ever surpass the max delegation scenario

That covers the two most used strategies (stable effective cut vs variable effective cut, with a fixed protocol reward cut)

I’m really glad that you posted it, and we could iron out the edges of the proposal, as I said in many posts, I believe this is the way to generate great ideas for change!

8

Hey, fair enough. Then give indexers both options, right? They can be tools to serve distinct purposes.

9

I don’t quite understand, that’s exactly what’s being discussed here with @Mats.

Or do you mean having 2 distinct cooldown implementations to each serve one specific purpose?

10

Yes, that’s what I mean. I like the concept of “parallel cooldowns” as proposed!

-Edit- This was me using the incorrect term. I like the “middle ground” solution juanmardefago is suggesting.

11

That was @Mats original idea/proposal too, but I do have my doubts, since adding extra complexity to an already complex protocol will have a bunch of undesired effects, as I mentioned on my original response to the proposal.

The most obvious ones are that it’s harder to understand, so you basically raise the bar of knowledge needed to understand how everything fits together, and you also add more points of failure.

That’s why I would much rather have a single flexible solution that would also allow both of those scenarios, which at the same time should be easier to implement, and less likely to break.

12

Once again, fair enough! I won’t profess to know the technicals, I can just speak from a delegators perspective- we aren’t seeing almost anyone use the cool down periods yet, but it seems like they would if they could tie it to real %. Most indexers seem to be more or less be attempting to maintain a consistent real cut anyway- they just can’t point to anything to say “hey- it’s guaranteed.”

If a relatively unknown indexer could promise to maintain the same cut, it would significantly help them compete with the larger indexers and offer delegators that extra bit of security that they seek. Indexers who locked themselves into a real cut for longer periods of time would be able to justify taking a slightly larger fee! Many delegators would be fine with this arrangement if it more or less ensured they wouldn’t need to worry about redelegating for the next 6 months. The buzz word in staking/ delegating is “set it and forget it” and this sort of thing would allow indexers to offer that.

Whatever works to implement that, cool!

1 Like
13

@juanmardefago

Your solution is easily the best one and I’d like to edit the proposal to be that, but it seems I can’t edit the proposal page. Do you think we should make a new one? Your proposal is so much better that it should be the one discussed I think.

2 Likes
14

I’m not sure whether the best is to simply close this one and start a new one, since everyone joining the discussion will miss what has been discussed previously.

Although I think that we could technically create a new one and simply… link this one?

There are a bunch of things still left to check, like how viable it is to implement. While I think that my proposal is technically possible, I didn’t write the smart contracts :sweat_smile:

15

I think mods can edit your post. Also if you reach a certain trust level you can go back and edit posts.

16

@juanmardefago
I think you are right that closing this one, starting a new one and linking to this one is the best route.

Would you like to start the new one since you should be credited with the improved proposal? If you don’t want to I’m happy to do it.

@Cole

Also if you reach a certain trust level you can go back and edit posts.

Ok, so as an alternative I could come back and edit the post in 2034 :wink:

17

@Derkhersh

-Edit- This was me using the incorrect term. I like the “middle ground” solution juanmardefago is suggesting.

Yeah, blame that on me, I made it confusing by putting to much speculation in the OP which became redundant once @juanmardefago contributed his much improved suggestion. Hopefully creating a new OP will create greater clarity.

2 Likes
18

In order to get the concept just right before the new proposal, let’s see that we have the details completely clear.

First of all, do we agree that we would need one additional (optional) parameter for the cooldown feature, which is “target effective cut”?

Then that the rules are:

  1. The “Target effective cut” parameter can only be set together with the cooldown parameter (so not mutable during the cooldown period).
  2. During the cooldown period, the indexer can change their “rewards cut” parameter if and only if the change brings the derived effective cut closer to the value specified in the “target effective cut” parameter than it would be if the “rewards cut” parameter were left unchanged.

I don’t think we even need to mention tolerance if we just always allow it to be moved closer, however much. This will always provide the needed flexibility for the indexer that wants to do the best they can to maintain effective cut and advertise their stability via the cooldown.

Is there anything you think we’d need to iron out beyond this before perhaps hashing out a draft for the real proposal here and then posting it?

Edit: the nutshell version could be summed up as “cooldown means the indexer only changes their cut to maintain effective cut, or not at all”.

19

I want to try to do some general analysis of the incentives, benefits and weaknesses with the proposal and see if you - and anybody who has made it this far down the thread - would agree.

Here’s my basic premise, please correct me if I have any of these fundamentals wrong:

If the indexer keeps their reward cut parameter unchanged and the amount of GRT delegated to the indexer increases (new people delegate), the effective cut increases as well. This is negative for the delegator but positive for the indexer.

If the indexer keeps their reward cut parameter unchanged and the amount of GRT delegated to the indexer decreases (people undelegate), the effective cut decreases as well. This is positive for the delegator but negative for the indexer.
/premise

Thus the indexer has an incentive to update the rewards cut to maintain the effective cut when people undelegate. This proposal would provide them the tools to do so without breaking the cooldown, which is a benefit to indexers.

I think it is also therefore a benefit to the health of the eco system. Simply put, it allows an indexer to scale with unforeseen undelegation in a way that might prevent especially smaller indexers from going bankrupt. It would also be easier for them to explain to delegators that they are not trying to scam them by being able to point to the cooldown protocol allowing them to do this, and that the delegators’ effective cut has been maintained.

It would also provide indexers the option to update the rewards cut to maintain effective cut when new people delegate. That is a benefit to indexers who want to do so to compete for delegators, and a benefit to delegators who have the opportunity to earn more rewards by looking for indexers who historically use this option.

The proposal still does have the weakness that an indexer can chose not to update their cut parameter as they gain more delegators, who then see their rewards diluted and the effective cut grow despite the cooldown. This is not a weakness introduced by the proposal, but one that remains not completely solved (though the proposal does help by at least introducing the option for the indexer who wants to use cooldown but also maintain effective cut as their delegation grows).

Hopefully free market mechanisms are enough to respond to this remaining weakness, and I think the proposal helps those mechanisms work by improving the strength of the signal an indexer can send about their intent to maintain effective cut.

So, I can see no downside with this proposal from the indexer perspective, they only gain options. I also see no downside from the delegator perspective, except perhaps that it doesn’t completely solve the problem of an indexer who doesn’t update when delegation grows (but the proposal does improve on this situation too).

I admit I haven’t considered the curator perspective at all in this, honestly I don’t understand it enough. Do you have any insight in how, if at all, they have touch points with this proposal?

I’m interested in all opinions on if my analysis seems valid.

1 Like
20

I’m sorry that I’m spamming with walls of text, I’m hoping that having room to fully discuss these topics is the intended purpose of the forum and that nobody feels pushed out from participating by all my writing, that’s certainly not my intention.

Anyway, I also wanted to see if anyone has thoughts on an alternative variation before we write the new proposal.

My premise is that I’m making the assumption that somewhere in the protocol implementation, there is some code that looks at the indexer’s “reward cut” parameter and allocates rewarded GRT to delegators and the indexer accordingly.

My suggestion is that this code could be modified to check if the indexer is on cooldown and has a target effective cut set. It could then use that target effective cut to derive the corresponding reward cut from the indexer stake and delegator stake and use that instead of the value specified in the “reward cut” parameter.

This would allow the indexer to pledge to keep an effective cut very precisely for the duration of the cooldown period, at no additional cost in gas and with no room for any “cheating” by foregoing to update the reward cut when the delegation grows.

Something to consider?

Edit: honestly I feel that if this would work it would be the ideal solution. It would make the current, confusing “reward cut” parameter something of an implementation detail, that probably wouldn’t even have to be shown in most UIs, which could focus on showing just the (derived) effective cut and the cooldown. The “target effective cut” parameter wouldn’t have to be shown, since if the cooldown is active it’s the effective cut shown that is guaranteed for the duration.

This would be extremely clear to delegators trying to pick indexers (and clarity makes for better markets, a “confusopoly” will not benefit anyone in the long run), it would allow indexers to maintain effective cuts with zero work or gas costs, and it is balanced between indexer and delegator interests: it auto-balances in the delegators’ favor when more people delegate but also auto-balances in the indexers’ favor during undelegation, which seems eminently fair.

Frankly I think this is how the protocol must have been meant to work (anyone who knows this?) and it would be a minimal fix to make this feature work perfectly.

Edit2: meta-suggestion: in our new proposal, we only put the title and the abstract intention (problem description plus intent/requirements for solution) in the OP, and then we keep the proposed implementation in the first post, that we can keep updating as needed with the best solution on the table, until the thread settles on what is the agreed specifics of the proposal.