Proposal to tie Cooldown to Effective Cut

@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:

@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

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”.

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

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.

I’m not sure if having to set a target effective cut is needed, that would be up to the implementation (since effective cut can be calculated based on public fields within the contracts). I’m not sure whether having it calculated in the smart contracts would mean a higher gas cost, or if adding parameters would mean higher gas costs (I’m no expert in SC optimization :sweat_smile:).

Since those are details for the implementation I think those can be completely up to the developer, since the important part of the proposal is to revamp the cooldown system to allow for both strategies mentioned earlier, and it would work exactly the same in both scenarios (calculated vs set as parameter).

If we were to have to set a parameter for the target, we might get into situations where the target set isn’t the same as the calculated effective cut at the moment you set it up, we should also consider what to do there (I guess we could do nothing, and just proceed to only allow the indexer to get closer to the effective cut even if those don’t match).

I like the idea to completely remove the “tolerance” option, since it could potentially mean you would be allowed to straight further from the effective cut in certain scenarios, and also makes it a little bit simpler (if abs(current effective cut - target effective cut) < abs(older effective cut - target effective cut) then allow, else reject).

Yeah, it’s better for everyone I think, since the indexer gains more options for strategies while still being able to set a cooldown so that delegators know what to expect and know for sure that the indexer won’t be able to perform a “sandwich attack” or even increase their current effective cut (unless of course new delegations come in, as you mentioned).

Delegators would also know for sure which are the limits of the effective cut, since the indexer only has two options when on this cooldown implementation:

  • Adjust to keep the effective cut fixed
  • Let the effective cut curve do it’s thing

This means that delegators know for sure that the maximum effective cut an indexer on cooldown can charge them is the maximum effective cut for the curve they are currently in, example in the image below:

So, all in all, the cooldown would improve certainty for delegators that the indexer can’t take advantage of them, but it won’t mean that the effective cut they see now is the effective cut that will persist for the duration of the cooldown, which means it’s probably worth showing the maximum effective cut for the curve somewhere in the dashboard (although I’m a fan of super complex spreadsheets, so maybe delegators could say whether that’s worth the extra clutter or not :sweat_smile:)

Regarding curators, they aren’t affected by any of these changes, since the curator market is something completely isolated from indexers and their settings.

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.

That would probably make this a lot more complicated than it needs to be, and that also means a major revamp of the reward distribution algorithm, which is being discussed in another thread.

To summarize my position, I don’t think it’s wise to fiddle with the reward algorithm right now, since it’s a lot more complex than the cooldown algorithm, and should be handled with care.

If we went that route (allowing for the target effective cut on cooldowns to be used instead of the reward cut) then it would be much easier just to revamp the system to use effective cut instead of the current reward cut, but that comes with some drawbacks (and probably a lot of headaches for the developers implementing it :sweat_smile:). It would also mean that we won’t be supporting both strategies discussed above (curve vs fixed effective cut), but rather only allow for fixed effective cuts when using a cooldown.

Feel free to check the other thread though :wink:

1 Like

Let’s not let the perfect become the enemy of the good here. This is an excellent, and from the sounds of it, relatively straight forward solution. While it doesn’t set things in stone, I think that’s okay. After all, APY isn’t just determined by indexer cut, it’s also determined by how many delegations there are. What this does is give indexers a pretty easy way to signal to delegators that there won’t be any rug pulling. If someone ends up getting mad that their indexer took a 11% cut instead of a 9% cut like last week, they’re being pretty insufferable and will likely never be happy. This is an excellent step forward.

Unless something happens and this proposal dramatically changes, I think this is something just about all stakeholders can support as is.

Thanks for working on this guys!

2 Likes

@juanmardefago
Bummer :slight_smile: But thanks for considering it, I’d love to keep thinking about something like the auto-keeping of effective cut by the protocol (at no gas cost to indexers) for the long term, but I’m perfectly happy with the proposal we had, so that’s what we’ll go for.
Also, the ideas are not incompatible as such and the proposal we have worked out seems like a great stepping stone to a next, future update (perhaps) that does it automatically.

@Derkhersh
Thanks for your thoughtful responses, I really hope we can make this happen!

@juanmardefago

which means it’s probably worth showing the maximum effective cut for the curve somewhere in the dashboard

This is a great idea! It could simply be shown as the two possible best (which would also be current and thus a little highlighted) to worst effective cut as: 11%-19% or maybe as 11% (19%).

Edit: I just remembered that current effective cut isn’t necessarily the best possible, if people undelegate, so it would be a bit more cluttered…maybe like this could work: 11% (5%-19%) as in “curr (min-max)”. But where to squeeze in the target cut? Oh well, however the UI is designed I like the idea of showing the info.

