Delegation Feedback Rollup Thread

Questions & Feedback Feedback
1

We’ve gotten a lot of great feedback on delegation over the past few weeks, so I thought I’d start a rollup thread here to track the feedback, as well as share some context behind some of the protocol design decisions we made and what constraints any future designs would have to satisfy.

HOW TO USE THIS THREAD: Please post any additional feedback you have related to delegation, or any additional color (or +1s) you would like to add to the existing feedback. I will try to keep the list below up-to-date with new feedback and share any additional context we might have on design constraints. To keep the conversation manageable, please post specific improvement ideas in a separate topic here: https://forum.thegraph.com/c/research/protocol-economics/23

  1. Undelegating takes a long time (28 days).
    The undelegating period is intended to, among other things, prevent double-counting of delegation across multiple simultaneous allocations, by undelegating and immediately redelegating to an Indexer. Because of that, the undelegating period needs to be at least as long as the maximum duration of an allocation, which is 28 days. Allocations are allowed to go that long to give Indexers the flexibility to spend less gas on opening/closing allocations.

    It would be great if we could find a way to reduce or eliminate the undelegating period because it would make the market for delegation far more dynamic, allowing Delegators to respond to things like poor behavior and changed delegation parameters in real-time. Any proposed solution will simply need to account for double-counting of delegation.

  2. (Related) It’s unfair that Indexers can change their delegation parameters immediately, but we have to wait 28 days to undelegate.
    Indexers have a “cooldown” that determines how often they can change delegation parameters. We considered setting a minimum cooldown here, but decided instead to let the free market determine what cooldowns Indexers set. All other things being equal, we would expect Indexers who set longer cooldowns to receive more delegation.

  3. Indexer Reward Cut & Indexer Fee Cut should only refer to rewards and fees attributed to delegated stake (like in Cosmos or LivePeer).
    This was actually the intent. Delegation was one of the last features to be worked on, and by the time we realized it wasn’t implemented in this way, we had already completed security audits. Since you can still reverse engineer the “effective cut” from the information available, we chose to leave it as is, since the changing it late in the game would have added risk to the network launch. We intend to submit a proposal to change this in the future.

  4. A Delegator can receive rewards from an allocation even if they weren’t delegated to the Indexer during the entire allocation.
    We refer to this as “Delegator Front Running,” and the purpose of the delegation tax, as well as the unbonding period, is to make this unprofitable. A better solution would be to not make Delegators eligible for rewards that are already in-flight for an Indexer, however, at the time we evaluated this approach the extra on-chain book keeping required, and the associated gas costs, did not seem to justify the benefits of the more correct solution. This is something we would like to revisit, perhaps when we explore L2 scaling for The Graph’s protocol smart contracts, if not before.

  5. Allowing Indexers to become overdelegated creates uncertainty for Delegators
    Allowing Indexers to become overdelegated provides an important market signal that they should either deposit more of their own stake or make their delegation parameters less attractive. This serves the purpose of a more efficient delegation market, while satisfying a design principle we had while designing the network, which was to not require off-chain coordination for mission-critical protocol functionality., This principle is intended to reduce centralization vectors and is also why the protocol has a curation market.

    All that being said, we agree it would be better for Delegators to have more clarity around the rewards they should expect to earn. A relatively simple option here would be to allow Indexers to become overdelegated but only by up to a certain amount, for example by only up to 25%. More complex solutions might involve dynamic bonding curves.

  6. Delegators using Token Lock Wallet must fully exit protocol to realize rewards
    This is similar to issue addressed for Indexers in this proposal, except as it pertains to Delegators. By requiring Delegators to exit fully into the Token Lock Wallet, they incur a relatively large opportunity cost as all their funds, not merely the ones they wish to withdraw must go through a thawing period.

9 Likes
2

I think one of the biggest issues with this is the sense of unfairness that it impacts delegators who joined prior to the indexer being over-delegated the same as those causing / increasing the over-delegation (who may or not understand the impact).

I’d be interested to hear how unrestricted over-delegation reducing centralisation was envisioned ? Regardless thereof in reality, if anything, we see it increase allocation centralisation ? (Which is potentially psychological in cause : higher in a list, social preselection, etc.)

I think capping over-delegation at protocol level would be a good way forward. Yet i also think, seeing not making it a hard limit is to allow for what’s merely a signal function, that 25% is high. On the biggest indexer we’re talking about potentially over 0.5 BILLION tokens being allocated in a diluting manner.

5 Likes
3

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.

As an example:

  • Let’s say you have 1M GRT owned staked, with 1M GRT delegated to you, and a 60% protocol cut (not effective cut). Your effective cut is 20% in this situation. You then proceed to lock your parameters for the next 100 days.
    image
  • Now let’s say someone comes in and delegates another 9M GRT to you, leading you to a total of 10M GRT. You locked your parameters before, you can’t lower the protocol cuts to keep the effective cut at a steady rate of 20%. With the new 9M GRT delegated to you, your effective cut now became 56%, lowering the amount your delegators make significantly.
    image

Last note on this – I’ve even noticed some indexers taking advantage of this and intentionally locking their protocol parameters to attract delegators that have no clue how to calculate the effective cut %, because “locking your parameters” is heavily emphasized everywhere without any actual context.

6 Likes
4

~28 days is a relatively standard unbonding period and provides the level of economic security needed and reduces the token velocity adequately (is there a way to quantify this beyond an opinion?) You see similar numbers on Polkadot/Substrate-based chains, Cosmos and many other chains.

However, I feel this is also punitive to first-time delegators and given the high level of distribution for GRT, the demographic spectrum is huge and would benefit from some leniency here. Cosmos has an instant redelegation feature that assists in this situation (keep in mind that Cosmos delegators are subject to slashing risk and that plays a major part in making the instant redelegation feature viable):

Technical read on Cosmos Instant Redelegation: https://docs.cosmos.network/master/modules/staking/01_state.html#redelegation

Easier read:

Cosmos Re-delegation

The 21-day lockup period for those who un-bond their stake in the Cosmos network does not inhibit someone who is already delegating their ATOM to change validators on the fly. They can instantly begin earning rewards with the validator they switch to. However, this feature is different from un-bonding, waiting for 21 days and not earning rewards over that time period and then re-delegating. This is to discourage stickiness and consolidation around validators giving penalty-free options to delegators who want to make a switch.

In this case, within the Lunie app interface, you can choose a different validator than whom you are already delegating to and redirect any amount of your staking balance from one validator to another. This process can only be done once every 21 days.

Source: https://lunie.io/guides/how-cosmos-staking-works/

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

3 Likes
5

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
7

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
8

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
9

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.

10

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.

11

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

12

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
13

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
14

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
15

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
16

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.

17

@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
18

@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
19

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
20

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).

22

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.