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 ).
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 )
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 ). 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.
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.
@juanmardefago
Bummer 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!
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 .
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.
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.
@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?
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.
).
). 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.
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.