I think the minimum isn’t that useful, since you would want to only know the maximum the indexer might be able to keep from whatever you generate, if you get more rewards than you expected it isn’t something you will be angry about, but if you get less than you expected (because the maximum isn’t showing) you will probably get quite angry :sweat_smile:.

Also, it might get too cluttered for the UI.

1 Like

Yeah, Current/Max would work pretty well. As you say, no one is upset about getting more than they wanted.

Also gives an indexer the utility to do some kind of low cut “sale” for a week or something if they wanted to attract some extra delegators, without having to wait for the cool down to end.

1 Like

@juanmardefago , @Derkhersh

I think you guys are right.

So, are there any more details that need hashing out?

I think only implementation feedback. Most of the core devs are super busy and handling the other major proposals from what I recall, but I’d love for an opinion from @ari !

I saw that network.thegraph.com has been updated to show effective cut in the column and protocol cut in the tooltip! This is great news, and will make things much easier for delegators!

At the same time, it does perhaps increase the urgency of our proposal a small bit since now the cooldown displayed does not relate to the value displayed in the column next to it (the effective cut). There are a few indexers using the cooldown, and if a delegator sees one with an attractive effective cut and delegates, to then see the effective cut change drastically as other delegators pile on, it will possibly give a worse impression (to the effect that the cooldown can’t be trusted) than what we had before.

I also think the wording in the interface needs to be updated some more, currently some claims are a bit misleading. In the tooltip for the “Cooldown remaining” column it says “Time remaining until the indexer can update their delegation parameters again. Cooldown periods are set by indexers when they update their delegation parameters.” Then the “Effective Indexer Cut” column is sorted under the “Delegation parameters” section, implying that it is the Effective Indexer Cut that the indexer can’t change during the cooldown.

Do you know what would be the proper forum for suggesting minor UI changes like wording?

However, I have to admit I don’t have a suggestion for wording that would make the pedagogical problem go away. In fact, thinking about it I doubt that the cooldown can even be shown in a way that can be explained effectively if the effective cut is shown under “Delegation parameters”. There might need to be a new column for effective cut so the protocol cut can keep being shown under the “Delegation parameters” section, and then it isn’t as minor a UI change anymore. In fact, the solution might be to not show Cooldown in the UI at all until our proposal has been implemented.

I want to get one more alternative out there before we write the new proposal, to cover all the angles.

A super simplified version could be: The indexer can always change the protocol cut downwards during the cooldown period.

This would, I think, give all the benefits of the current proposal to the delegators. It would not, however, be as good for indexers, since they would not have the option of increasing their protocol cut while maintaining effective cut in the event of undelegation. It would, however, give the indexer who wishes to maintain their target effective cut (or better, during undelegation) the option to do so and still use the cooldown. We could still display current effective cut and worst effective cut in the UI as discussed above.

It seems to me that this alternative might have enough simplicity going for it that it could be worth considering?

For some reason I am not allowed to edit my comments anymore. @Cole help me, I must have plummeted in trust. :open_mouth:

@juanmardefago I’m starting to think this is really two proposals.

The first, simpler and probably more immediately actionable proposal is to simply say that indexers are always allowed to adjust their protocol cut downwards during the cooldown period (so, simply, always), as this should be uncontroversial to delegators.

It makes the system “rugpull safe” for delegators since indexers with a cooldown can’t suddenly increase their effective cut, and it allows for newer/smaller indexers (that are not close to delegation capacity) to start using the cooldown to signal they are willing to keep effective cut while they grow towards full delegation capacity by lowering their protocol cut as the delegation grows - again, I think the biggest problem with the current system is that indexers who are willing to do this cannot.

The second, slightly more complicated follow-up proposal is that the system can save away the indexer’s (derived) effective cut in a variable when cooldown is set (as you proposed), and the indexer would be allowed to adjust the protocol cut upwards if and only if it would bring them closer to the saved away (target) effective cut (so, our current proposal). This would bring more balance to the system and be a welcome further improvement over the first proposal to always allow downwards adjustment, but I’m not sure the first proposal which would solve the most pressing flaws with the current system should be blocked on waiting for acceptance of the second (due to any increased implementation difficulty with saving away the variable or other reasons). What do you think?

And to follow up on my UI woes…

I think the ideal solution would be a new, sortable column for “Current Effective Cut”, and replace the column that used to be the protocol cut with a “Max Effective Cut” that is shown under “Delegation parameters” (whereas "Current Effective Cut isn’t). The Cooldown tooltip would just continue to say that Cooldown binds the Delegation parameters (so the Max Effective Cut but not the Current Effective Cut). That would be perfectly honest, easy to understand and effective to sort by.

Understanding Discourse Trust Levels