Proposal for enabling redelegation by changing how allocations work

The issue: bad actors that keep changing rewards cut cant get punished since delegators have to unstake then wait 28 days with no reward, thus punishing them too. I suggest enabling re-delegation without the 28 days cooldown for these cases.

That presents a different problem though, which is re-delegating to indexers that have not claimed rewards yet, so bad delegators could just switch from one indexer to the other, collecting rewards they shouldnt be getting.

Solution to that: Instead of allocating rewards to everyone delegated, we allocate only to those which are in the subgraphs allocation. This way we can enable delegators to re-delegate in case of bad actors without punishing them with a 28 day unstake period with no rewards, and at the same time prevent delegators to just keep redelegating to indexers with pending rewards.

1 Like

I think this period is necessary.

There should be a voting system in place that governs indexer rate changes. Votes by the delegators might be the best system here.

not for what im proposing, and does not break the system.

So someone else in control of the indexer’s rates? Even though the indexer is the only one paying heavy costs each month? And the delegators will just want the lowest rates possible, this will not go.

1 Like

Perhaps, but the delegators would just unstake if they didn’t like it anway. At least with a vote it gives the indexer data on how their delegators are feeling towards the rate change.

This is not really the point of this suggestion above, delegators can still vote on that but the indexer can still screw them over if thats their plan, then they need to undelegate and wait 28 days plus fee costs and deposit fee… then when you do undelegate, you need to find an indexer with 1.5%+ better yearly APY to even get to breakeven. This is def not a solution, what im proposing above is, in case delegators are unhappy.

An indexer business is not a cooperative. If an indexer wants to implement something like this outside the protocol, in a DAO for example. - fine. But running my business at the whim of delegators votes? Hard pass.

2 Likes

I’m not saying your operation would be 100% at the mercy of delegators, but wouldn’t you like to know if your rate increase/decrease changes would cause a more than favorable delegation exit?

it shouldnt be at the mercy of delegators, at all. For rate increase/descrease, most of us do it for a good reason and we notify our delegators. That should be enough. There is a good reason why no project ever implemented any kind of delegator governance, because it makes zero sense and would only benefit delegators, they have no idea what the operating costs of any node are. Can we stop going off the topic on this proposal please.

1 Like

No? This is a forum. All opinions are welcome and to shut them down is to remain in an ignorant headspace.

1 Like

OK, you described it as governing via a voting system, so I assumed you meant something in-protocol. Personally, no I wouldn’t find the signal from that vote to be useful (at least as the cut mechanisms work today). I think the last few months have shown that the dynamics of the cut mechanism are too complex for delegators and indexers to fully grok despite a lot of attempts to find a way to make them understandable. I think that’s a much bigger problem we need to find a solution to. That’s being discussed here

1 Like

The OP is right, this discussion is not pertinent to the original proposal and is adding noise on an unrelated subject. Please create a dedicated post for any further discussion on the topic of delegators voting on indexer cuts - I’m happy to move what I’ve written over there if you choose to make a post.

2 Likes