Delegation Feedback Rollup Thread

I personally think the way this has been implemented is problematic, but maybe I will be proven wrong given enough time. My preference would be to set a rolling freeze window, so delegators can be sure that once I set the freeze window to 28 days, any change I make to the cuts will not be implemented for 28 days. That at least gives them ample time to make a decision on whether they will stick around or not. I’m really interested to hear what people think about the the cooldown mechanism.

4 Likes

The cooldown has the function to give delegators confidence ? (Currently doesn’t protect them.) So why not make it that cut % can only be changed after closing the allocation, basically cue it until that happens ? Once an existing allocation closes, rewards get distriubted at the previous % cut. And new allocations get opened with the new % cut.

Immediately triggering closing & reopening allocations could have unintended consequences, e.g. gas wasted if you wanted to change allocation amounts.
The cueing approach also works if you want to wait for automatic allocation renewal and allows you to react to promptly.

It might however be complex to implement, especially if more subgraphs get indexed, as it basically requires % cut to be attached to allocation ids (i think).

2 Likes

Great feedback so far! A lot of useful color to the existing items above. Looking forward to what others add.

If protocol-viable, something like instant redelegation would address delegator’s initial regrets around their first delegation and also reduce stickiness and indexer consolidation.

I would love to support instant re-delegation at the protocol level if we can find a way. One design constraint that separates The Graph from Cosmos is the notion of allocations an Indexer’s delegated stake being “in use” over a period of epochs. There may be ways to design around this, however, while achieving equivalent incentives.

A huge problem with this, is that the cooldown as a fresh indexer, actually hurts your delegators rewards.
Why? Because once you set a cooldown of X period of days, AND you receive delegations AFTER you set it, you then can’t lower the cuts% to balance out the new delegated stake.
It’s heavily related to your #3 point in that list.

This is a fascinating example. We always assumed Indexers and Delegators to primarily self-interested, but it was unexpected that some of the mechanisms we had chosen to protect Delegators (i.e. the cooldown) actually make it harder for Indexers to take actions with the best interests of Delegators in mind. Especially, with the way overdelegation currently works, as Koen noted.

My preference would be to set a rolling freeze window, so delegators can be sure that once I set the freeze window to 28 days, any change I make to the cuts will not be implemented for 28 days.

I agree this could be useful, either in addition or as a replacement for the cooldown period. Also interested to hear what others think.

I even propose establishing an indexer rating system, such that beginner level delegators have an idea about the reputation of indexer.

I would love to see some community experimentation here. Some forms of reputation could likely be derived from on-chain data and formalized as metrics that are computed in a subgraph, but other forms could also incorporate off-chain signals and may be computed in a transitive peer-to-peer fashion.

t might however be complex to implement, especially if more subgraphs get indexed, as it basically requires % cut to be attached to allocation ids (i think).

We opted for as gas efficient design as possible on the first pass of the delegation mechanism, but something like this could be worth it especially as we explore L2 scaling and collect more community feedback on the importance of the functionality to justify such a change.

1 Like

What about a redelegate option that has the max of the allocation periods of each indexer (the currently staked one and the on you’re going to). This would also be an additional draw for the indexers willing to pay the additional gas cost for more frequent allocations.

Also sorry if I use incorrect terms and say dumb things. I’m new to this game :slight_smile: .

edit: Yep, I said dumb things. I thought the indexers had to specify their allocation period. My bad.

My feedback is pretty similar to the “Indexing rewards should be withdrawable to a separate address” thread, but as applicable to Delegators. I was not sure if that topic was only for the sake of indexers.

Unless I am mistaken, I believe that if a Delegator wishes to undelegate their “unrealized rewards”, they would first need to undelegate the entire delegation to reach the unrealized portion. Similar to the other topic, I think that the unrealized rewards should be withdrawable to a separate address, or otherwise make them “realizable” to be added to the full staking amount.

For Delegators who wish to periodically withdraw rewards, the current system is arranged so that each withdrawal effectively reduces their “weight” in the protocol for the sake of reward allocation, because it is subtracted from the “Delegating - Total” amount.

