This is a proposal to change how the cooldown mechanism works.
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.
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.
There would need to be some tolerance to how precisely the effective cut % would have to be maintained.
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.
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.
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)