Forcing indexers to close existing allocations before changing cuts would be great for delegators. As it is right now, I could have 500 GRT in potential rewards and then the indexer changes the fees and I must wait for it to auto allocate my rewards, while making negligible amount of rewards. If they were forced to close existing allocations we could undelegate and wait 28 days without losing our pending GRT.
4 Likes
Hi Hermit! Welcome and thanks for making your first post.
Personally I think this makes sense. I don’t know what it means from a technological perspective, but certainly it would be easier to gain the trust of Delegators if this were in place, even with a 0 cooldown period.
3 Likes
I like the purpose behind this idea, but I don’t think it would work well exactly as stated for one reason:
An Indexer with no open allocations cannot serve queries. This would mean forcing an Indexer to shut down service to change delegation parameters - which is unacceptable for an Indexer providing critical services to dApps.
There might be better ways to achieve the same end. For example, I can imagine that the delegation parameters could be copied at the time the allocation was created. That way the Delegator has the same assurances that their potential rewards will not disappear.
3 Likes
Not sure whether the contract is able to save 2 sets of parameters (existing and newly updated cut). This way the indexer can keep old allocations open with the existing parameters and we can make the new cut changes to only affect the newly opened allocations,
2 Likes
May be for the indexer the new cut only take effect on new allocations.
1 Like
Indexers will close and reopen allocations anyway, manually or automatically ? Applying % cut could be cued for this event to happen ? Existing allocation gets distributed with existing cut, new allocation gets opened at new cut ?
imho it’d be needed to link to allocation ID. With more subgraphs, it’s not as clear cut as 1 starting / ending time.
Technically, it is hard to do this with the way the contracts are implemented. One major thing to keep in mind is that when you delegate you are part of a pool of delegated tokens with all other indexers. This pool can then be used to create larger / more allocations.
Therefore, there is no way to distinguish a one delegated token between another right now.
Allocations COULD have the percentage cut associated with them, and the gas cost would probably be acceptable for an upgrade in the contracts. However, I don’t know if it fixes anything. An indexer can choose when to create a new allocation with new tokens. Whenever you delegate your tokens, you know that a new allocation must be created. Thus, they could accept your tokens, change their fee, then create an allocation.
Hi,
What I hear here, you are trying to protect delegators against loosing their potential reward - that’s really good.
But try to take a look from another point of view, where Indexer would change Reward Cut (decrease) before closing allocation to provide delegators with even better reward.
As per our strategy, on second indexer, we promise delegators to keep fixed Real(Effective) Reward Cut, so when new delegators join the pool we have to reduce Reward Cut before closing allocation in order to avoid reward dilution and provide our existing delegators with promised reward level.
So, implementing feature proposed in this topic will ruin our service and make our delegators (about 200 delegators) unhappy.
I can also confirm that not only our team, but long list of other indexers follow the same strategy. And impact would be even worse.
I urge you think wisely and discuss such critical questions and propose your ideas having bigger quorum which would include all indexers to avoid any unpredictable impact.
Please note, that there is a “cooldown” parameter in place which indexer can use and delegator is safe to take into account choosing indexers. I can see there are plenty of indexers who have set cooldown parameter for your convinience.
P.S.
Reward Cut - is a global parameter and implementing proposed approach is not scalable.
If indexer had 50+ allocations to subgraphs they would never been sync and could be opened in different epochs including current one. closing them in one time could get unpredictable result
Best regards,