Hi All, I just wondering do we have maximum query fee cut and rewards fee cut for indexer?

I know, of course, the indexer is the real one who works hard for actual works and indexer is indeed deserved to get majority of return.

But if the consensus of Graph is DPoS, which the intention is to bring more ppl to decentralize the network, then for certain indexers with 100% cut is unreasonable.

I would think it would be better to have maximum cut in the rules

Everyone is free to do whatever they wish, and what they think it’s good for them.
The protocol is open and permissionless.
Besides the handful of guys that have the cuts set at 100%, there are a hundred more indexers with cuts below 100%. :slight_smile:

2 Likes

Going to share my thoughts that I had put on Discord, which is that I think the current overall system makes staking really bias against/unfavorable towards delegators.

  • To start, the effective cut % is not readily visible but that already has been covered and seemingly being addressed in other proposals.
  • The 28-day unbonding period + 0.5% tax + ETH gas makes it very difficult and uneconomical for delegator mobility and active stake management (e.g. switching). Why does it matter?
  • Here’s what I’ve constantly observed: indexers offering very low cut % to attract delegators, then flipping the switch and jacking up their cut % aka rug-pulling, leaving the delegator with no lossless way out–at best, they have to wait 5+ weeks just to breakeven and losing out on reward for that duration.
  • In the worst case, this keeps happening to Bob, so Bob is now trapped in an never ending cycle of jumping from indexer to indexer, each doing the same thing, at breakeven, and thereby rendering his yield rate at 0%, never mind the headache.
  • Yes, not having a minimum cooldown contributes to this problem, but even putting in a minimum cooldown of say 28 days isn’t a good solution. Delegators look for stable yield that can go unmanaged for months, potentially years. A minimum cd of say 28 days just means they can flip it from 0% to 100% in 28 days, and we’re back to square one. (Cyclic issue mitigated but not fully resolved.)

This makes the system really scam-y.

What I, and I think many fellow delegators, would want to see is a system that allows higher freedom of staking mobility without or with reduced penalty (long unbonding period & tax, gas is probably unavoidable.) We don’t need to restrict Indexers, but rather if free market is actually the goal, give Delegators the actual freedom to choose whomever whenever.

1 Like

Here is a novel idea for “Bob” : delegate to an indexer who has set a realistic cut and does not have problems before. You seem to get the pattern, maybe you can help “Bob” to understand too and learn to avoid this.

The flipside of all the opportunities being unlocked for everyone by blockchain, defi, banking the unbanked, etc is that you are in fact responsible.

1 Like

What is the standard of “realistic”? Why does Bob have to go through the effort of drafting a research report on every indexer down the list to evaluate his options? It’s more logical to address a system that’s fundamentally flawed and complex than to peg it as “user responsibility” and sweep it under the rug.

You also mentioned DeFi, but a core pillar of cryptocurrencies and decentralized finance is that no implicit or explicit trust is required. Your suggestion implicitly trusts someone to not do bad things and abuse the system. A seemingly good actor can turn bad at any time, and a good track record isn’t the same as a guarantee.

In effect, it doesn’t fix the underlying issue.

1 Like

Giving delegators the option to instantly redelegate if the indexer changes the reward cut too much might mitigate this. But most reward cut changes are justified from what I’ve seen, so the reward cut abuse would have to be weighed against the indexer’s recent received delegations / withdrawn delegations and the total GRT staked/delegated in the network.

@Brandon Regarding #2, @Mats, @Derkhersh and I had a long discussion on possible solutions to the cooldown problem (the one later mentioned in this thread by @indexer_payne, regarding how cooldown isn’t always ideal to use).

We think it could be quite an improvement for both delegators and indexers, since it would push the system towards being easier for delegators (they would know exactly what to expect when an indexer has a cooldown in place), and would greatly benefit indexers that aren’t trying to scam their delegators.

1 Like

@graphguy I added your point as #6 to the list of feedback up above.

@juanmardefago I look forward to hearing your thoughts here. One thought that occured to me while re-reading the above is that if we fixed the issues around how rewards and fee cut were calculated AND fixed the issue with overdelegation making Delegator income unpredictable, the protocol might be at a state where more Indexers would feel comfortable setting longer cooldown periods.

