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:
- Improve the utility of the cooldown period by changing how it works (it is less useful today and rarely used)
- 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.
2 Likes
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.
3 Likes
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.
7 Likes
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.
2 Likes
Thawing periods? Or cooldowns? 
1 Like
This proposal has been stalled for a while because some people in the community were concerned about not being able to set a negative cut with this change in case they wanted to incentivize delegations.
Iād love to see if someone can come up with a better implementation, Iāll do the code review!
3 Likes