@pepperbenzMcSpicy I definitely see a lot of value in making the delegation market more efficient. One consideration any design here will need to balance is that Delegators are also service providers to the network. The function they contribute to is the Sybil resistance of Indexers in the network. Part of what makes their signal (delegation) credible is that there is some cost to choosing a suboptimal Indexer (i.e., one w/ poor liveness, poor performance, etc.), currently captured as a delegation tax and the delegation thawing period.

In the ideal protocol design, the most successful Delegators would be the ones that synthesize all the publicly available on-chain data to delegate to the highest quality Indexers, while not requiring them to have an off-chain trust relationship with those same Indexers, which could act as a centralization vector (this is why delegated stake is not slashable in The Graph).

1 Like

If we make the cuts apply only to the delegated stake, I’m definitely setting at least quarterly-long locks on my parameters :slightly_smiling_face:

1 Like

Totally, we actually went the other way around on the cooldown discussion

Basically the idea was to revamp the cooldown implementation to allow the indexers to change the fee cut even when the cooldown is applied, but only if the change would move the effective cut closer to the original effective cut calculated at the time when the cooldown was set. (to avoid having to revamp the cut system).

Yeah, I fully support the solution that came out of this discussion @juanmardefago linked to. Should be pretty useful for everyone, and I expect that if it or something pretty similar gets implemented we’ll see a ton more cooldown usage, which would be really great.

Hi, question here about collecting unrealized rewards? How exactly is this done? I want to realize my GRT rewards and delegate back into the same pool. Ideally set it to auto delegate if possible.
I cannot see how to do this or find an FAQ on it.
Thanks.

It’s already set to auto-compounding by default and can’t be changed. All the rewards you get, are added back in your delegation.

1 Like

#1 – based on my own observations thus far, the objective and justified reason for a delegator needing to re-delegate to another indexer due to bad indexer behavior seem to be isolated situations. Don’t have a technical background, but want to bring forward a couple of ideas on that:

  • Assuming that the need for instant re-delegation should be an exception, is there a way to implement the ability for a delegator to do that on a limited scale, such as once a year or only three times total? Idea being that double-counting could occur in such situations, but only when a delegator feels its truly necessary while putting guard rails around the ability to abuse it on an ongoing basis.
  • Implement dispute governance process. Delegators can present their case to a cross-community committee. If case is voted in favor, delegators of said indexer are allowed instant one-time re-delegation to another indexer

#2 – cooldown periods seem to be a rare parameter set by indexers, hardly see it. Moreover, it’s a concept that is very little understood in the delegator community, based on my own experience. Some thoughts:

  • Relabel “cooldown remaining" to “payout commitment” or “rewards cut lock duration”, some language that is closer to a meaning that a delegator can better interpret and which actually conveys a positive message when they see a value being displayed there.
  • Inverse gamification: is there a way that indexers could receive any sort of benefit by being a leader in the “cooldown period” department at the protocol/operations level, such as being given earlier insight into subgraph release schedules?

#5 – I personally don’t think that many delegators are well versed on this subject and the ramifications of “overdelegations”, including the impact it has on their rewards once that occurs. I have heard fears being expressed a few times by delegators they would not earn any rewards at all in such situations. Attempting to speak from an average delegator viewpoint, it would seem the best solution is a removal of the overdelegation concept. In the end, it appears to be an exercise of moving the goal post. If it’s 25% or 0% shouldn’t matter, if we are contemplating a hard cap. Complexities are introduced to delegators when rewards/APY levels start to change due to the existence of an overdelegation territory. That could be resolved by eliminating that in the first place.

1 Like

Regarding the ability to instantly re-delegate to another Indexer, what about a meta transaction that undelegates and then delegates to your chosen Indexer at the time?

So the Delegator could choose a “Redelgate” option, choose the amount of GRT to redelegate, choose the new Indexer, and process that transaction all in one confirmation. If that’s technically feasible, at worst it would reduce the amount of babysitting the current process requires.